The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1990)
DOCUMENT: TCP-IP Distribution List for February 1990 (338 messages, 190755 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1990/02.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 Feb 90 00:57:31 GMT
From:      zaphod.mps.ohio-state.edu!swrinde!emory!hubcap!ncrcae!usceast!usceast.cs.scarolina.edu!wright@tut.cis.ohio-state.edu  (Stephen D. Wright)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP for the NCR Tower

Howdy,

Has any one ported the Serial Line IP (SLIP) interface to an NCR
Tower, running SysV Unix?  Is there a commercial version?  This
would be of great utility here and I suspect elsewhere.  If there
is sufficient response I'll post the results.

Thanks in advance,
Steve Wright
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 90 03:50:24 GMT
From:      mailrus!umich!wsu-cs!egrunix!srodawa@tut.cis.ohio-state.edu  (Ronald Srodawa)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP-IP and NSCA.
Very briefly now.. TCP/IP are a family of protocols developed for the
internet.  They aren't OSI, but are moving that way.  IP is a protocol
that delivers a packet (with no guarantee of success) to any chosen
site on the internet.  Every machine has a 32 bit address, usually
written with the octets in decimal, like 35.146.180.2.  TCP implements
a reliable end-to-end virtual circuit on top of IP.  It delivers packets
from a particular "port" on one machine to another paticular port on
another machine.  There are several "well-known" ports on every system
which are used to negotiate higher level uses like mail.  On top of
TCP/IP are many 
other appication protocols.  The three best known are SMTP for mail,
Telnet for remote interactive login, and ftp for file transfers.
Hope that helps.

=============================================================================
| Ronald J. Srodawa               | Internet: srodawa@unix.secs.oakland.edu |
| School of Engineering and       | UUCP:     srodawa@egrunix.UUCP          |
|    Computer Science             |                                         |
| Oakland University              |                                         |
| Rochester, Michigan  48309-4401 |                                         |
| Phone: (313) 370-2247           |                                         |
=============================================================================
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 90 05:21:44 GMT
From:      snorkelwacker!spdcc!ima!esegue!johnl@apple.com  (John R. Levine)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip for 386 UNIX
In article <5645@ncrcae.Columbia.NCR.COM> wingo@ncrcae.Columbia.NCR.COM (Dave Wingo) writes:
> I am looking for a 386 UNIX tcp/ip package and ethernet board combination.

All of the usual 386 Unix vendors ship a tcp/ip package based on Lachman's
port of BSD TCP/IP.  It works as well as any TCP does.  There is NFS on top
of it which Interactive is shipping now and SCO will sometime in the near
future.  There is a little flakiness, e.g. csh filename globbing doesn't
work on remote NFS directories that aren't on System V disks (such as
directories on Suns) but nothing that keeps me from getting my work done.
The TCP/IP interoperates well with other implementations and there are many
386 Unix boxes on the Internet.

As far as the board goes, I'd use the WD8003E which is cheap, reliable, and
has enough buffers to be fast.  Smart Ethernet cards do not improve
performance because the processor on the card tends to be a lot slower than
the 386 that it is attempting to offload.
-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl
"Now, we are all jelly doughnuts."
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Feb 90 13:39 PST
From:      Mr. Spock <Spock@SAMSON.cadr.dialnet.symbolics.com>
To:        TCP-IP%NIC.DDN.MIL@Riverside.SCRC.Symbolics.COM
Cc:        spock@SAMSON.cadr.dialnet.symbolics.com
Subject:   SLIP for the sun.
I'm looking for information on how to set-up an "ethernet" connection
between 2 sites using Sun machines connected to 9600 baud modems
communicating across a leased line.  I've been told that SLIP is the
thing to use but I know nothing about it or how to do the setup.  I've
also been told that someone on this list may be able to help me.  Help!

    Thanks,
     -Mark Alexander

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Feb 90 12:59:59 EST
From:      wood%lavc3.dnet@smithkline.com (Bill Wood, SmithKline&French R&D, 215-270-5163)
To:        "tcp-ip@nic.ddn.mil"%inet.dnet@smithkline.com
Subject:   tcp/ip questions
Hello,

I need some information on the bsd source for TCP/IP in 
bsd-source/src/sys/netinet.

1) Is this software reliable?  Does anyone know if it has
been validated?

2) Has anyone ported this software?  Where were the trouble
spots?

3) Has anyone ported it to a non-Unix operating system (eg. PC)?

4) Is there source for a non-Unix implementation in the public
domain?

Please email me directly if you can help.  Thanks,

- Bill             wood@smithkline.com

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 90 12:53:09 GMT
From:      mcsun!ukc!kl-cs!nott-cs!cat.fulcrum.bt.co.uk!masalla.fulcrum.bt.co.uk!axion!planet!mdc@uunet.uu.net  (Martin Chapman)
To:        tcp-ip@nic.ddn.mil
Subject:   Voice over Ethernet

 Does anybody out there know of any voice/phone packages that run over ethernet
(and/or TCP/IP). I am interested in being able to plug in a microphone or
telephone into my Sun Sparc station, and be able to phone other people on the
net.

  Please *e-mail* replies of products, suppliers, etc and I will
compile and post the results.


Martin.

--
Martin Chapman PhD, BSc, SMBCS, B/Tec, GCE, CSE, 11+
British Telecom Research Labs, Martlesham Heath, Suffolk, U.K.

"Life's a Bitch, then you die."
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 90 14:16:51 GMT
From:      mailrus!wuarchive!brutus.cs.uiuc.edu!uakari.primate.wisc.edu!delta!jester!peters@tut.cis.ohio-state.edu  (Frank W. Peters)
To:        tcp-ip@nic.ddn.mil
Subject:   DNS Query server?
Hello,

     Several months ago someone posted a offer of a very simple DNS resolver
server for UNIX.

     My nearest recollection of the operation of this software was that you
could connect to this code at a certain port (not the DNS port) and send a
name and receive an address.

     We now have a use for such a program.  Can anyone tell me where I might
get it?

Thanx
--Frank

Frank W. Peters        Systems Programmer     Computing Center & Services
peters@CC.MsState.Edu  Peters@MsState.Bitnet  (601)325-2942
"I can't give you brains, but I can give you a diploma." -- The Wizard of OZ
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 90 15:54:51 GMT
From:      mailrus!umich!wsu-cs!ares.cs.wayne.edu!jjb@tut.cis.ohio-state.edu  (Jon J. Brewster)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP-IP and NSCA.
In article <406@egrunix.UUCP> srodawa@unix.secs.oakland.edu.UUCP (Ronald Srodawa) writes:
[about TCP and IP]

I suspect that "NSCA" is NCSA, as in NCSA Telnet?  If so,
it stands for National Center for Supercomputing Applications
and is located at U of Illinois at Urbana-Champaign.  They
wrote the software which implements the applications ftp
and telnet on whatever.  We run it on Mac's, but I gather
you're talking about a PC version.
--
 Jon J. Brewster
 jjb@cs.wayne.edu
 ...!umich!wsu-cs!jjb
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Fri, 02 Feb 90 00:32:08 PST
From:      Greg Satz <satz@cisco.com>
To:        bnrgate!bnr.ca!aruigrok@uunet.uu.net (Adrian C Ruigrok)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Mac FTP
A version of NCSA Telnet 2.3 for the Macintosh with SLIP and MacTCP is
available for anonymous ftp from ftp.cisco.com as telnet.hqx. This version
is a combined NCSA TCP/IP and MacTCP driver version. You configure SLIP on
the modem port with the hardware=slipN configuration command (N is the baud
rate, e.g. 9600). MacTCP can be used by specifying hardware=driver. This
version will also try to do BOOTP to determine its IP address if dynamic
address configuration is requested and you are using NCSA TCP/IP. This is
useful for cisco (to name one) Terminal Servers which will respond to BOOTP
requests on their SLIP lines. The BYU FTP client is also supported by
selecting service FTP in the open connection dialog.

This version is copyright cisco Systems, Inc. It can be used and given away
as long as it is not sold. Only the binary will be made available. This
software is being supplied as is without any warranty or support.  I will
gladly receive bug reports but I can make no commitment to fixing them.

I also cannot mail anyone copies of this file. If you cannot FTP it, you
will need to ask someone else who can.

Greg Satz
cisco

PS. I am looking for a REGIS terminal emulator that I could possibly
incorporate into this package.
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 90 16:43:52 GMT
From:      swrinde!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!tank!cps3xx!raja@ucsd.edu
To:        tcp-ip@nic.ddn.mil
Subject:   HELP: telnetting from DOS to Cyber NOS/VE

I got the following request for info
from a friend in India.  Any help
would be deeply appreciated.  Please
*EMAIL* me at:

       raja%frith.egr.msu.edu@uunet.uu.net

Thanks in advance!


Narayan Sriranga Raja.
-----------------------------------------------------------------
     *EMAIL FROM INDIA BEGINS*

We would like to know if there is 
anybody on the nets using TCP/IP for PCs (basically telnet)
to access CDC's Cyber 180/840 running NOS/VE and TCP Gateway
in one of its Device Interfaces(DI). We are using the CMU's
version of MIT PCIP available in public domain. We have some
problems in using the package in that when telnet application
first opens TCP connection to the remote, it times out and
tries 8times before closing and coming out. 
We use Interlan 5010 Card and the compatible driver; I do not
suspect the driver because it works fine with a Vax 8600 running
Ultrix. If there is anyone using PCs to telnet to a Cyber host
(s)he would be the most useful contact in this regard.

Thanks Much:

---Murthy.
-----------------------------------------------------------------
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 90 19:31:02 GMT
From:      dialogic!drich@uunet.uu.net  (Dan Rich)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: rsh vs remsh -- how does one handle the name conflict?

  I decided I was tired of having to know which machine I was on, and
wrote the script below.  By listing the various remote shell programs
in the variable RSHELL, you can let this script figure out which one
to run.  Then, you can name the script anything you find convient and
place it somewhere in your path (I use /usr/public/bin/rsh, that way
it is available on all of our machines).

  One other thing.  As I mentioned earlier, under System V (or at
least with ISC's tcp/ip), you can't just rename the remote shell
program.  Rsh is written so that it can be linked to programs bearing
the names of machines on your network.  It will then attempt to run a
remote shell on that machine.  (ie. If I link rsh to dialogic, typing
'dialogic' will run a remote shell on the machine dialogic.)

8<------------------------------ Cut Here ------------------------------>8
#! /bin/sh
# $Id: rsh,v 1.1 90/02/01 10:41:01 drich Exp $
#
# rsh - remote shell that will work on any(?) machine
#
# $Log:	rsh,v $
# Revision 1.1  90/02/01  10:41:01  drich
# Initial revision
# 
#
RSHELLS="/usr/ucb/rsh /usr/bin/rshl"

for i in $RSHELLS
do
	if [ -f $i ]
	then
		RSH=$i
	fi
done

$RSH $*
8<------------------------------ Cut Here ------------------------------>8

--
Dan Rich                    | ARPA: drich%dialogic@uunet.uu.net 
UNIX Systems Administrator  | UUCP: uunet!dialogic!drich
Dialogic Corporation        | - Time is an illusion.  Lunchtime, doubly so. -
(201) 334-1268 x213         |                           Douglas Adams
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 90 20:18:32 GMT
From:      arc!chet@apple.com  (Chet Wood)
To:        tcp-ip@nic.ddn.mil
Subject:   How to connect to a nearby site?
Hi.
	One group in our company is relocating to a nearby site.
(Somewhere between next door and a few miles away, we're not sure.)

We're used to the ethernet interconnection and wondering what would be
involved in preserving some of it. What kind of hardware/software is
required to run reasonably responsive TCP-IP protocols over a
distance-- telnet, nntp, ftp, maybe nfs.

I don't think we can afford microwave, but SLIP over a telebit won't
hack it. 

What's in between? A leased phone line? Where do I find out the
basics? Hardware, software, vendors, costs?

There will probably be a Sun at the head end at each site.

Thanks in advance for suggestions....

Chet

--
Chet Wood                       ~                         (408)727-3357
     arc!chet@apple.COM         .  Advansoft Research Corporation
          chet@arc.UUCP         .       4301 Great America Parkway
               apple!arc!chet   .            Santa Clara, CA 95054, USA
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Fri, 02 Feb 90 13:40:58 -0800
From:      "Philip Almquist" <almquist@jessica.Stanford.EDU>
To:        mailrus!wuarchive!brutus.cs.uiuc.edu!uakari.primate.wisc.edu!delta!jester!peters@tut.cis.ohio-state.edu (Frank W. Peters)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: DNS Query server?
Frank,
>      Several months ago someone posted a offer of a very simple DNS resolver
> server for UNIX.
>
>      My nearest recollection of the operation of this software was that you
> could connect to this code at a certain port (not the DNS port) and send a
> name and receive an address.

	I don't think that you are going to find what you're looking
for.  The UNIX DNS resolver is pretty simple.  The UNIX DNS server can't
be simple because it has a rather complicated task to perform.

	I suspect that what you heard about is something called an
IEN-116 name server.  IEN-116 was the predecessor to the DNS.  People
who have very obsolete Bridge terminal servers will have IEN-116
servers, or one was probably posted to comp.sources.unix at some point.

	Normally, the IEN-116 server merely turns around and asks a DNS
server, so unless there's some good reason why you have to use the
IEN-116 protocol instead of DNS directly this results in somewhat
pointless extra work.  If your system still has the old /etc/hosts
routines you can probably hack it pretty trivially to use the host table
instead (since that's the way the IEN-116 server originally worked), but
then of course you have to maintain the host table.

	Another problem with IEN-116 is that I've never seen a
publicly-available IEN-116 resolver, so you'd probably have to write
your own.  Since it's a different protocol than DNS, you need to change
rather more than just the port number in your DNS resolver to get it to
work.
							Philip
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 90 00:39:12 GMT
From:      att!cbnewsd!pccl@ucbvax.Berkeley.EDU  (paul.c.liu)
To:        tcp-ip@nic.ddn.mil
Subject:   wanted: tcptest src
Does any netter know where I can retrieve the source code
for tcptest, via anonymous ftp.

It seems that tcptest runs produce much better result than ttcp.
Using etherfind reveals that tcptest has traffic pattern of
data-data-data-data-data-data-ack-ack-ack-ack-ack-ack...
and ttcp has traffic pattern like
data-ack-data-ack-data-data-ack-data-ack-ack... (small window?)

Thanks in advance!

Paul.C.Liu@ATT.COM
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 90 01:12:45 GMT
From:      zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!seth@tut.cis.ohio-state.edu  (Seth Robertson)
To:        tcp-ip@nic.ddn.mil
Subject:   Inetd Discard on SunOS4

I just picked up the netout package from jade.berkeley.edu and found out
that it did not work with Suns.  (The netout package sends lots of 10K
packets over the ethernet to a remote host which discards them using the
discard built into inetd.c)  The reason was simply that the line:

discard stream	tcp	nowait	root	internal

was not in /etc/inetd.conf (but the udp line was in there, the support was
in the inetd.c, and when you added the line, everything worked).

Now I certainly wouldn't suggest that Sun would ever do anything like this
for no good reason (:-) so I was wondering if anyone knew why Sun might have
done this.

                                        -Seth Robertson
                                         seth@ctr.columbia.edu

P.S.  Good job Thomas Ferrin
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 90 07:16:00 EST
From:      "VAXB::DBURKE" <dburke%vaxb.decnet@nusc-npt.navy.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   3com + netbios
Date sent:  2-FEB-1990 07:19:10 

Hi folks,
	 Is there such a thing as a NETBIOS driver for the 3C501 ethernet card 
from 3-COM.  If there is, how do I get it?.  Thanks for the help.

Dave
================================================================================
Dave Burke                                ||               ___________
Aquidneck Data Corporation                ||              //  ||     ||  
170 Enterprise Center                     ||             //   ||      ||  
Middletown, R.I. 02840                    ||            //    ||       ||  
dburke%vaxb.decnet@nusc-npt.navy.mil      ||           //-----||       ||  
(401) 847-7260                            ||          //      ||      ||
(This line left intentionally blank)      ||         //       ||_____||
================================================================================

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 90 03:14:43 GMT
From:      mcsun!cernvax!chx400!fatcat!acadch!impch!altger!logex@uunet.uu.net  (logex)
To:        tcp-ip@nic.ddn.mil
Subject:   tn3270 BUT for 5250 IBM systems 36 terminals ?

Hi all:

I'd like to know if there is such a thing (public domain),
as tn3270 but, what i need to emulate is a 5250 and/or
5251 terminal for an IBM System 36.

Can you tell me where can i get such software.? I am planning 
to implement it on a Xenix system or NCR Tower Unix system.

I'd appreciuate your help, thanks in advance.!!
Email me to logex@altger.UUCP

Thanks.    Ed
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Feb 90 09:01:13 EST
From:      Asher Waldfogel <awaldfog@wellfleet.com>
To:        CUNYVM.CUNY.EDU!BARILVM.BITNET!HANK@talcott.harvard.edu, tcp-ip@sri-nic.ARPA
Subject:   RE: Billing for use
	
>I believe that by introducing billing, all mass distribution lists
>will become large "question" boards with no answers.  We will have
>effectively killed off the vast amount of cooperation that goes on
>daily over the Internet.
	
>OK.  So we can't bill the sender.  How about the receipant paying?
>How easy would it then be for some hostile user/host to send a couple
>of gigabytes of information to your host, just so that you got billed
>for it?
	
>I don't believe we can bill by sender or by receiver.  Anyone who
>tries it is just asking for trouble.  If one must recapture costs,
>then use the example given by someone else in this list and impose
>a yearly tax for Internet connection, whether you use it or not.
	
>Hank Nussbacher
>ILAN - Israeli Academic Network

I agree that with the current model of unmoderated lists, it is hard
to adopt a billing policy under which experts answer questions.  But 
I think that magazine subscription is just about the right model for
mailing lists.  I subscribe to the list, and pay for everything that is
sent to me.  I may even pay a subscription which pays for a list editor,
whose responsibility is to keep multi-megabyte diatribes and irrelevant
contributions off the list.  I might also choose to subscribe to an
unmoderated list, and take my chances, or to subscribe to all messages 
shorter than some preset length - with the option to retrieve those messages
later (at my cost) from some archive.

Does this inhibit the exchange of information?  Possibly.  But it might also 
encourage someone to edit and publish old list contributions, which could
answer a large fraction of questions sent in to the list.

I think that intuitively we all agree that the initiator of a message 
transaction bears some responsibility for the costs of fulfilling it -
Vint's "commons" problem - we just need some consensus about who the
initiator really is.  For lists is it the sender or the subscriber?  And
if it is the subscriber, we need some way to bill reverse charges.

Asher Waldfogel

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Feb 90 14:37:55 PST
From:      postel@venera.isi.edu
To:        TCP-IP@nic.ddn.mil
Cc:        iab@venera.isi.edu, iesg@venera.isi.edu, ietf@venera.isi.edu, irsg@venera.isi.edu
Subject:   About RFCs in Postscript and Ascii

Hi:

RFCs have been traditionally published in ASCII text.

The IAB has decided that RFCs may be published in PostScript.  This
decision is motivated by the desire to include diagrams, drawings, and
such in RFCs.  It also allows authors that normally work with document
production tools that produce PostScript output to use their normal
tools.  PostScript documents (on paper, so far) are visually more
appealing and have improved readability.

PostScript was chosen for the fancy form of RFC publication over other
possible systems (e.g., impress, interpress, oda) because of the
perceived wide spread availability of PostScript capable printers.

It has been pointed out that many RFC users read the documents online
and use various text oriented tools (e.g., emacs, grep) to search
them.  Often, brief excerpts from RFCs are included in e-mail.  These
practices are not yet practical with PostScript files.

Therefore, the IAB has also decided that when ever an RFC is published
in PostScript a secondary version of that RFC is to be made available
in ASCII text.  This secondary version may be missing some elements of
the primary version (e.g., diagrams), and be formatted differently.

Work is in progress to provide the secondary versions of the
PostScript RFCs already published.

It has also been pointed out that PostScript is less standard that has
been assumed and that several of the document production systems that
claim to produce PostScript actually produce nonstandard results.

It may be necessary to identify a set of document production systems
authorized for use in production of PostScript RFCs, based on the
reasonableness of the output files they generate.


--jon.  (The RFC Editor)
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 February 1990 1503-PST (Friday)
From:      stanonik@nprdc.navy.mil (Ron Stanonik)
To:        tcp-ip@nic.ddn.mil
Subject:   milnet/nsfnet(cerfnet) connectivity
We recently needed to connect from a milnet site (nprdc.navy.mil)
to a cerfnet site (sdsu.edu) , and found delays were about ~30secs.
This is particularly annoying given that the sites are less than
5 miles apart.  The milnet/arpanet core gateways were redirecting
nprdc.navy.mil through reston-dcec-mb.ddn.mil; ie, both sites are
in San Diego CA, but at least one site was being redirected through
VA(?).

Admittedly the milnet is only 56kb and is now an unfashionable
backwater of the networking galaxy, but something seems very
wrong with the routing to produce delays of 1/2 minute.

Aside from the milnet noc, is there anyone else to query about
routing problems (an nsfnet noc?)?  Gone are the days when we
only needed to sort out routing with one or two gateways.

Is there an online description of the nsfnet topology?  Not that
it will help.

Thanks,

Ron Stanonik
stanonik@nprdc.navy.mil
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 90 08:32:08 GMT
From:      satz@CISCO.COM (Greg Satz)
To:        comp.protocols.tcp-ip
Subject:   Re: Mac FTP

A version of NCSA Telnet 2.3 for the Macintosh with SLIP and MacTCP is
available for anonymous ftp from ftp.cisco.com as telnet.hqx. This version
is a combined NCSA TCP/IP and MacTCP driver version. You configure SLIP on
the modem port with the hardware=slipN configuration command (N is the baud
rate, e.g. 9600). MacTCP can be used by specifying hardware=driver. This
version will also try to do BOOTP to determine its IP address if dynamic
address configuration is requested and you are using NCSA TCP/IP. This is
useful for cisco (to name one) Terminal Servers which will respond to BOOTP
requests on their SLIP lines. The BYU FTP client is also supported by
selecting service FTP in the open connection dialog.

This version is copyright cisco Systems, Inc. It can be used and given away
as long as it is not sold. Only the binary will be made available. This
software is being supplied as is without any warranty or support.  I will
gladly receive bug reports but I can make no commitment to fixing them.

I also cannot mail anyone copies of this file. If you cannot FTP it, you
will need to ask someone else who can.

Greg Satz
cisco

PS. I am looking for a REGIS terminal emulator that I could possibly
incorporate into this package.

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Feb 90 16:12:51 EST
From:      Scott W. Rogers <rogers@osi540sn.gsfc.nasa.gov>
To:        arc!chet@apple.com, tcp-ip@nic.ddn.mil
Subject:   Re:  How to connect to a nearby site?
Broadband with bridges will give you full 10-megabit bandwidth.
You may be able to contract with a local cable TV company if a
cable happens to run past both of your facilities.
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 90 12:16:00 GMT
From:      dburke%vaxb.decnet@NUSC-NPT.NAVY.MIL ("VAXB::DBURKE")
To:        comp.protocols.tcp-ip
Subject:   3com + netbios

Date sent:  2-FEB-1990 07:19:10 

Hi folks,
	 Is there such a thing as a NETBIOS driver for the 3C501 ethernet card 
from 3-COM.  If there is, how do I get it?.  Thanks for the help.

Dave
================================================================================
Dave Burke                                ||               ___________
Aquidneck Data Corporation                ||              //  ||     ||  
170 Enterprise Center                     ||             //   ||      ||  
Middletown, R.I. 02840                    ||            //    ||       ||  
dburke%vaxb.decnet@nusc-npt.navy.mil      ||           //-----||       ||  
(401) 847-7260                            ||          //      ||      ||
(This line left intentionally blank)      ||         //       ||_____||
================================================================================

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 90 15:47:28 GMT
From:      ico!dougm@handies.ucar.edu  (Doug McCallum)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip for 386 UNIX
In article <1990Feb1.052144.27172@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes:
...
>All of the usual 386 Unix vendors ship a tcp/ip package based on Lachman's
>port of BSD TCP/IP.  It works as well as any TCP does.  There is NFS on top
>of it which Interactive is shipping now and SCO will sometime in the near

Not really a true statement.  ISC's TCP/IP is not based on Lachman's in the
386/ix product.  It is based on a port ISC did long before Lachman and ISC
became the same company.

AT&T's TCP/IP is based on the Wollongong port and not the Lachman port.
A number of 386 UNIX vendors are selling this version.

A number of vendors are also using an independent port done by Spider Systems
and a few with the TCP/IP port by Streamlined.

While the Lachman based TCP/IP is probably the most widely distributed, it
isn't the only one.  A major portion of the 386 versions are one of the others.

The NFS implementations probably all come from the LAI base.
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 90 17:25:58 GMT
From:      dcatla!endrk@gatech.edu  (David R. Koch)
To:        tcp-ip@nic.ddn.mil
Subject:   BSD TCP/IP source code

	My company is looking for information concerning the 
	BSD TCP/IP suite source code.  Basically, I'm looking for
	someone to contact to discuss the procedures for 
	licensing and so on.  Any help would be greatly appreciated.


David Koch				Racal Data Network
    					Alpharetta, Georgia 
(404)442-4738				{gatech, sun!sunatl} !dcatla!endrk
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 90 18:17:23 GMT
From:      hpda!hpcuhb!hpscdc!karl@ucbvax.Berkeley.EDU  (Karl Watanabe)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Ethernet Throughput (AMD vs. Intel vs. Seeq)
/ hpscdc:comp.protocols.tcp-ip / ncpmont@amdcad.AMD.COM (Mark Montgomery) /  8:12 pm  Jan 30, 1990 /
In article <582@berlioz.nsc.com> andrew@dtg.nsc.com (Lord Snooty @ The Giant Poisoned Electric Head       ) writes:
><2447@ncr-sd.SanDiego.NCR.COM>, ward@babel.SanDiego.NCR.COM (Ed Ward 2337) :
>> I'm looking for some information comparing the Ethernet throughput of the 
>> AMD lance, Seeq 8005, and Intel 82??? controller chips....
>
>I'd look at National's NIC too - they practically own the Enet market.
>-- 
>...........................................................................
>Andrew Palfreyman	andrew@dtg.nsc.com	Albania before April!

Whoa, boy!	I think that the statement "they practically own the Enet
market" is a bit rash.	Check with IBM, DEC, SUN or 3COM or look inside their
boxes.  I think you'll find that there are about twice as many AMD LANCE, SIA
and XCVR chips in them as all those other manufacturers have sockets combined.
"LOOK AGAIN" to quote the T.I. speak n' spell chip.		Mark
----------


I have opened a few HP LAN modules and I see AMD LANCE and SIA chips.

I don't how NATL Semi could possible "OWN" the ENET mkt.

Karl
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 90 00:22:02 GMT
From:      pyramid!ctnews!unix386!markb@decwrl.dec.com  (Mark Beyer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip for 386 UNIX
In article <1990Feb2.154728.17877@ico.isc.com>, dougm@ico.isc.com (Doug McCallum) writes:
> In article <1990Feb1.052144.27172@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes:
> ...
> AT&T's TCP/IP is based on the Wollongong port and not the Lachman port.

In which release ?  SVR4 is definitely the Convergent/Lachmann port.



-- 
--
Mark Beyer
markb@convergent.com
{pyramid,pacbell,sri-unix}!ctnews!markb
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Sat, 3 Feb 90 10:47:30 MST
From:      "Doug McCallum" <dougm@ico.isc.com>
To:        pyramid!ctnews!unix386!markb@decwrl.dec.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re(2): tcp/ip for 386 UNIX
In reply to your message of 3 Feb 90 00:22:02 GMT
-------
> In article <1990Feb2.154728.17877@ico.isc.com>, dougm@ico.isc.com (Doug McCallum) writes:
> > In article <1990Feb1.052144.27172@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes:
> > ...
> > AT&T's TCP/IP is based on the Wollongong port and not the Lachman port.

> In which release ?  SVR4 is definitely the Convergent/Lachmann port.

SVR3.  SVR4 is only barely out the door and is only available to a small
handful of people.  THe discussion was about currently shipping 386
based UNIX systems.
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 90 05:25:42 GMT
From:      van-bc!skl@ucbvax.Berkeley.EDU  (Samuel Lam)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: About RFCs in Postscript and Ascii
In article <9002022237.AA21479@bel.isi.edu>, postel@VENERA.ISI.EDU wrote:
>... the IAB has also decided that when ever an RFC is published
>in PostScript a secondary version of that RFC is to be made available
>in ASCII text.

Thank you very much!!!  This decision is appreciated.

-- 
Internet: <skl@wimsey.bc.ca>	UUCP: {van-bc,ubc-cs,uunet}!wimsey.bc.ca!skl
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 90 06:16:26 GMT
From:      zaphod.mps.ohio-state.edu!usc!venera.isi.edu!gremlin!nrtc.nrtc.northrop.com!wdarden@tut.cis.ohio-state.edu  (Bill Darden <zaphod.mps.ohio-state.edu!usc!venera.isi.edu!gremlin!nrtc.nrtc.northrop.com!wdarden@tut.cis.ohio-state.edu>)
To:        tcp-ip@nic.ddn.mil
Subject:   ACC 4xxx Experiences
I would greatly appreciate any user experiences with ACC 4130 and
4400 Routers and 4800 SNMP Network Management System.

Thanks,

BiLL.....
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 90 06:16:47 GMT
From:      ecsvax.uncecs.edu!dukeac!wolves!ggw@mcnc.org  (Gregory G. Woodbury)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: rsh vs remsh -- how does one handle the name conflict?
DOUG@YSUB.BITNET ("Doug Sewell"):
- On our Encore (4.2-based) system, there is no '/bin/rsh'.  If I enter
- 'rsh' on the Encore, it wants to know what host to use.
- 
- So, I'd conclude rsh (remote shell) is a Berkeleyism, and rsh (restricted
- shell) is a ATTism.

	At work, on the Opus 88k's and Clippers, /bin/rsh is the restricted
shell and /usr/bin/rsh is the remote shell (sometimes in /usr/ucb/rsh). They
recommend renaming it to rmtsh if you want to and note that in a homeogenous
environment it should not create a problem.

	Personally, I define a (bourne) shell function "rsh" that references
the /usr/bin/rsh program and passes all the arguments to that.  Also, in the
small network we have, I define shell functions that are the names of the other
machines in the dept that invoke rsh with at fixed first argument and passing
the rest of the args to the machine bing sought.

The functions look like:
	rsh(){
		/usr/bin/rsh $@
	}

	aliceb(){
		if [ $# -eq 0 ]
		then
			rlogin aliceb
		else
			rsh aliceb TZ=EST5EDT $@
		fi
	}
-- 
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>
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 90 14:22:39 GMT
From:      zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!stat!pace@tut.cis.ohio-state.edu  (Donald Pace)
To:        tcp-ip@nic.ddn.mil
Subject:   CUTCP lpr


I have a problem.  I am using the Columbia University TCP package
on my IBM4381 running under VM.  I am new to VM and IBMs in general
but what I want to do is set up a LPR virt. machine as the documentation
from Columbia describes.  I have a problem however.  It seems that the
lpr virt. machine startup file is written for a processor called 
wylbur.  I do not have wylbur.  Does anyone out there know where 
I can get wylbur ( if it is PD ), or has anyone out there avoided
this and wrote their own execs without using wylbur?

thanks in advance
Don Pace
Florida State University
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 90 19:51:44 GMT
From:      sluggo!melohn@sun.com  (Bill Melohn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Inetd Discard on SunOS4

All of the internal services are included in /etc/inetd.conf in SunOS 4.1.
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Sun, 4 Feb 90 8:37:50 EST
From:      Jack Haverty <haverty@BBN.COM>
To:        van-bc!skl@ucbvax.berkeley.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  About RFCs in Postscript and Ascii
Some documents will be very difficult to understand with only ascii
content, e.g., documents with diagrams, graphs, and other pictorial
information.

Request for clarification: is the intent of this policy to create ascii
images of RFCs which are complete and understandable in isolation, or
to create ascii versions of RFCs for ease of computer searching, extraction
of text, and the like?

Jack
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 90 13:37:50 GMT
From:      haverty@BBN.COM (Jack Haverty)
To:        comp.protocols.tcp-ip
Subject:   Re:  About RFCs in Postscript and Ascii

Some documents will be very difficult to understand with only ascii
content, e.g., documents with diagrams, graphs, and other pictorial
information.

Request for clarification: is the intent of this policy to create ascii
images of RFCs which are complete and understandable in isolation, or
to create ascii versions of RFCs for ease of computer searching, extraction
of text, and the like?

Jack

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Sun, 4 Feb 90 19:24:54 GMT
From:      gkn @ Sds.Sdsc.Edu (Gerard K. Newman)
To:        stanonik @ nprdc.navy.mil, tcp-ip @ nic.ddn.mil
Subject:   CERFNET/MILNET connectivity
>From:	 stanonik@nprdc.navy.mil (Ron Stanonik)
>Subject: milnet/nsfnet(cerfnet) connectivity
>Date:	 2 February 1990 1503-PST (Friday)
>
>We recently needed to connect from a milnet site (nprdc.navy.mil)
>to a cerfnet site (sdsu.edu) , and found delays were about ~30secs.
>This is particularly annoying given that the sites are less than
>5 miles apart.  The milnet/arpanet core gateways were redirecting
>nprdc.navy.mil through reston-dcec-mb.ddn.mil; ie, both sites are
>in San Diego CA, but at least one site was being redirected through
>VA(?).

CERFNET gets its connectivity to the NSFNET backbone at the NSS here
at the San Diego Supercomputer Center;  however, it seems that all of
the nets advertised thru the NSS here in San Diego seem to get fed
into the MILNET via RESTON-DCEC-MB.DDN.MIL, which is pretty stupid
given that MOFFET-FLD-MB.DDN.MIL is only 2 T1 and 2 ethernet hops
from SDSC.

MILNET connectivity from SDSC is pretty bad most of the time because
of this.

gkn
----------------------------------------
Internet: GKN@SDS.SDSC.EDU
Bitnet:   GKN@SDSC
Span:     SDSC::GKN (27.1)
MFEnet:   GKN@SDS
USPS:     Gerard K. Newman
          San Diego Supercomputer Center
          P.O. Box 85608
          San Diego, CA 92138-5608
Phone:    619.534.5076
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Feb 90 10:30:06 PST
From:      prue@venera.isi.edu
To:        stanonik@nprdc.navy.mil
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  milnet/nsfnet(cerfnet) connectivity
>We recently needed to connect from a milnet site (nprdc.navy.mil)
>to a cerfnet site (sdsu.edu) , and found delays were about ~30secs.
>This is particularly annoying given that the sites are less than
>5 miles apart.  The milnet/arpanet core gateways were redirecting
>nprdc.navy.mil through reston-dcec-mb.ddn.mil; ie, both sites are
>in San Diego CA, but at least one site was being redirected through
>VA(?).

>Admittedly the milnet is only 56kb and is now an unfashionable
>backwater of the networking galaxy, but something seems very
>wrong with the routing to produce delays of 1/2 minute.

I coordinate the routing within Los Nettos in the Los Angeles Area.  Los Nettos
and CERFnet have well coordinated routing and are well interconnected.  They
can be thought, topologically, to be the same regional network.  They are not
administratively the same but again are well coordinated.  Los Nettos advertises
sdsu.edu to the Arpanet and in particular to the mail bridge 

	MARINA-DEL-REY-MB.DDN.MIL  ==>  26.6.0.103  10.6.0.22
	
This mail bridge is co-located with a Los Nettos node and on the same PSN, #22,
on the Arpanet.

Within Los Nettos/CERFnet the route back is via full T1 to this mail bridge.
That is, the return path does not touch the NSFNET backbone.  I have no tools 
to tell me the path from your node towards sdsu.edu.  Right now the ping times
from the Los Nettos node co-located with the mail bridge, to sdsu.edu is 
averaging 182 ms.

I do know that MARINA-DEL-REY-MB.DDN.MIL has been unresponsive to pings at 
various times and may or may not have forwarded packets.

Walt Prue
213-822-1511



-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Feb 90 08:30:23 EST
From:      hsw@sparta.com (Howard Weiss)
To:        almquist@jessica.Stanford.EDU
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: DNS Query server?
Actually, I believe that what Frank Peters was looking for was
the service that host 128.218.1.109 provides on port 5555 - you
simply connect to that host at that port, type in a fully formed
internet host name and it responds with an internet address and
closes the connection.  I used it when I had a host that still
only had /etc/hosts and it did just what I needed - which was
basically a manual nslookup.

Howard Weiss

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      5 February 1990 1323-PST (Monday)
From:      stanonik@nprdc.navy.mil (Ron Stanonik)
To:        prue@venera.isi.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Re:  milnet/nsfnet(cerfnet) connectivity
Thanks for the info.

We're now getting redirects from the milnet/arpanet core to
route through marina-del-rey, instead of reston.  Coincidently(?)
rtt's are down to 500msec, which makes the connection usable.
Hmm, maybe someone unthreaded a routing knot along the way?

Thanks,

Ron
stanonik@nprdc.navy.mil

ps. If anyone's interested, this is the traceroute from nprdc.navy.mil
to sdsu.edu:

traceroute to sdsu.edu (130.191.229.14), 30 hops max, 40 byte packets
 1  MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  241 ms  125 ms  152 ms
 2  10.0.0.22 (10.0.0.22)  180 ms  185 ms  170 ms
 3  ucla-gw.ln.net (130.152.64.2)  184 ms  394 ms  273 ms
 4  CERFnet-GW.UCLA.EDU (128.97.10.253)  169 ms  226 ms  172 ms
 5  sdsc-ucla.cerf.net (134.24.101.100)  402 ms  266 ms  261 ms
 6  134.24.220.101 (134.24.220.101)  477 ms  520 ms  630 ms
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  sdsu.edu (130.191.229.14)  451 ms !  615 ms !  815 ms !
-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Feb 90 10:25:18 EST
From:      ntm1169@dsac.dla.mil (Mott Given)
To:        tcp-ip@nic.ddn.mil (TCP-IP List)
Cc:        mgiven@dsac.dla.mil
Subject:   Trying to get email address Colorado State Univ.

  I am trying to get the e-mail address (if any) of a Dr. Susan Athey at 
   Colorado State Univ.   I tried the command "$ whois athey" without any 
   luck.  When I looked in our list of INTERNET hosts, I could not tell
   which of the hosts with a "colorado" string embedded corresponds to
   Colorado State Univ.  I had thought if I could discover that, that I could
   write to the postmaster at that site.  Does anyone have any ideas about 
   how I could proceed?
-- 
Mott Given @ Defense Logistics Agency Systems Automation Center,
             DSAC-TMP, Bldg. 27-1, P.O. Box 1605, Columbus, OH 43216-5002
INTERNET:  mgiven@dsac.dla.mil   UUCP: ...{osu-cis}!dsac!mgiven
Phone:  614-238-9431  AUTOVON: 850-9431   FAX: 614-238-3214 I speak for myself
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Feb 90 10:25:38 EST
From:      Frank Kastenholz <kasten%interlan.interlan.com@RELAY.CS.NET>
To:        TCP-IP@NIC.DDN.MIL, postel@VENERA.ISI.EDU
Cc:        iab@VENERA.ISI.EDU, iesg@VENERA.ISI.EDU, ietf@VENERA.ISI.EDU, irsg@VENERA.ISI.EDU
Subject:   Re:  About RFCs in Postscript and Ascii
I think that this is an excellent solution to the Postscript vs Ascii
debate.

My only concern is that there may be useful information that is lost in going
from Postscript to ASCII. For example, if the TCP RFC were originally done in
Postscript and 'ported' to ASCII, the TCP header and state transition diagrams
could be lost. Will any effort be made to preserve these diagrams?

Also, given the possible information loss, which version of the RFC will be
the 'official' one?

As an aside - maybe diagrams could be made available via "FAX over TCP"?
I seem to recall that there was a discussion thread on the TCP/FAX topic
on the TCP-IP list within the past 2 or 3 months so there is some
interest in the general subject.

Cheers
Frank Kastenholz
Racal Interlan
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 90 13:14:04 GMT
From:      interlan!backman@eddie.mit.edu  (Larry Backman)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Racal Interlan TCP/IP for 386 Unix
In article <9001292040.AA00602@sparkle.tis.com> ho@LA.TIS.COM (Hilarie K. Orman) writes:
>Recently Mark Towfigh of Racal Interlan posted information about
>a TCP/IP product for 386 Unix.  The 800 number he mentioned seems
>to open onto an automated message system that captures customer
>information and returns nothing, and I have received mailer failure
>messages from attempts to contact towfiq@interlan.Interlan.COM.
>Has anyone successfully contacted this company?
>
FYI

	Racal - Interlan, Inc.
	508-263-9929 or 1-800-LAN-TALK
	(ask for direct marketing)

		towfiq@interlan.com
		uunet!interrlan!towfiq
     
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 90 17:27:41 GMT
From:      zaphod.mps.ohio-state.edu!usc!srhqla!nrcvax!ihm@tut.cis.ohio-state.edu  (Ian H. Merritt)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  About RFCs in Postscript and Ascii
haverty@BBN.COM (Jack Haverty) says:
>Some documents will be very difficult to understand with only ascii
>content, e.g., documents with diagrams, graphs, and other pictorial
>information.
>
>Request for clarification: is the intent of this policy to create ascii
>images of RFCs which are complete and understandable in isolation, or
>to create ascii versions of RFCs for ease of computer searching, extraction
>of text, and the like?
>
>Jack

Jack, I have access to a PostScript printer.  It is tough to grep
through a paper copy of an RFC, no matter how 'pretty' it may be.  The
PostScript format files are of little use in this regard as well.

For my purposes and per many of the other comments I read in the
initial flurry of complaints spawned by the first few PostScript-only
RFC's, it is this (computer searching as you suggest in your question)
that is most important about plaintext.  Once the RFC has been
mechanically identified, we can get a paper copy.

Also, it is useful to be able to include quotes from the RFC in E-mail
without having to type them in from a paper copy (extraction, as you
also suggest in your question).  Retyping, after all would somewhat
defeat the purpose of this marvelous electronic communication system
we all know and love.

	-i

Ps: Thank you Jon Postel.

-- 
US Snail:	2380 Rose Avenue; Oxnard, CA  93030  U.S.A. tel. 805-485-2700
InterNet:	ihm@NRC.COM
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 90 18:09:54 GMT
From:      hpda!hpcupt1!hprnd!pat@ucbvax.Berkeley.EDU  (Pat Thaler)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Ethernet Throughput (AMD vs. Intel vs. Seeq)
Probably nobody "owns" the Ethernet IC market.  The National 
controller chip is used on a lot of newer cards for PC's (but 
certainly not all PC cards).  Cards for workstations often use the 
Intel and AMD chipsets.  The early SEEQ chips were also used
a lot on PC's, I'm not sure about the 8005.  People's perceptions of
who "owns" the market are probably colored by what machines they
normally work with.  (I expect that most of the IC vendors involved
don't release sales figures on their Ethernet chips.)

In my experience, how well a chip performs often depends on how it
interacts with the backplane it is interfaced to.  In other words,
it is possible that chip A will perform better than chip B in
a PC; but chip B will perform better than chip A in another backplane.
On the chips which support a buffer structure, how efficiently you
manage the buffers can also affect performance.  There may be a
trade off of efficiency in throughput for efficiency in memory usage.

It is not clear to me that a benchmark test of the chips against each
other in a set environment will indicate relative performance in 
another environment.

Pat Thaler
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 90 18:23:33 GMT
From:      motcsd!motsj1!mcdchg!chinet!rpslmc!bwolfe@apple.com  (brian wolfe)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP for Data General MV7800?

I'm interested in finding an ethernet board and TCP/IP software
package for a Data General MV7800, the computer is actually part of
a GE medical systems MRI unit. 

GE has told us that they are working on such a product, but it won't be 
available for a while... we'd like to get something now if its available.

Please email responses to brian@chinet.chi.il.us and I will
summarize if there is any interest.

Thanks in advance,

 
Brian Wolfe

Dept. of Radiology                                 brian@chinet.chi.il.us
Rush Presbyterian - St. Lukes Medical Center
Voice: (312)-942-5781
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 90 20:20:02 GMT
From:      ubc-cs!alberta!atha!lyndon@beaver.cs.washington.edu  (Lyndon Nerenberg)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: rsh vs remsh -- how does one handle the name conflict?
I have been wondering how to handle the conflict between the USG
and BSD rsh commands. I consider the BSD rsh to be the "real thing"
since it seems to be used more in that context. The only time I've
seen rsh used as a restricted shell is inside the sysadm command
under SVR3. Since I consider sysadm as being hopelessly broken, I
classify the USG behaviour as depricated :-)

Since SVR4 is merging in the BSD networking utilities (to some extent,
anyway), I would think that AT&T has already had to deal with this
behaviour. Could someone familiar with SVR4 comment on this?


-- 
Lyndon Nerenberg  VE6BBM / Computing Services / Athabasca University
     {alberta,decwrl}!atha!lyndon || lyndon@cs.AthabascaU.CA

                     UREP: Peru in disguise?
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 90 22:27:19 GMT
From:      cogsci!schimmel@ucsd.edu  (John E. Schimmel)
To:        tcp-ip@nic.ddn.mil
Subject:   Where can I get sources to RDP for VAX/DECstations?
We wuld very much like to use RDP on VAXstations and DECstations.
Could someone please give me some hints as to a contact for this.

Thanks,
John E. Schimmel
jschimmel@ucsd.edu
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 90 06:17:21 GMT
From:      unsvax!jimi!herbert!doug@uunet.uu.net  (Doug Phillipson 5-0134)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP

	Hello world. I have SLIP running between PC's and SUN's
but it won't work between SUN's.  Has anyone done this using the
SLIP stuff that comes with PC-NFS? Am I missing something?  SUN says
they don't support it but I just know someone must be doing it. I
am trying to get rid of a bridge.  Any help will be greatly appreciated.

Thanks in advance.

Douglas Phillipson (Please use E-mail I will post summary)
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Feb 90 16:37:55 EST
From:      craig@cwh.cam.nist.gov (Craig Hunt)
To:        tcp-ip@nic.ddn.mil
Subject:   Getting a commercial firm into Internet
One of our network users, who is doing extensive work with a commercial
firm, asked how that firm could have access to the Internet. Does
anyone know who is offering a service to connect commercial users into
Internet services.  I suggested UUNET and CSNET.  I also thought
perhaps Merit. Suggestions, contacts, addresses would all be
appreciated.

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Feb 90 19:10:02 EST
From:      Phil Dykstra <phil@BRL.MIL>
To:        tcp-ip@nic.ddn.mil
Subject:   Thanks
I just wanted to thank whoever-did-it for some changes-for-the-better
that happened recently:

1) Thanks to the NIC for answering all pings again.  I my opinion this
   is one of the NIC's valuable services, especially since you do record
   route right (!), are on ARPA and MIL net, and are almost always up.

2) Thanks to the core gateway guys for implementing Record Route.

3) Thanks to the core for no longer forwarding 1->0 TTL packets
   (so traceroute works right).

The nice result:

vgr> ping -R sri-nic.arpa
PING sri-nic.arpa (10.0.0.51): 56 data bytes
64 bytes from 10.0.0.51: icmp_seq=0 time=374 ms
BRL.ARPA (26.2.0.29)
RESTON-DCEC-MB.DDN.MIL (10.6.0.20)
NIC.DDN.MIL (10.0.0.51)
NIC.DDN.MIL (26.0.0.73)
ext394.brl.mil (192.5.23.253)
vgr.brl.mil (192.5.23.6)

sprt> traceroute sri-nic.arpa
traceroute to nic.ddn.mil (10.0.0.51), 30 hops max, 38 byte packets
 1  gw394 (192.5.23.1)  20 ms  0 ms  0 ms
 2  ext394 (192.5.23.253)  20 ms  20 ms  20 ms
 3  reston-dcec-mb.ddn.mil (26.21.0.104)  120 ms  180 ms  120 ms
 4  nic.ddn.mil (26.0.0.73)  340 ms  720 ms  360 ms

- Phil
-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 90 17:08:24 GMT
From:      usenet.ins.cwru.edu!cwjcc!ncoast!sgtech!adnan@tut.cis.ohio-state.edu  (Adnan Yaqub)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip for 386 UNIX
In article <825@unix386.Convergent.COM> markb@unix386.Convergent.COM (Mark Beyer) writes:

   In article <1990Feb2.154728.17877@ico.isc.com>, dougm@ico.isc.com (Doug McCallum) writes:
   > In article <1990Feb1.052144.27172@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes:
   > ...
   > AT&T's TCP/IP is based on the Wollongong port and not the Lachman port.

   In which release ?  SVR4 is definitely the Convergent/Lachmann port.

For one, in 3.0.  I have a manual in front of which says: "AT&T
Enhanced TCP/IP WIN/386 Release 3.0" which talks about "Wollongong
Socket Compatibility Library Routines".
--
Adnan Yaqub
Star Gate Technologies, 29300 Aurora Rd., Solon, OH, USA, +1 216 349 1860
...cwjcc!ncoast!sgtech!adnan ...uunet!abvax!sgtech!adnan
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 90 17:16:33 GMT
From:      usenet.ins.cwru.edu!cwjcc!ncoast!sgtech!adnan@tut.cis.ohio-state.edu  (Adnan Yaqub)
To:        tcp-ip@nic.ddn.mil
Subject:   Authentication for SNMP - Are there any standards?
In reading the SNMP RFCs I find mention of authentication of PDUs.
Are there any standards for authentication mechanisms.  For example,
if I make a widget which has a SNMP agent in it, how should I treat
the issue of authentication so as to maximize the number of
communities in which my product can be sold?  Are most networks going
to do trivial (read no) authentication?  What does the NYSERnet
(What's their new name? Performance something or another?) code do?
IMHO it seems dangerous to run a network with trivial authentication,
and thus allow complete strangers to reboot network entities at will.
--
Adnan Yaqub
Star Gate Technologies, 29300 Aurora Rd., Solon, OH, USA, +1 216 349 1860
...cwjcc!ncoast!sgtech!adnan ...uunet!abvax!sgtech!adnan
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Feb 90 23:29:02 EST
From:      timsmith@Sun.COM (Timothy G. Smith - Technical Consulting)
To:        tcp-ip@nic.ddn.mil
Subject:   Mr. Morris (again...)
The following text is a letter to the editor that was published in the
Tuesday, Feb. 6, 1990 issue of "The Capital".  "The Capital" is the
local paper in the Annapolis MD area.  RTM's parents live a few miles
north of Annapolis so the Worm and the trial were of interest to some
of the locals.

I am sending this out to the tcp-ip mailing list for informational
purposes.  Some might be amused, some might be annoyed, some might not
care.  I thought the letter's content was was worth passing on to the
rest of the net who are not priviledged enough to get home delivery of
"The Capital".

Please do not start the
virus/worm/it_was_bad/it_was_good/hang_him/give_him_a_medal thing
again.  

Yes this is a real letter.  For those folks who want to verify the
existence of this letter "The Capital" can be reached at (301)
268-5000.

I hope I have not violated any copyrights or whatever by typing this
in and posting it.

enjoy,
        Tim Smith - Technical Consultant
US mail:Sun Microsystems        E-mail:
        6797 Dorsey Road                internet:tgsmith@east.sun.com
        Suite 4                         uucp    :sundc!tgsmith
        Baltimore, MD 21227
MaBell :(301)379-5000

NB:  The usual applies... I take sole responsibility (and claim) for
this message - except for the stuff below which I typed in from the
newspaper.


Letter to Editor follows:
###########################################################################
Support Morris

Robert Morris, the recently convicted computer hacker, is the son of a
dedicated, loyal public servant who pioneered in alerting the computer
community to potential security problems, including viruses.
Fortunately - or unfortunately, depending on how you look at recent
events - the son accomplished with one dramatic indiscretion what his
father has worked to do for years - everyone now knows of the
dangers!  Nevertheless, Robert's father was very upset at his son's
action.

The jury was right to return a guilty verdict, but the felony charge
seems excessive.  Certainly we cannot allow anyone to get away with
gaining unauthorized access to computer systems.  It was poor judgment
on the son's part, but was not done maliciously.

Robert has already suffered enough for his computer experiment.  He
has over $100,000 in legal bills, been kicked out of graduate school,
lost his scholarship, and is now a convicted felon with diminished
civil rights.  Further punishment would be cruel and inhumane, and a
waste of an extraordinary talent which this country needs.  I hope and
pray the judge realizes this when he decides on Robert's sentence.

For those who lost hours of work - if you ignore this alert, your next
loss through system failure, power failure, hacking or sabotage might
be far more devastating.  The "public health" message for the computer
community is this: if your computer interfaces with another computer,
it also interfaces with all the computers that one interfaces with.
Put an electronic condom on it, becuase the next virus might be fatal.

To those who are concerned about the nation's security - take heart!
Many computers at facilities around the country, and all classified
networks, have virus "shields" to protect them.  The Morris virus did
not infect them.

Robert Morris - and the world- have learned valuable lessons through
all of this.  Let's leave it at that!

In the meantime, however, the kid is broke!  If you would like to help
him, please send a contribution to The Robert T. Morris Legal Defense
Fund, P.O. Box 44132, Washington, D.C. 20026-4132.

Loriel S. Bieri
Arnold
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 90 18:43:52 GMT
From:      laba-1ee@e260-4g.berkeley.edu (Gary H. Aochi)
To:        comp.protocols.tcp-ip
Subject:   How to prepare files for execution

How do you de-arc files from simtel20?
I retrieved some files of the form:
	EMACS15E.ARC.2
		     ^
		     |
		     What is this?

I am currently storing these files, retrieved tenex mode, in a UNIX system 
account, but would like to download the files for use on my PC (the files are
for the PC).  I know about arc, tar, compress (Z), zip...but what 
is _that_ number?

Can someone please help me....none of the files are ASCII text.

please e-mail me directly

Thanks, 
Gary H. Aochi

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Wednesday, 7 February 1990 00:21:15 EST
From:      Gene.Hastings@boole.ece.cmu.edu
To:        craig@cwh.cam.nist.gov (Craig Hunt)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Getting a commercial firm into Internet
Merit (nsfnet-info@merit.edu) and the NNSC (NSFNET Network Service Center,
nnsc@nnsc.nsf.net) can both supply information on regional "mid-level"
networks whom your associates might subscribe to. They would need to know the
location of the prospective client.

Gene


-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 90 19:31:08 GMT
From:      acd4!smm@uunet.uu.net  ( Steve McCoole )
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP for Ultrix 3.1

   We used to have a version of SLIP from ucb that would work on an 
Ultrix 2.3 system.  With the changes to 3.1 it no longer works due
to massive changes in the internal structures of the kernel.  We
have looked at the SLIP that DEC supplies with Ultrix and tried it
but it will only allow one connection per link, which isn't really
useful.  We also do not have Ultrix source so changing the old driver
is not very likely either.

   The question is then, could anyone please direct us to a PD 
version of SLIP that will run on Ultrix 3.1 machines?  It would
also be wonderful if the code would work on the DEC RISC machines.
Please e-mail any information that you might have to me and I will
summarize the net if there is interest.

Thanks in advance!

Steve McCoole
Applied Computing Devices
uunet!acd4!smm
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 90 22:05:02 GMT
From:      pluto!lfischer@nyu.edu  (Larry Fischer)
To:        tcp-ip@nic.ddn.mil
Subject:   snmp authenticate
Can anyone shed some light on the authentication process used in SNMP?
I have some manuals but they arent quite clear... Does it always get done?
need it always get done?  Is there one method or one of many? and if many
how does one decide what is being used...

Thanks in advance
Lawrence Fischer
    
-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 90 00:01:41 GMT
From:      zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!murtoa.cs.mu.oz.au!ditmela!yarra!melba.bby.oz.au!leo!gnb@tut.cis.ohio-state.edu  (Gregory N. Bond)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: DNS Query server?
In article <9002022140.AA16279@jessica.Stanford.EDU> almquist@JESSICA.STANFORD.EDU ("Philip Almquist") writes:

	   Another problem with IEN-116 is that I've never seen a
   publicly-available IEN-116 resolver, so you'd probably have to write
   your own.  Since it's a different protocol than DNS, you need to change
   rather more than just the port number in your DNS resolver to get it to
   work.

Well, the Xylogics annex terminal server can also use an ien-116 name
service, and comes with source for an ien-116 daemon that is derived
from Berkeley software (it has a UCB copyright).  So check the
berkeley network sources.  (It is probably called named).  Also, most
4BSD-based systems come with an ien-116 server enabled in the inetd
configuration, so you may have it and just not know it.  (I know this
is true of SunOs 3.5 and 4.0).

Greg, who is in the process of installing an annex!
--
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: gnb@melba.bby.oz.au    non-MX: gnb%melba.bby.oz@uunet.uu.net
Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnb
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 90 00:26:50 GMT
From:      ingr!b11!heller@uunet.uu.net  (Anne Heller)
To:        tcp-ip@nic.ddn.mil
Subject:   UDP bind question

I have a question regarding binding to ports in UDP.  Is it generally 
acceptable to allow binding more than once to a given port?  (I know about the 
SO_REUSEADDR option in sockets, but we have a STREAMS implementation
which complies with the AT&T Transport Provider Interface (TPI) standard,
so not everyone is accessing UDP through sockets.)

I'm sorry if this is a naive question, but I did not find anything addressing
this issue in RFC768 (User Datagram Protocol) or in the RFC1122
(Requirements for Internet Hosts - Communication Layers).

Thanks,
Anne A. Heller	
--
uucp:...!uunet!ingr!b11!heller!heller
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 90 01:08:27 GMT
From:      n8emr!vlink01!steve@tut.cis.ohio-state.edu  (1770 MCI)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP
I apologize for being so ignorant, but what is tcp-ip?  What is it run
on, is like uucp or what?

Thanks.


-- 
|UUCP Mail : osu-cis!vlink01!steve     |Vlink                |
|MCI Mail  : uucp!mcimail.com!368-5882 |Steven E. Frazier    |      
|ATT Mail  : attmail!vlink01!steve     |1828 Darrow Drive    |
|Voice Mail: 614-755-3772              |Powell, Ohio  43065  |
-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Wed, 07 Feb 90 09:46:43 -0500
From:      "Martin Lee Schoffstall" <schoff@psi.com>
To:        craig@cwh.cam.nist.gov (Craig Hunt)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Getting a commercial firm into Internet
PSI is providing networking services (NYSERNet, CAPNet) throughout
the NorthEast and MidAtlantic states and internationally. Contact
info@psi.com.

Marty
----------------

 One of our network users, who is doing extensive work with a commercial
 firm, asked how that firm could have access to the Internet. Does
 anyone know who is offering a service to connect commercial users into
 Internet services.  I suggested UUNET and CSNET.  I also thought
 perhaps Merit. Suggestions, contacts, addresses would all be
 appreciated.

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 90 01:28:45 GMT
From:      ccncsu!longs.LANCE.ColoState.Edu!steved@boulder.colorado.edu  (Steve Dempsey)
To:        tcp-ip@nic.ddn.mil
Subject:   traceroute for Ultrix3.1 (wasRe: Problem with TCP/IP to remote sites)
In article <276@jove.dec.com>, mogul@decwrl.dec.com (Jeffrey Mogul) writes:
> In article <6227@cps3xx.UUCP> nanda@cpsvax.cps.msu.edu (Arun Nanda
{manager}) writes:
> >[ problem with timeouts ]
> 
> This sounds to me like your TCP datagrams are being sent with a TTL
> (Time to live in the IP header) that is too small....
> 
> from decwrl.dec.com to your host cpsvax.cps.msu.edu is 14 hops; you
> can discover this by using the "traceroute" command that is floating
> around in the public domain.

I've been trying to get traceroute running under Ultrix 3.1 to no avail.
I don't have Ultrix source (yet), but do have 4.3BSD source.  My 4.3
machine is in a *very* unstable state (can't even gen a kernel any more)
and is on its way out the door anyway.  I used the 4.3 net code to build
the Ultrix kernel, but the system crashes after running traceroute a couple
of times.  All other network utilities work fine.  Any ideas?
And where are the latest traceroute sources kept?


        Steve Dempsey,  Center for Computer Assisted Engineering
  Colorado State University, Fort Collins, CO  80523    +1 303 491 0630
INET: steved@longs.LANCE.ColoState.Edu, dempsey@handel.CS.ColoState.Edu
UUCP: boulder!ccncsu!longs.LANCE.ColoState.Edu!steved, ...!ncar!handel!dempsey
-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Feb 90 09:54:59 -0500
From:      Stephen Wolff <steve@cise.nsf.gov>
To:        craig@cwh.cam.nist.gov, tcp-ip@NIC.DDN.MIL
Cc:        hahn@umdc.umd.edu, rick@ns.uu.net, schoff@psi.com
Subject:   Re:  Getting a commercial firm into Internet
CSNET has merged with BITNET; the result is called CREN.

There are conditionss under which the firm might be eligible for a connection
to SURANET; contact Jack Hahn 301 454 5434 or hahn@umdc.umd.edu.

In addition to UUNET/AlterNet (Rick Adams, <rick@ns.uu.net>), they should
consider PSI; contact Marty Schoffstall <schoff@psi.com> in Reston, VA.

-s

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Feb 90 12:19:37 EST
From:      Jim Fullton <fullton@samba.acs.unc.edu>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re:  SLIP FOR ULTRIX

	I read that......  I have seen other postings that indicate that a good SLIP
isn't available...  I'll keep looking...

	Jim
-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 90 12:01:58 GMT
From:      zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!wb3ffv!fallst!tkevans@tut.cis.ohio-state.edu  (Tim Evans)
To:        tcp-ip@nic.ddn.mil
Subject:   SCO TCP/IP Driver for 3c505
Does anyone have a driver for the 3Com 3c505 which will allow SCO's
TCP/IP (SCO Xenix 2.3, specifically) to work?  Thanks.
-- 
UUCP:		{rutgers|ames|uunet}!mimsy!woodb!fallst!tkevans
INTERNET:	tkevans@wb3ffv.ampr.org
Tim Evans	2201 Brookhaven Ct, Fallston, MD 21047  (301) 965-3286
-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 90 13:11:09 GMT
From:      news@psuvax1.cs.psu.edu  (Daniel Ehrlich)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Inetd Discard on SunOS4
In article <131187@sun.Eng.Sun.COM> melohn@sluggo.Sun.COM (Bill Melohn) writes:

Bill> All of the internal services are included in /etc/inetd.conf in SunOS 4.1.

You did not answer the original question.

--
Dan Ehrlich <ehrlich@cs.psu.edu>
Voice: +1 814 863 1142	FAX: +1 814 865 3176
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 90 18:01:37 GMT
From:      auspex!guy@uunet.uu.net  (Guy Harris)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: rsh vs remsh -- how does one handle the name conflict?
>Since SVR4 is merging in the BSD networking utilities (to some extent,
>anyway), I would think that AT&T has already had to deal with this
>behaviour. Could someone familiar with SVR4 comment on this?

In S5R4 "/usr/bin/rsh" or maybe "/usr/ucb/rsh" is the Remote SHell;
"/usr/lib/rsh" or something off in the corner like that is the
Restricted Shell.
-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 90 18:45:52 GMT
From:      amdahl!rtech!wrs!hwajin@ames.arc.nasa.gov  (Hwa Jin Bae)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip for 386 UNIX
In article <ADNAN.90Feb6170824@sgtech.UUCP> adnan@sgtech.UUCP (Adnan Yaqub) writes:
   For one, in 3.0.  I have a manual in front of which says: "AT&T
   Enhanced TCP/IP WIN/386 Release 3.0" which talks about "Wollongong
   Socket Compatibility Library Routines".

The Wollongong stuff is based on the LAI TCP/IP stuff.  I know cause I've
looked at the sources.  The V.4 will have LAI TCP/IP stuff too.  Trust me.

--
Hwa Jin Bae, Wind River Systems, 1351 Ocean Avenue, Emeryville, CA 94606, USA
hwajin@wrs.com (uunet!wrs!hwajin)   "Omnibus ex nihil ducendis sufficit unum."
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 90 19:15:44 GMT
From:      van-bc!ubc-cs!alberta!mts.ucs.UAlberta.CA!ualtavm!DKRUGER@ucbvax.Berkeley.EDU  (Dwight Kruger)
To:        tcp-ip@nic.ddn.mil
Subject:   Packet driver for WD8003/A card
We are using the Clarkson packet drivers on our PC and PS/2 machines to
access the campus ethernet with the NCSA tn3270 and FTP applications.
 
The Clarkson drivers function properly with WD8003E and WD8003ET/A cards,
but not with the newer WD8003E/A card.  Both the WD8003ET/A and WD8003E/A
cards are for microchannel machines.
 
Does the Clarkson packet driver support the WD8003E/A card?  The documentation
makes no mention of it.  If not, is there an update to the packet driver for
use with the WD8003E/A card?
 
Dwight Kruger
Network Software Development
University Computing Systems
University of Alberta
-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 90 20:30:04 GMT
From:      uwm.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!delta!Delta.CS.MsState.Edu!peters@lll-winken.llnl.gov  (Frank W. Peters)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: DNS Query server?
In article <9002051330.AA00323@cheops.columbia.sparta.com> hsw@SPARTA.COM (Howard Weiss) writes:

   From: hsw@SPARTA.COM (Howard Weiss)
   Newsgroups: comp.protocols.tcp-ip
   Date: 5 Feb 90 13:30:23 GMT

   Actually, I believe that what Frank Peters was looking for was
   the service that host 128.218.1.109 provides on port 5555 - you
   simply connect to that host at that port, type in a fully formed
   internet host name and it responds with an internet address and
   closes the connection.  I used it when I had a host that still
   only had /etc/hosts and it did just what I needed - which was
   basically a manual nslookup.

Yes!  This is exactly what I want!  We're working on some networking
code on a UNISYS 1100 system that runs an operating system called
Exec8, doesn't have a C compiler or socket library and which has NO
usable hosts file system (as near as I understand it the hosts file is
compiled into the it's front-end-processors OS...so the FEP has to be
rebooted to add a new host to the table!!).

But enough about our troubles.  Where can I get a copy of the above
software?  the machine referenced above doesn't have an anonymous FTP
and the only machine at ucsf that I can find which does have anonFTP
(ccb.ucsf.edu) doesn't seem to have it either.

Any ideas?

--Frank

Frank W. Peters        Systems Programmer     Computing Center & Services
peters@CC.MsState.Edu  Peters@MsState.Bitnet  (601)325-2942
"I can't give you brains, but I can give you a diploma." -- The Wizard of OZ
-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 90 22:09:22 GMT
From:      elroy.jpl.nasa.gov!zardoz.cpd.com!dhw68k!fedeva!cpb9182@ames.arc.nasa.gov  (Claude Bowie)
To:        tcp-ip@nic.ddn.mil
Subject:   RS-422 Terminal Server
Does anyone know any vendors who make RS-422 terminal servers?

I have a requirement to network a large number of industrial
async terminals using ethernet over broadband. the particular
terminal I am using has both RS-232 and RS-422 interfaces
on the primary port.  However, the terminals are pretty widely
dispersed and I may really need to use the RS-422 in order for
a terminal server to connect to multiple terminals.

thanks,

claude


-- 
+---------------------------------------------------+----------------------+
! Claude Bowie FEDERAL EXPRESS Memphis, TN          #  "Ok you guys, quit  !
![..!hplabs!csun,..!mit-eddie!premise]!fedeva!bowie # clowning around and..!
+---------------------------------------------------+----------------------+
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 90 22:39:49 GMT
From:      zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!aero!ctw@tut.cis.ohio-state.edu  (Charles T. Wolverton)
To:        tcp-ip@nic.ddn.mil
Subject:   SMTP-X.400 Gateways
Would appreciate help on identifying vendors of subject gateways. Tnx.

**** charles wolverton    aerospace corp.   ctw @aerospace.aero.org
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 90 22:54:35 GMT
From:      amdahl!rtech!wrs!hwajin@apple.com  (Hwa Jin Bae)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP bind question
In article <7391@b11.ingr.com> heller@b11.ingr.com (Anne Heller) writes:
   I have a question regarding binding to ports in UDP.  Is it generally 
   acceptable to allow binding more than once to a given port?  (I know
   about the SO_REUSEADDR option in sockets, but we have a STREAMS
   implementation which complies with the AT&T Transport Provider
   Interface (TPI) standard, so not everyone is accessing UDP through sockets.)

It doesn't really matter whether you use sockets or TLI interface to access
the UDP/IP.  The system calls (whether you use bind() or t_bind()) get turned
into STREAMS messages as they pass through the STREAM heads with types that TPI
multiplexor module understands (in case of bind request it would be
T_BIND_REQ type).  Upon receiving such messages TPI multiplexor module will
call protocol specific bind routine to handle the bind request and return 
the result of such binding.  This sequence of kernel events is identical
for both TLI and socket based requests.

--
Hwa Jin Bae, Wind River Systems, 1351 Ocean Avenue, Emeryville, CA 94606, USA
hwajin@wrs.com (uunet!wrs!hwajin)   "Omnibus ex nihil ducendis sufficit unum."
-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90 00:24:32 GMT
From:      mitel!sce!xicom!alexr@uunet.uu.net  (Alex Laney)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Ethernet Throughput (AMD vs. Intel vs. Seeq)
In article <29000@amdcad.AMD.COM> ncpmont@amdcad.UUCP (Mark Montgomery) writes:
>In article <582@berlioz.nsc.com> andrew@dtg.nsc.com (Lord Snooty @ The Giant Poisoned Electric Head       ) writes:
>><2447@ncr-sd.SanDiego.NCR.COM>, ward@babel.SanDiego.NCR.COM (Ed Ward 2337) :
>>> I'm looking for some information comparing the Ethernet throughput of the 
>>> AMD lance, Seeq 8005, and Intel 82??? controller chips....
>>
>>I'd look at National's NIC too - they practically own the Enet market.
>>-- 
>>...........................................................................
>>Andrew Palfreyman	andrew@dtg.nsc.com	Albania before April!
>
>Whoa, boy!	I think that the statement "they practically own the Enet
>market" is a bit rash.	Check with IBM, DEC, SUN or 3COM or look inside their
>boxes.  I think you'll find that there are about twice as many AMD LANCE, SIA
>and XCVR chips in them as all those other manufacturers have sockets combined.
>"LOOK AGAIN" to quote the T.I. speak n' spell chip.		Mark

The figure is: about 85% of the Ethernet chipset market is supplied by
Nat. Semi. Surprising but true ... I know for certain that Western Digital
and others use the Nat. Semi chipset. How many chips does DEC use compared
to the IBM PC and compatible market( Novell, etc.)?

It's an independent figure from Dataquest or some organization like that.

-- 
Alex Laney, Xicom Group, National Semiconductor, Ottawa, Canada (613) 728-9099
uunet!mitel!sce!xicom!alex (alex@xicom.uucp)     Fax: (613) 728-1134
"You save time, increase the amount of work done and it is easy."
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90 01:10:41 GMT
From:      zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!sirius.ucs.adelaide.edu.au!mikeb@tut.cis.ohio-state.edu  (Mike Byrne)
To:        tcp-ip@nic.ddn.mil
Subject:   SMTP gateway for cc:Mail under Netware 386
We are currently installing six Netware 386 servers on campus.
We have been recommended cc:Mail as an appropriate E-Mail package.

        1. Does anyone have any experience with this product ?

        2. Is there an SMTP gateway available (under development ?) ?


__________________________________________________________________________
Mike Byrne                              PHONE:  +61-8-228-5110
Microcomputer Support                   FAX:    +61-8-224-0464
The University of Adelaide              E-MAIL: mikeb@ucs.adelaide.edu.au
GPO Box 498  ADELAIDE 5001
SOUTH AUSTRALIA
__________________________________________________________________________
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90 02:28:40 GMT
From:      mojo!smaug@mimsy.umd.edu  (Kurt Lidl)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SMTP gateway for cc:Mail under Netware 386
In article <759@sirius.ucs.adelaide.edu.au> mikeb@ucs.adelaide.edu.au (Mike Byrne) writes:
>We are currently installing six Netware 386 servers on campus.
>We have been recommended cc:Mail as an appropriate E-Mail package.
>
>        1. Does anyone have any experience with this product ?

	I used this package on a PC based network when I worked for
the military.  The network was a Nestar PLAN (Personal LAN) environment,
which caters to *none* of the other PC style networks.  On the other
hand, it allowed booting off the network server and was reasonably
fast.  At any rate, that is the environment.
	The company that makes cc:Mail ported their code to this
network, wrote a driver for it and then polished the code.  We initially
were running release 2.0 and then upgraded to 3.0 -- both were
remarkably bug-free!  Mostly enhancements to the software, not
just bug-fixes.
	The software that we were using was *extremely* slick, fast
and colorful (we had a base config on the machines of 8Mhz 286's,
EGA and Multi-Sync monitors).  The facilities for including files
in messages (binary and so forth) were execellent.  One drawback --
a maximum of 25 files in a single message.  A pain when trying to
get a lot of GIF files from one network account to the other...
	I don't know how the files were encapsulated -- I suspect that
if you cannot ensure 8 bit data, you cannot ensure sending binaries
all over creation...
	On our system (I am not sure if this is an artifact of having
it on our special kind of network server or not) they mail storage
area was a pre-created database of some type -- we endded up
devoting a small (65 meg Plan 3000 fileserver) to dedicated mail
handling -- it worked very well.
	Hopefully the company has continued their excellent software
writing.  I think that this is the single piece of PC based software
that I really enjoyed using.  Please send me any collection
of responses that you get from the net.  Thanks.

>        2. Is there an SMTP gateway available (under development ?) ?

	As I understand it, they were working on a gateway into
other mailing systems, but I do not have *any* experience with it at
all.  Sorry.

>Mike Byrne                              PHONE:  +61-8-228-5110

--
/* Kurt J. Lidl (smaug@eng.umd.edu) | Unix is the answer, but only if you */
/* UUCP: uunet!eng.umd.edu!smaug    | phrase the question very carefully. */
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90 06:02:17 GMT
From:      amdcad!pepsi.amd.com!remaker@ucbvax.Berkeley.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   TN3270 for PCs/MACs, Summary Posting
As promised, here is a consolidated list of replies to my request for 
information on PC/MAC tn3270 packages, Edited for length.  I was informed that
the query belonged in comp.protocols.tcp-ip.ibmpc, but an overwhelming response 
from people saying "YES! I need to do that too!" has prompted me to post this.
A pointer message will be posted to comp.protocols.tcp-ip.ibmpc.

Thanks for your help, everyone.  The net is an indispensable resource.  I hope
people find this useful.  The general consensus is that clarkson is doing the
most whiz-bang tn3270 for a pc, and Brad Clements himself tells me a PC-NFS com-
patible version is in the works.  I haven't actually tried any of these 
solutions below, but this information is a good starting point.

Enjoy, 
Phil remaker@bach.amd.com
________________________________________________________________
rom: manoj@xlnvax.excelan.com (manoj @ Prod Mktg)
Subject: TN3270 for a PC (fwd)
To: remaker@pepsi.amd.com
Date: Wed, 24 Jan 90 9:33:59 PDT

Novell excelan offers a package for tn3270 at your dos & os/2
for dos, it also offers NFS client at the dos machine..
i will send you some literature..

________________________________________________________________
From: Mark Eggers <meggers@uci.edu>
Subject: Re: TN3270 for a PC
Date: Wed, 24 Jan 1990 11:29:47 PDT

There is really nothing that will work at the same time as Sun's PCNFS.  
You have two choices with a PC that I know of.

1.     Clarkson's modified NCSA Telnet, available via anonymous FTP from omnigate.clarkson.edu.  No NFS, however.

2.     PC/TCP from FTP Software, Inc.  This is about $400 per machine without        NFS, and $600 with NFS.  It has everything (tn3270, VT100, VT220, rcommands etc.). I don't have the address at my desk, but could dig it up if you can't find it.

Macintoshes - there are two packages, neither of which support NFS.  There 
is a real problem with NFS and the Macintosh.

1.     tn3270 from Brown University. Available via anonymous ftp from a 
variety of places, including brownvm.brown.edu and zaphod.ncsa.uiuc.edu.  Quite nice.

2.     Amada Walker's company (Intercom, I think), has a commercial 
version.  Basically, it's NCSA Telnet plus a lot of bells and whistles.  Don't know about the cost.


hope this helps - /mde/


______________________________________________________________
FROM REAME FILE AT CLARKSON:

This software is available via E-Mail. For information on how
to obtain a copy via email, send mail as follows:

	mail archive-server@sun.soe.clarkson.edu
	Subject:

	path  <your return address in internet form goes here>
	send ncsa2.2tn Index
	^D
The archive server has 8 uuencoded files that can be reassembled
into ncsabin.tar.Z and 13 uuencoded files that can be reassembled
into ncsasrc.tar.Z.  The documentation is also available via
the archive server. In this distribution no uuencoded file
is larger than 75K bytes. Be sure to use the path command in
your request to the archive server to ensure proper reply addressing.

Comments, bugs and suggestions to
	Brad Clements
	Network Engineer
	Educational Resources Center
	Clarkson University
	Potsdam, NY 13676
	(315)268-2292  
__________________________________________________________________
Date:         Thu, 25 Jan 90 17:21:22 EST
From: Doug Nelson <ucbvax!jade.berkeley.edu!08071TCP%MSU.bitnet>

As for PD TN3270s, I know of NCSA Telnet for the PC, and Brown University
for the Mac.  If you want one that coexists with NFS, your best bet may be
to go with FTP Software, Inc., which has an excellent TCP/IP package for the
PC, and now has a PC-NFS work-alike called InterDrive.

Doug Nelson
Manager of Network Software
Michigan State University
___________________________________________________________________
rom: mmccann@hubcap.clemson.edu (Mike McCann)

TN3270 for the Mac can be found at zaphod.ncsa.uiuc.edu.  If you find TN3270
for the IBM, please let me know.

Thanks,
Mike McCann
___________________________________________________________________
Date:     Wed, 24 Jan 90 11:26:14 EST
From: Brad Clements <ucbvax!omnigate.clarkson.edu!bkc>
To: amdcad!pepsi.amd.com!remaker
Subject:  Re:  TN3270 for a PC
Status: RO

Clarkson has a version of NCSA that does TN3270 on the PC. However you can
have only one 3270 session active at a time.

Currently it doesn't run under PC-NFS, but I have a beta version that sorta
runs under PC-NFS

If you'ld like to try it when its ready, I'll add you to the list of test sites.

_____________________________________________________________________
From: Chris Ranch <apple!csr@ubvax>
Subject: Re: TN3270 for a PC

Hello,

Ungermann-Bass sells MacUWS, currently supporting multiple session telnet using
VT100 and TTY emulation, + FTP, and scripting front end (sophisticated).

We are in the process of identifying alpha/beta sites for the next upgrade
which will include VT220, tn3270, Tandem 6530, and tn6530.  Also UB network 
management support for the mac workstation.  Testing will start in a few weeks.

Mail back if your interested,


-- 
Chris Ranch
Ungermann-Bass, Inc
(408)562-7957      csr@ubvax.ub.com
_______________________________________________________________________
From: Jeffery Bacon <BACON%MTUS5.BITNET@CUNYVM.CUNY.EDU>

     Boy, you want a miracle.
     We also run Sun's pcnfs stuff here, mostly on ibm pc/xt's running
3com 3c503 cards, but also on ps/2-30's using 3c501's and some Zenith 386's,
and we would like the same connectivity. Unfortunately, we haven't found it.
Sun doesn't offer anything, and while they've made some noise about it here
and there, we have yet to see line one of code or binary one.
     What you can do, however, for some limited instances, is run NCSA telnet.
There's a 3270 version of that floating about; it's all ftp'able from
I think omnigate.clarkson.edu or sun.soe.clarkson.edu. These use the FTP-spec
packet drivers, or can talk straight to the cards itself (in the instance of
the 501 or some other cards). There's also a patch to allow pcnfs to use the
packet driver interface. However, you can only do one or the other, not both -
pcnfs hogs the packet driver, so that ncsa can't access it. If you have a
hard drive local, or want to swap a floppy, tho, it IS an option. If you need
more details, write. We don't use it here too all much - we can telnet to
a Sun and run tn3270 there, or a lot of pc's have 7171 direct access to our
mainframe - but it's a valid option.


Jeffery Bacon -- Computing Technology Svcs., Michigan Technological University
email- bacon@mtus5.bitnet       voice: (906)487-2110        fax: (906)487-2787
alternate-  uucp: <world>!itivax!anet!bacos  domain: bacos%anet@itivax.iti.org
_____________________________________________________________________
From: Alan Strassberg <lstc!oetl1.SCF.LOCKHEED.COM!alan@uunet.UU.NET>

	Did you get an answer to your question ? My suggestion
	would be PC-NFS from Sun with any one of the tcp/ip
	packages (ka9q, pc-ip, ncsa). These should co-exist easily.
	BTW, you're question better belongs in comp.protocols.tcp-ip.ibmpc.
	And there's a tn3270 for the mac also.

	email back if you need more info.

				alan

-- 
Alan Strassberg             alan@oetl.scf.lockheed.com
(408) 425-6139              ...!uunet!lstc!oetl!alan 

_____________________________________________________________________
Date:         Tue, 30 Jan 90 13:27:32 EST
From: Doug Nelson <ucbvax!jade.berkeley.edu!08071TCP%MSU.bitnet>

>Thanks for the help.  I may look into the PCNFS workalike.
>
>I hate the serial # broadcasts and its bulky size.
>
>Do you know about this package?

If you mean FTP Software's PC/TCP and InterDrive, yes, I know plenty about
it.  We have a site license for both, although we haven't yet delivered
InterDrive to our users.  The PC/TCP product is stable, and works well.
I use its TN3270 almost constantly (including this very moment).  InterDrive
is a new product, and is still missing a couple features, such as file
locking.  It also suffers from performance problems.  I expect them to
solve both of these problems within a couple months, though.  The company
itself is very reponsive to its customers.

Doug

________________________________________________________________________
Phillip A. Remaker A.M.D. M/S 167 P.O. Box 3453 Sunnyvale, CA 94088-3000
remaker@amdcad.amd.com  Cutting Edge Networking...Close to the Jugular...
"It's only work if someone makes you do it."  -Calvin
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90  13:20 EST
From:      mmorse@NSF.GOV
To:        tcp-ip@NSF.GOV
Subject:   Mailbridge between the Internet and cc:Mail (PC LAN package)
   This subject comes up fairly frequently, so I'm risking violating
net etiquette by posting the answer to the net rather than just to the
asker (mikeb@ucs.adelaide.edu.au).  This is the standard message I've
been sending out on this subject (it's written for people who know
PCs, not UNIX or TCP/IP):

(Updated March 28, 1989)

        This message describes a mail gateway at NSF that transfers
mail between cc:Mail and the research and academic networks
(primarily the DARPA/NSF Internet and BITNET).  I've also
enclosed limited information on similar gateways running at Proteon
and other sites.

        The gateway used at NSF was adapted from the gateway
developed by Al Marshall at Proteon, Inc.  

What is cc:Mail?

        cc:Mail, a commercial product, is an electronic mail system that
runs on PC's connected to a LAN.  All the executable code runs on
the PC's and mail is exchanged by accessing a database on a LAN file
server.  cc:Mail runs on a variety of LAN hardware and software,
including any LAN system that provides DOS with virtual drives.  It
is currently (March '89) limited to MS-DOS PC's; however, a
MacIntosh version has been announced.  Compared to typical time-
sharing mail implementations it is inexpensive, fast, well-documented,
and user-friendly.  It is easily installed and most users will not require
any training to use it.

        cc:Mail uses a proprietary message format and transfer
protocol, but "import" and "export" utilities are provided to allow the
transfer of mail with other systems.  More information about cc:Mail
can be obtained by contacting the vendor at 800-448-2500.

Hardware and Software Environment

        At NSF the gateway is implemented on a PC running MS-DOS
and a VAX running UNIX.  The PC does not talk directly to the
research and academic networks.  It transfers mail through the UNIX
machine which has links to the Internet, BITNET, and UUCP.  Any
host that can be accessed from the UNIX machine can be addressed
from cc:Mail.  For this document, the PC will be referred to as the
"Gateway PC," and the UNIX machine as the "Internet Host."

        The Internet Host is a VAX 785 running Ultrix.  It runs
MMDF (Multi-Channel Memo Distribution Facility) for its MTA
(Mail Transport Agent).  MMDF is supported by CSNET (Computer
Science Network).  It performs essentially the same functions as
sendmail on many UNIX computers.

        The Gateway PC is a PC AT clone.  It communicates at 9600
baud with the Internet Host using an asynchronous protocol known as
Phonenet.  The software to support Phonenet on the PC is PMDF
(MMDF in Pascal).  PMDF is licensed software available to CSNET
members, or directly from the University of Pennsylvania.  The
Gateway PC is also on the 3COM LAN that supports cc:Mail at NSF.

        Software on the PC provides translation of the mail between
the Internet format (RFC 822) and the proprietary cc:Mail format. 
Address resolution and final delivery is accomplished on the UNIX
machine.

Addressing

        The cc:Mail system uses real names for addresses, and its
directories and documentation expect this.  What RFC 822 users
would think of as a "host name" is called a "Post Office" in cc:Mail. 
A typical address on cc:Mail looks something like this:

     Michael Morse at NSF-DC

        Internet addresses look something like this:

                mmorse@note.nsf.gov

        The approach taken at NSF was to ignore the real-name bias
of cc:Mail and refer to users in cc:Mail by their UNIX usernames. 
The reasons for this are mostly historical:  All NSF employees already
had usernames that they used on the UNIX mail system and were
known by on the Internet.  Also, at the time the gateway was
developed cc:Mail had no aliasing capability.  In addition, NSF's
connection to the BITNET limits usernames to eight characters.

Addressing cc:Mail Users from the Internet

        The cc:Mail users are addressed exactly as if they were using
the Internet host for mail, so mail to me, for example, is addressed as
follows:

                mmorse@note.nsf.gov

        Mail is transparenetly directed to the Gateway PC using the
aliasing feature of MMDF.

Addressing Internet Users from cc:Mail

        A special cc:Mail Post Office called "INTERNET" (at Proteon
it's called "ARPA") is set up.  To send mail to the Internet, cc:Mail
users select that Post Office.  The cc:Mail system then prompts them
for the Internet address.  The address is combined to look something
like this:

                lforest@terp.umd.edu at INTERNET

Return Addresses

        The gateway ensures that mail in both directions is "replyable." 
Mail coming into cc:Mail has "at INTERNET" appended to the return
addresses.  Mail going out from cc:Mail carries the return address of
the Internet Host (note.nsf.gov).

Binary File Transfer

        The cc:Mail system allows users to easily attach PC files (text
or binary) to messages.  The gateway encodes attached files into 7-bit
ASCII using the uuencode scheme originally developed in the UNIX
environment.  Incoming uuencoded files are similarly decoded into
cc:Mail file attachments.

Implementation Details

        The Gateway PC runs 3COM 3+ drivers to access the file
server for cc:Mail, and uses its serial port to communicate with the
Internet Host using the Phonenet protocol.  The PC runs a batch file
that repeatedly runs the following steps:

  1)    It runs the cc:Mail EXPORT utility to collect (onto its local
     disk) the mail for the Internet Host.

  2)    It translates the mail to Phonenet format and builds a file for
     each message in the Phonenet queue directory.

  3)    It runs the Phonenet MASTER program that logs onto the
     UNIX machine and delivers and receives mail.

  4)    It looks for incoming mail in the Phonenet queue directory. 
     For any mail found it translates it and appends it to a file for
     the cc:Mail import utility.

  5)    It runs the cc:Mail IMPORT utility to deliver the mail to
     cc:Mail.
 
  6)    It checks for any housekeeping it needs to do, such as running
     its own backup.  After housekeeping is complete it returns to
     step 1.

        The gateway has been running at NSF since July 1988.  It has
proved to be very reliable and requires virtually no human attention. 
It currently handles about 1000 messages a week for about 225 cc:Mail
users at NSF.  The main constraint on the gateway is the 9600 baud
line between it and the Internet host.  This limits the transfer to about
1 megabyte per hour.

Other Gateways

        The other gateways that I know of use the same basic
architecture:  A PC on the LAN uses cc:Mail's IMPORT and
EXPORT programs to transfer mail with the LAN.  The PC translates
the mail to Internet format and transfers it to an Internet Host for
delivery.  The primary difference between the gateways is the protocol
used to exchange mail with the Internet Host.  

        We use Phonenet at NSF because it was readily available, we
were familiar with it, and it was specifically designed to allow easy
access to Internet mail over serial lines.  However, the Phonenet
protocols are not widely available.

        There are two other protocols that have been used successfully: 
UUCP and SMTP.

UUCP

        The UUCP model is almost identical to the gateway used at
NSF.  The only difference is that UUCP has a different mail format
and queueing structure.  UUCP is widely available for PC's, in both
supported (commercial) versions and public domain varieties.  A
gateway using UUCP has been running successfully at Oregon State
University at least as long as NSF's.  A limitation of some of the
UUCP implementations is that usernames can only be 8 characters.

SMTP

        The SMTP model is used at Proteon Inc.  It uses TCP/IP
protocols to transfer mail to the Internet Gateway.  It has an ad-
vantage that it operates at LAN speeds.  The gateway requires that a
single PC be configured to communicate with both TCP/IP and
whatever LAN protocols are being used.  Co-existance between LAN
software and TCP/IP is possible with many systems.  Since DOS is not
a good operating system for multi-tasking, the Proteon implementation
uses two Gateway PC's, one for receiving mail and one for sending. 
        
        Another possibility for an SMTP gateway is to use an 80386-
based UNIX machine (such as the SUN 386i) that can run both DOS
and SMTP in a multi-tasking environment.  As far as I know nobody
has implemented a gateway for cc:Mail on this architecture, but it has
been done for other LAN mail systems.

Availability of the Software

        If you are a CSNET member (or have a PMDF license), are
running MMDF, and would like to implement the PhoneNet gateway,
please contact me:

        Mike Morse  --  mmorse@note.nsf.gov

        I will send you the complete package.  If you have experience
with PC's and Internet mail systems you should be able to get it
running in a day or so.  If you want to modify the gateway to run with
UUCP, let me know and I will send you the non-PMDF portion. 

        Al Marshall of Proteon has made his gateway available to
anyone via anonymous ftp.  Contact:

        Al Marshall --  acm@proteon.com

You can purchase a UUCP gateway from Oregon State.  Write to:

        Richard Kinoshita -- kinoshir@ccmail.orst.edu  (Internet)
                            kinoshir@ORSTVM           (BITNET)

[Since I wrote this, cc:Mail has hired Richard to develop and support
gateways.  --MHM]

     If you have any questions, please feel free to write to me, or if
that fails, give me a call:

        Mike Morse -- (202) 357-7659

Disclaimer

        Neither Al Marshall nor I have any connection with cc:Mail
other than as customers.  This message is in no way an endorsement of
cc:Mail by the National Science Foundation.
-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90 09:05:58 GMT
From:      touch!todal!virgil@uunet.uu.net  (Virgil Champlin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip for 386 UNIX
In article <HWAJIN.90Feb7104552@ganges.wrs.com> hwajin@ganges.wrs.com (Hwa Jin Bae) writes:

hwa> The Wollongong stuff is based on the LAI TCP/IP stuff.  I know cause I've
hwa> looked at the sources.

You are dead wrong on this.  I wonder if some of the common BSD source
fooled you?

hwa> The V.4 will have LAI TCP/IP stuff too.

I believe that SUN was the subcontractor for the networking code in V.4
and that they chose to use LAI source as the starting point.  I may have
a good idea as to the ending point but it is mostly speculation.

hwa> Trust me.

Not completely, this time.

-virgil

--
    Virgil Champlin			virgil@touch.com

	"I got it, I got it, I ain't got it."
-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Feb 90 17:16:47 PST
From:      postel@venera.isi.edu
To:        tcp-ip@nic.ddn.mil
Cc:        gnb@melba.bby.oz.au
Subject:   Re: DNS Query server?

Hey!  

The IEN-116 name server is an old idea who's time is past.  
Kill and bury any code that still does IEN-116.

Please use the DNS instead!

--jon.
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Thu, 08 Feb 90 14:57:22 EST
From:      MLESSINS%WAYNEST1.BITNET@CORNELLC.cit.cornell.edu
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: How do you string a thinnet?
Thanks Brain....I mean Brian.....
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Feb 90 15:26:57 EST
From:      fab%saturn.ACC.COM@salt.acc.com (Fred Bohle acc_gnsc)
To:        tcp-ip@nic.ddn.mil
Cc:        cam@saturn.ACC.COM
Subject:   TCP extensions

I am trying to find out who uses TCP options for various extensions
of the protocol.  For example, what implementations use RFC 1072, Extensions
for Long-Delay Paths?  This includes window scaling, selective acknowledgements
and TCP Echo options.  I would like to know any other extensions to the
protocol that various implementations use.  What other RFC's are implemented?
What other extensions are implemented which are not yet RFC's?

This information will be used in considering which options/extensions
will be added to ACC's ACCES/MVS product, so your replies will be used
to improve interoperability.

Fred

------------------------------------------------------------------------
Fred Bohle			EMAIL: fab@saturn.acc.com
ACC				AT&T : 301-290-8100 
10220 Old Columbia Road
Columbia, MD 21046
------------------------------------------------------------------------

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90  15:53 EST
From:      mmorse@NSF.GOV
To:        tcp-ip@NSF.GOV
Subject:   Need Info, Internet Mail from MVS System
   We have an IBM 3090 running MVS that is currently not connected to
the Internet and does not run TCP/IP.  I'm looking for information on
how to connect this machine to the Internet mail system.  The chief
requirement is that application programs in CICS, TSO, and MVS batch
must be able to send and receive Internet mail.  We are not
particularly interested in a user interface.

   Since the machine is not connected now, we're open to all
hardware/software suggestions.  If you are running something similar,
I'd love to hear from you.

--Mike

Michael Morse
National Science Foundation                Internet: mmorse@note.nsf.gov
(202) 357-7659                               BITNET: mmorse@NSF
-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Feb 90 20:26:53 EST
From:      Pete Hickey <PETEHIC%UOTTAWA.bitnet@ugw.utcs.utoronto.ca>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: TCP/IP

>I apologize for being so ignorant, but what is tcp-ip?  What is it run
>on, is like uucp or what?

Yeah, its kind of like UUCP, but more powerful.  It runs on lots of
machines.

=======================================================================
Pete Hickey                     | Convention says that something funny
University of Ottawa            | goes here.  Its blank because I have
Ottawa, Ontario, CANADA         | nothing funny to say.
(613) 564-7646                  |_____________________________________
    petehic@uotacdvm.uottawa.CA      PETEHIC@UOTTAWA.BITNET
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90 16:32:58 GMT
From:      umabco!lwilson@cvl.umd.edu  (Lowell G. Wilson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SMTP gateway for cc:Mail under Netware 386
In article <759@sirius.ucs.adelaide.edu.au> mikeb@ucs.adelaide.edu.au
(Mike Byrne) writes:
>...
>        2. Is there an SMTP gateway available (under development ?) ?

I talked to a sales rep at cc:Mail yesterday and she told me that an
SMTP gateway is under development and will be put into beta release next
month.  Her guess is that the product will be put into final release 2
months after that...

-- 
Lowell Wilson : Sinecure III        University of Maryland at Baltimore    
                                    Information Resources Mgt Division     
                                    UUCP: ...cvl!umabco!lwilson            
                                    Internet: umabco!lwilson@cvl.umd.edu
-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90 16:58:51 GMT
From:      ucsdhub!hp-sdd!ncr-sd!ncrcae!secola!syackey@ucsd.edu  (Steve Yackey)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip for 386 UNIX
In article <HWAJIN.90Feb7104552@ganges.wrs.com> hwajin@ganges.wrs.com (Hwa Jin Bae) writes:
>In article <ADNAN.90Feb6170824@sgtech.UUCP> adnan@sgtech.UUCP (Adnan Yaqub) writes:

>The Wollongong stuff is based on the LAI TCP/IP stuff.  I know cause I've
>looked at the sources.

Are you sure its not as simple as having a common ancestor ?
-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90 17:04:09 GMT
From:      att!laidbak!stevea@ucbvax.Berkeley.EDU  (Steve Alexander)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip for 386 UNIX
In article <HWAJIN.90Feb7104552@ganges.wrs.com> hwajin@ganges.wrs.com (Hwa Jin Bae) writes:
>The Wollongong stuff is based on the LAI TCP/IP stuff.  I know cause I've
>looked at the sources.

If that's the case, then they owe us a big chunk of money. :-)

Let me throw some cold facts on the fire of confusion:

The TCP/IP that AT&T will sell you for 5.3.n was done by the Wollongong Group.
The NFS that they will sell you for 5.3.n was done by Lachman Associates,
and was ported to run over WIN*.

The TCP/IP that will be part of 5.4 was done by Lachman Associates and went
to AT&T via Sun Microsystems.  The NFS that will be part of 5.4 was done by 
Sun, since 5.4 is vnode-based, not FSS-based.

INTERACTIVE liked Lachman's NFS so much they bought the company.  INTERACTIVE's
host-based TCP/IP is not derived from Lachman's TCP/IP.  INTERACTIVE did their
TCP/IP themselves.

SCO got their TCP/IP and NFS from Lachman.

Hope this helps...

-- Steve

----
*WIN is a trademark of the Wollongong Group.
--
Steve Alexander, Software Technologies Group    | stevea@i88.isc.com
INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea
-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90 18:13:35 GMT
From:      trwrb!sansom@ucbvax.Berkeley.EDU  (Richard E. Sansom)
To:        tcp-ip@nic.ddn.mil
Subject:   PROFS -> SMTP interface query

We're looking for a PROFS to SMTP interface for our local VM system.
Does anyone out there know of such a thing?  If it helps, we're running
VM/SP REL 5 and have ACC's TCP/IP networking software/hardware.

Please send responses to sekine@trwrb.dsd.trw.com.  Thanks!

Nancy Y. Sekine
TRW Space and Defense Sector, Redondo Beach, CA
sekine@trwrb.dsd.trw.com
-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90 18:43:43 GMT
From:      ladcgw!news@uunet.uu.net  (Frank Mayhar)
To:        tcp-ip@nic.ddn.mil
Subject:   Need routed (Routing daemon) for System V or HPUX.
I have an HP 9000/300 that needs to be used as a gateway.  Unfortunately,
HPUX 6.5 doesn't come with a 'routed' daemon, which makes things kind of
painful.  So I need one.  Before I spend a lot of time porting the BSD 4.2
routed to HPUX, does someone already have it for System V (release 2 or 3)
or HPUX (6.5 or later)?

Thanks in advance!
--
Frank Mayhar  fmayhar@hermes.ladc.bull.com (..!{uunet,hacgate}!ladcgw!fmayhar)
              Bull HN Information Systems Inc.  Los Angeles Development Center
              5250 W. Century Blvd., LA, CA  90045    Phone:  (213) 216-6241
-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90 19:57:22 GMT
From:      MLESSINS@WAYNEST1.BITNET
To:        comp.protocols.tcp-ip
Subject:   Re: How do you string a thinnet?

Thanks Brain....I mean Brian.....

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90 20:04:03 GMT
From:      ftp!fks@bloom-beacon.mit.edu  (Frances Selkirk)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TN3270 for PCs/MACs, Summary Posting
One correction to the NFS/tn3270 posting:

FTP's PC/TCP with InterDrive is $490, not $600. It is also available
in site licenses. (20-49 copy site license - $230 per copy)

				-Frances Selkirk
				 FTP Software, Inc.
				 info@ftp.com
-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90 20:41:26 GMT
From:      ingr!b11!guy!guy@uunet.uu.net  (Guy Streeter)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP bind question
hwajin@ganges.wrs.com (Hwa Jin Bae) writes:

>In article <7391@b11.ingr.com> heller@b11.ingr.com (Anne Heller) writes:
>   I have a question regarding binding to ports in UDP.  Is it generally 
>   acceptable to allow binding more than once to a given port? ...

>It doesn't really matter whether you use sockets or TLI interface to
>access the UDP/IP...
>...  Upon receiving
>such messages TPI multiplexor module will call protocol specific bind
>routine to handle the bind request and return the result of such
>binding.  This sequence of kernel events is identical for both TLI
>and socket based requests.

I believe you misunderstood the question, which was how the UDP
protocol-specific bind routine should handle a second bind request for
an already-bound port.  Answers received so far are in favor of
allowing subsequent binds to succeed, and handing copies of received
data to each.  Seems that could get confusing...

--
Guy Streeter
b11!guy!guy@ingr.com
...uunet!ingr!b11!guy!guy
-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90 20:41:27 GMT
From:      intercon!news@uunet.uu.net  (Amanda Walker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TN3270 for PCs/MACs, Summary Posting
In article <29085@amdcad.AMD.COM>, remaker@pepsi.amd.com writes:
> Amada Walker's company (Intercom, I think),

Close :-)

> has a commercial 
> version.  Basically, it's NCSA Telnet plus a lot of bells and whistles.
> Don't know about the cost.

For VT102 + TN3270, the cost is $295.00 for a single copy.  For VT240+TN3270,
it's $495.00.  We support multiple sessions (although usually not to the
same host, since we have found no way to emulate a DFT over TN3270), 3278
models 2-5 with base color, but no 3179G host graphics (yet).

For more information call (703) 450-7117.

--
Amanda Walker
InterCon Systems Corporation

"Many of the truths we cling to depend greatly upon our own point of view."
	--Obi-Wan Kenobi in "Return of the Jedi"
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90 20:47:52 GMT
From:      att!cbnewsd!cage@ucbvax.Berkeley.EDU  (charles.gerlach)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip for 386 UNIX
>   For one, in 3.0.  I have a manual in front of which says: "AT&T
>   Enhanced TCP/IP WIN/386 Release 3.0" which talks about "Wollongong
>   Socket Compatibility Library Routines".
>
>The Wollongong stuff is based on the LAI TCP/IP stuff.  I know cause I've
>looked at the sources.  The V.4 will have LAI TCP/IP stuff too.  Trust me.

Just because we look alike does not make us father and son.  It doesn't
even make us relatives, even though I would expect that if you looked
long and hard enough you would find a common ancestor.

Back to the original question.  In WIN/386 3.0 there is a socket
compatibility library to provide socket services over TLI.  WIN/386 3.0
is TLI-based and would have none of the socket calls features most programmers 
have come to expect without that library.
-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90 21:40:14 GMT
From:      touch!todal!virgil@uunet.uu.net  (Virgil Champlin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP bind question
In article <HWAJIN.90Feb7145434@ganges.wrs.com> hwajin@ganges.wrs.com (Hwa Jin Bae) writes:
>>   In article <7391@b11.ingr.com> heller@b11.ingr.com (Anne Heller) writes:
>>    I have a question regarding binding to ports in UDP.  Is it generally 
>>    acceptable to allow binding more than once to a given port?  (I know
>>    about the SO_REUSEADDR option in sockets, but we have a STREAMS
>>    implementation which complies with the AT&T Transport Provider
>>    Interface (TPI) standard, so not everyone is accessing UDP through sockets.)
>  It doesn't really matter whether you use sockets or TLI interface to access
>  the UDP/IP.  The system calls (whether you use bind() or t_bind()) get turned
>  into STREAMS messages as they pass through the STREAM heads with types that TPI
>  multiplexor module understands (in case of bind request it would be
>  T_BIND_REQ type).  Upon receiving such messages TPI multiplexor module will
>  call protocol specific bind routine to handle the bind request and return 
>  the result of such binding.  This sequence of kernel events is identical
>  for both TLI and socket based requests.

This is a bit wrong since the stream head knows nothing about TPI.  It
also doesn't answer the question "Is it generally acceptable to allow
binding more than once to a given port?".  I am also unaware of anything
in UDP or TPI that prohibits more that one binding, concurrent or not,
for CLTS providers.  That doesn't mean that some implementations might
disallow multiple concurrent binds but I do not know what they would use
as a justification.  Probably my old standby, "It seemed to make sense
at the time.".  There is the restriction with TPI that prohibits
multiple concurrent binds with a "qlen" greater than zero which
effectively disallows multiple concurrent "listens" (in the TLI sense)
but this is for COTS, not CLTS providers .

-virgil
--
    Virgil Champlin			virgil@touch.com
					Campbell, CA
	"I got it, I got it, I ain't got it."
-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90 22:14:01 GMT
From:      van-bc!ubc-cs!alberta!mts.ucs.UAlberta.CA!ualtavm!DKRUGER@ucbvax.Berkeley.EDU  (Dwight Kruger)
To:        tcp-ip@nic.ddn.mil
Subject:   Network General
Does anyone have a telephone number for Network General?  I need a # which
is accessable from Canada.
 
We need to have some repairs done on our Siffer ethernet card, and the
vendor who originally supplied it wants an outrageous amount for its repair.
 
Dwight Kruger
Network Software Development
University of Alberta
-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90 22:25:08 GMT
From:      hpda!hpcupt1!hpindwa!raj@ucbvax.Berkeley.EDU  (Rick Jones)
To:        tcp-ip@nic.ddn.mil
Subject:   Where Runs BSD?


A toss-up,

Who besides Berkeley runs with a BSD Networking Transport?  I am
especially interested in examples of that code being used on OS's
other than UN*X?

inquiringly,
rick jones
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 90 22:31:28 GMT
From:      jupiter.bellcore.com!karn@bellcore.com
To:        tcp-ip@nic.ddn.mil
Subject:   SIGCOMM '90 deadline approaching

This is just a quick reminder that the deadline for submitting papers to
ACM SIGCOMM '90 is just a few weeks away: March 2, 1990.

SIGCOMM '90 will be held in Philadelphia, PA on September 25-27, 1990.
Almost any topic in computer communications is relevant to this
conference, which has in recent years become one of the best of its
kind.

As it is currently a "hot" area with a lot of ongoing research
activities we are particularly interested in papers presenting new
results in the field of high speed networking and protocols ("high
speed" being roughly 100 Mb/s and above). However, all papers on
subjects within the scope of the conference will be given equal
consideration.

I am the chairman of the Program Committee, so you may direct your
questions and papers to me. Thanks!

Phil Karn
Bellcore 2P-357
445 South St
Morristown, NJ 07960
(201) 829-4299
karn@thumper.bellcore.com
-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 90 00:59:17 GMT
From:      pasteur!helios.ee.lbl.gov!me10.lbl.gov!milburn@ucbvax.Berkeley.EDU  (John Milburn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Need routed (Routing daemon) for System V or HPUX.
In article <1990Feb8.184343.16431@ladc.bull.com> fmayhar@hermes.ladc.bull.com (Frank Mayhar) writes:
>I have an HP 9000/300 that needs to be used as a gateway.  Unfortunately,
>HPUX 6.5 doesn't come with a 'routed' daemon, which makes things kind of
>painful.  So I need one.  ...

Why not upgrade to hpux 7.0. It comes standard with gated, which can
handle rip, hello, and egp. 7.0 also has full nameserver support.

-jem
John Milburn - Advanced Light Source - Lawrence Berkeley Laboratory
INTERNET: JEMilburn@lbl.gov   BITNET:    JEMilburn@LBL.bitnet
UUCP:      {...}!ucbvax!lbl.gov!JEMilburn
SnailMail: 1 Cyclotron Road 46-161 Berkeley, Ca. 94720  Ph:  (415) 486-6969
-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 90 01:41:12 GMT
From:      root@sbcs.sunysb.edu  (Systems Staff)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Getting a commercial firm into Internet
In article <9002071448.AA20057@nisc.nyser.net> schoff@PSI.COM ("Martin Lee Schoffstall") writes:
>PSI is providing networking services (NYSERNet, CAPNet) throughout
>the NorthEast and MidAtlantic states and internationally. Contact
>info@psi.com.
>
>Marty
>----------------

What does PSI charge per year for a SLIP link that provides full Internet
access?

					Rick Spanbauer
					Ameristar Technology
-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 90 02:57:31 GMT
From:      auspex!guy@uunet.uu.net  (Guy Harris)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Inetd Discard on SunOS4

 >Bill> All of the internal services are included in /etc/inetd.conf
 >Bill> in SunOS 4.1.
 >
 >You did not answer the original question.

If the original question was, as I remember it to be, "is there any
reason they're not included there in 4.0", the 4.0 "inetd" is basically
the 4.3BSD one with RPC support and some file descriptor throttling, so
the answer is "the only reason they're not there is that somebody" -
possibly me - "forgot to put them there".
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 90 03:31:59 GMT
From:      siucbal!tiwana@g.ms.uky.edu  (Gurmukh Tiwana )
To:        tcp-ip@nic.ddn.mil
Subject:   Wanted information on 3C503 3COM ETHERNET CARD

Hi folks,
    I am looking for documentation regarding the 3COM ETHERNET card
    3C503. I have the card but do not have the information for 
    programming it. If anyone has it and could send it to me it 
    would be a real help. Send e-mail to me if you have any 
    information.

Thank you,


------------------------------------------------------------
Gurumukh Tiwana, Southern Illinois University at  Carbondale 
tiwana@siucbal.UUCP
GR4024@SIUCVMB.BITNET
____________________________________________________________
-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 90 04:49:01 GMT
From:      pacbell!tandem!mytardis!narayan@ames.arc.nasa.gov  (Narayan Mohanram)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip for 386 UNIX
#>The Wollongong stuff is based on the LAI TCP/IP stuff.  I know cause I've
#>looked at the sources.  The V.4 will have LAI TCP/IP stuff too.  Trust me.
#>
#>Hwa Jin Bae, Wind River Systems, 1351 Ocean Avenue, Emeryville, CA 94606, USA
#>hwajin@wrs.com (uunet!wrs!hwajin)   "Omnibus ex nihil ducendis sufficit unum."

So you looked at the sources and figured out it is the same huh? How about
if the author of the Wollongong sources says that you are talking through your
hat.

Narayan Mohanram (ex Wollongonger!)
-- 
===============================================================================
Phone:	 408-738-4165
US Mail: 909 W. Olive, Sunnyvale, CA 94086
E-Mail:	narayan@tandem.com
-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Feb 90 09:33 EDT
From:      James Dryfoos- PostMaster <DMPM%DUKEMC.BITNET@VTVM1.CC.VT.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Network General
>Received: from JNET-DAEMON by dukemc; Fri, 9 Feb 90 03:43 EDT
>Received: From VTVM2(MAILER) by DUKEMC with Jnet id 9146 for DMPM@DUKEMC; Fri,
> 9 Feb 90 03:43 EST
>Received: by VTVM2 (Mailer R2.05) id 0317; Fri, 09 Feb 90 03:43:31 EST
>Date: Thu, 8 Feb 90 22:14:01 GMT
>From: tcp-ip-relay@NIC.DDN.MIL
>Subject: Network General
>Sender: ARPA TCP-IP Discussion Redistribution <TCP-IP@UTDALLAS.BITNET>
>To: James Dryfoos <DMPM@DUKEMC>
>Reply-to: TCP-IP@SRI-NIC.ARPA
>Message-id: <DF88C978B3DF204A14@dukemc>
>X-To:         tcp-ip@nic.ddn.mil
>X-Envelope-to: DMPM
>
>Does anyone have a telephone number for Network General?  I need a # which
>is accessable from Canada.
>
>We need to have some repairs done on our Siffer ethernet card, and the
>vendor who originally supplied it wants an outrageous amount for its repair.
>
>Dwight Kruger
>Network Software Development
>University of Alberta

For some reason I cannot find your address in this header so I am replying
to this list.  The number I have for Network General are (415)688-2700
and a fax number of (415)321-0855.

I am currently looking at getting a sniffer series 500.  Any comments?

-Jim Dryfoos

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
*  James Dryfoos  -- Medical Informatics - Duke University Medical Center     *
*                                                                             *
*  VMS Systems Programmer -- Postmaster - Duke Electronic Medical Post Office *
*  DMPM@DUKEMC.BITNET     -- Duke Medical Postmaster BITnet address           *
*  DMPM@DUKEMC.MC.DUKE.EDU - Duke Medical Postmaster INTERnet address         *
*  DRYFO001@DUKEMC.BITNET -- Personal BITnet Address                          *
*  DRYFO001@DUKEMC.MC.DUKE.EDU -- Personal INTERnet Address                   *
*  Box 2914 D.U.M.C. Durham, NC 27710 USA, EARTH--(919) 684-6421/fax 684-8675 *
*                                                                             *
*  My PLAN is to get through this day!!!!!!                                   *
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Feb 90 10:50 -0300
From:      MARCOS%BRUC.ANSP.BR@UICVM.uic.edu
To:        tcp-ip@nic.ddn.mil
Subject:   help
help
-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Feb 90 15:15:23 PST
From:      adelman@TGV.COM (Kenneth Adelman)
To:        hpda!hpcupt1!hpindwa!raj%ucbvax.Berkeley.EDU\@TGV.COM
Cc:        Tcp-Ip@Sri-Nic.ARPA
Subject:   Re: Where Runs BSD?
> Who besides Berkeley runs with a BSD Networking Transport?  I am
> especially interested in examples of that code being used on OS's
> other than UN*X?

    We use the Berkeley Networking code in MultiNet, our VMS TCP/IP
package.  The socket code (uipc_socket, etc) has been modified
slightly to act as what is essentially an FDT routine in a VMS driver
and from the socket level on down through the interface switch the
code is almost a 100% unmodified (the modifications have to do with
checking if someone is "root" and getting the time as a random number
seed).	We even run Berkeley UNIBUS and Qbus drivers under VMS.

						Kenneth Adelman
						TGV, Incorporated
-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 90 07:47:08 GMT
From:      oberman@rogue.llnl.gov (Oberman, Kevin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP

In article <90Feb8.205744est.58593@ugw.utcs.utoronto.ca>, PETEHIC@UOTTAWA.BITNET (Pete Hickey) writes...
> 
>>I apologize for being so ignorant, but what is tcp-ip?  What is it run
>>on, is like uucp or what?
> 
>Yeah, its kind of like UUCP, but more powerful.  It runs on lots of
>machines.

*Sigh* I hate seeing this sort of fairly useless answer, but it is (a little)
better than nothing, I suppose.

TCP/IP (tcp-ip, IP/TCP, ...) is the most common name for the DOD Network
Protocol suite. It was originally developed in the seventies by a community of
people under the auspices of ARPA, a DOD research agency. (Maybe ARPANET sounds
familiar.)

TCP is Tranmission Control Protocol and IP is Internet Protocol, making tcp-ip
a poor name. TCP is often not used. But its use is so nearly universal that I
don't see the point in fighting it.

TCP/IP includes a rich networking environment which include remote login
(TELNET), file transfer (FTP), electronic mail (SMTP), network management
(SNMP) and lots of other stuff. The standards are under continual revision and
expansion, so today's TCP/IP bears little similarity to that of a decade ago.
Even so, they may well interoperate.

Because TCP/IP was developed with government money and is not tied to any
single vendor it has become the defacto standard for multi-vendor networking
and is available from at least dozens, if not hundreds of vendors for virtually
any computer system from an PC to a Cray. It is also the standard network for
almost all Unix(tm) based systems.

While its capabilities are nowhere near as advanced as the proposed OSI
protocols (no flames, please), TCP/IP has two significant advantages. It's here
and available NOW and in use on well over 100,000 systems and it works. OSI
implementations are just coming into being and many important standards for OSI
are still under development.

UUCP (Unix(tm) to Unix(tm) Copy Program (as I recall)) is a fairly primative
but simple to implement communications method designed for the sole purpose of
copying a file from one system to another. It has since been adapted for E-Mail
use. UUCP is easy to set up and maintain, but is very limited in its
capabilities. It is usually used over low speed, dial-up lines and often
requires explicit (bang style) routing information.

I suspect I could sontinue with this for a week or so, but I think I've
described the most significant things involved.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything. Also, my spell
checker won't work in NEWS. Got to fix that sometime!

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 90 15:18:16 GMT
From:      ingr!b11!guy!guy@uunet.uu.net  (Guy Streeter)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP on async lines
I seem to recall hearing that SLIP will only run on synchronous serial
lines.  Is this true?  I'm not asking about a particular
implementation, and I realize that an async SLIP couldn't talk to a
sync SLIP, but is there something about SLIP which precludes it's
being implemented over async lines?

Responses by e-mail will be fine.
Thanks,
Guy Streeter
b11!guy!guy@ingr.com
...uunet!ingr!b11!guy!guy
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 90 15:31:19 GMT
From:      ecsvax.uncecs.edu!khj@mcnc.org  (Kenneth H. Jacker)
To:        tcp-ip@nic.ddn.mil
Subject:   HyperMIB Available?
Page 37 of draft #4 of the _Network_Management_Tool_Catalog_ states
that HyperMIB is available via anonymous "ftp" on machine CC.NMFECC.GOV.

I have tried at various times of the day and night, but failed.  Here's
a copy of the interaction:

	ftp ccc.nmfecc.gov
	Connected to ccc.nmfecc.gov.
	220 CCC.NMFECC.GOV MultiNet FTP Server Process 2.1(8) at ...
	Name (ccc.nmfecc.gov:khj): anonymous
	Password (ccc.nmfecc.gov:anonymous):
	331 anonymous user ok. Send real ident as password.
	530 ANONYMOUS ftp disallowed.
	Login failed.
	ftp>

Any suggestions on how to obtain this software are appreciated!


-- 
Kenneth H. Jacker               Domain:   khj@uncecs.edu
Dept of Math Sciences           BITNET:   khj@ecsvax
Appalachian State Univ          UUCP:     ...!ecsvax!khj
Boone, NC  28608
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Fri, 09 Feb 90  21:38:05 EST
From:      "Roger Fajman" <RAF@CU.NIH.GOV>
To:        merlin@smu.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Access to EARN/BITNET
> We have a user who would like to access a machine on "EARN/BITNET".
> I can't find anything on this in the domain name tables.  Please,
> what is this, and how do I connect to it?  Thanks for as quick
> a response as possible,
>
>
> David Hayes    School of Engineering   Southern Methodist University
> merlin@smu.edu uunet!smu!merlin
> "Here's a test to see if your job here on Earth is finished:  If you're
> still here, it isn't."  -- Richard Bach, _Illusions_

Your own school, Southern Methodist University, is on BITNET with node
name SMUVM1.  I suggest that you contact the Inforep for that node,
Michael Fritsche, (214) 692-3529, for assistance.

By the way, the proper list for this type of question is
Info-Nets@Think.com. There's probably a corresponding news group, but I
don't recall the name.

Roger Fajman
RAF@NIHCU  (BITNET)
RAF@CU.NIH.GOV  (Internet)

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 90 19:12:19 GMT
From:      ogicse!plains!tinguely@decwrl.dec.com  (Mark Tinguely)
To:        tcp-ip@nic.ddn.mil
Subject:   BIND 4.8[.1] TCP error

 We have been having a frequent BIND failure on both our VAX and
 Solbourne that is traced to TCP domain queries from an IBM NSMAIN
 nameserver running in cache mode (UDP queries do not cause this
 problem, though it is usually a UDP resolution that is active upon the
 crash -- this resolution is an innocent victim).

 I have discovered that something is trashing the hash areas (sometimes
 even as it is being recursively used in a resolution). Also, occasionally
 the socket/file descriptor for the TCP connection is changed to invalid
 entries causing a reply write fail (though this is not necessarially fatal,
 and the rest of the structure is not apparently altered).

 One dump I have points out in nlookup (dblookup.c), we pass, but do not
 modify the double pointer htpp, one of the first steps is to do a
 one level reference and put the answer in htp. Between the second and
 third call to nlookup, contents of *htpp (htp) changes. The only thing
 that could change this value (other than evil gods), is a signal processing
 routine, but the signal processing routines just set a flag and exit.

 Has any one else have frequent BIND failures (especially major domain
 sites that have heavy TCP domain loads).

-- 
Mark Tinguely           North Dakota State University,  Fargo, ND  58105
  UUCP:       		...!uunet!plains!tinguely
  BITNET:      		tinguely@plains.bitnet
  INTERNET:   		tinguely@plains.NoDak.edu
-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 90 19:41:04 GMT
From:      att!cbnewsi!han@ucbvax.Berkeley.EDU  (han.q.nguyen)
To:        tcp-ip@nic.ddn.mil
Subject:   Copy of RFC1134 (Point-to-Point Protocol Spec) Needed

I'm looking for the latest version (dated 11/89?) of RFC1134
(Point-to-Point Protocol Specification).  I have tried
to obtain this document from CSNET Info-Server but the Server
does not appear to have it on-line: my mail request got
acknowledged but there was no indication (i.e., the "document
was sent in X segments" kind of messages) that the document
was sent.

Can someone on the net who has an electronic copy of this spec
please sent it to me via e-mail?  My address: han@arch3.att.com


Many thanks.

Han Nguyen
AT&T Bell Labs
-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 90 22:47:24 GMT
From:      sun-barr!newstop!texsun!smunews!smu.edu!merlin@apple.com  (David Hayes)
To:        tcp-ip@nic.ddn.mil
Subject:   Access to EARN/BITNET
Sorry to send this to what may be the wrong group, but this is the
best-informed bunch of network people I know.

We have a user who would like to access a machine on "EARN/BITNET".
I can't find anything on this in the domain name tables.  Please,
what is this, and how do I connect to it?  Thanks for as quick
a response as possible,


David Hayes	School of Engineering	Southern Methodist University
merlin@smu.edu	uunet!smu!merlin
"Here's a test to see if your job here on Earth is finished:  If you're
still here, it isn't."  -- Richard Bach, _Illusions_
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 90 22:57:52 GMT
From:      pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!wupost!dranet!sean@tut.cis.ohio-state.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Getting a commercial firm into Internet
In article <9002062137.AA14927@cwh.cam.nist.gov>, craig@CWH.CAM.NIST.GOV (Craig Hunt) writes:
> One of our network users, who is doing extensive work with a commercial
> firm, asked how that firm could have access to the Internet. Does
> anyone know who is offering a service to connect commercial users into
> Internet services.  I suggested UUNET and CSNET.  I also thought
> perhaps Merit. Suggestions, contacts, addresses would all be
> appreciated.

I've been trying to get a definitive answer to this question for six months.
Finding the physical connection is easy; finding someone with the authority
to say yes, who will say yes is hard.  A related problem is finding out the
limits for which a commercial firm could use the Internet (the answers vary
from nothing, to anything), and getting it in writing (that's amusing).

Since I'm still looking for the definitive answer, don't take this too
seriously... sometimes I like to take out my frustrations by typing.

Although things are improving, I finally got a response from the NSF NSC
this week.

The physical connection is fairly easy.

    1. Find a network that is already on the Internet
       A few good sources for this information include
         a. Internet Resource Guide
            NSF Network Service Center (nnsc@nnsc.nsf.net)
         b. SERVICE@SRI-NIC.ARPA (SERVICE@NIC.DDN.MIL)
            Subject: HELP
         c. The Matrix : Computer Networks and Conferencing Systems Worldwide
            John S. Quarterman
            Digital Press, ISBN 1-55558-033-5
            (less than a year old, and already some information is out of date)

    2. Find out a contact person, ask them if they'll let you (goto step 1)
         This is were money comes up.  The general rules are
            If you are asking for a connection to them, you pay
            If they are asking for a connection to you, they pay
            If both parties are asking for a connection, split the
            cost and don't charge each other

    3. Get an IP network address, domain, and other adminstrivia
         a. either from the network you are connecting (eg. you become a
              subnet, or maybe a single host depending on your needs)
         b. or from HOSTMASTER@NIC.DDN.MIL (which will require coordination
              with/from the Internet core gateways)

    4. Order some equipment, put in a phone line, etc

    5. Hook it up, and you're on the Internet (yeah, right....:-)

Ok, you're connected, but are you allowed to connect???

A starting point for most "network policies"

  1.  Acceptability of traffic over a particular network line is determined
      by the entities owning/paying for the line.

  2.  Interference with the use or operation of the network is viewed as
      not acceptable.

  3.  Malicious, unethical (based on accepted community standards), or illegal
      activities are viewed as not acceptable.

Note the Commercial/Non-profit split isn't a universal concept in Internet
policies, though it is a frequent one.  Since no single entity owns the
Internet, determining the exact policies tends to be difficult.  "The Policy"
of the Internet is actually a set of interlocking agreements among several
hundred entities.  And not all of these agreements are in writing.

The Internet is really an inter-network (yep, that's what the books say).
It is tempting to think of the Internet as a homogenous network, but it
isn't.  A group of commercial companies could set up network with a gateway
to the rest of the Internet, and on that network exchange invoices with few,
if any, problems.  What is viewed as the "acceptable use policies," comes
from the principle that who pays calls the shots.  For example, commercial
use of the part of the Internet paid for by NSF isn't allowed, except for
things that NSF says are OK.

In reality the number of networks you actually need to worry about is much
smaller.  Generally you need to only get a line of approval between you
and one of the national backbones (about 2-4 authorizations).

      you<->local connection<->mid-level network<->national backbone

The most likely connection will be through a mid-level network.  Most of
the mid-level networks have connections only within a geographic region, but
a few have connections worldwide.  There are also overlaps between the
mid-level networks.  Shop around for the best combination of price, policy,
and added features (some have 24-hour support, very high bandwidth, or other
special resources).  They can vary greatly.  It is almost like choosing a
long distance telephone company.

There are several long haul IP backbone networks.  Some allow no third party
traffic, while others exists to connect the various mid-level networks.  Also
some mid-level networks have additional connections between themselves besides
the national backbones.  After you choose a mid-level network, they can help
with authorizations for the national backbones.

-- 
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
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 90 01:21:50 GMT
From:      nsc!pyramid!infmx!aland@decwrl.dec.com  (Dr. Scump)
To:        tcp-ip@nic.ddn.mil
Subject:   DOS & UNIX ethernet board wish list (was Re: TCP/IP over Starlan)
In article <26490@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes:
>mike@glisten.UUCP (Michael Wendel) in <195@glisten.UUCP> mentions:
>
>	AT&T has announced Ethernet compatability (IEEE 802.3) with its 
>	Starlan 10 product. I have AT&T literature on this product offering.
>	It is available directly from AT&T. They provide a toll free number
>	for more information:  1-800-247-1212.
>
>The original 1Mbit/sec StarLAN is also 802.3 compatible; more specifically,
>ANSI/IEEE 802.3e-1988, Type 1BASE5.
>The "new" StarLAN-10 is Type 10BASE5.
>  <etc.>

This brings to mind a question.  Does anybody know of an ethernet
board which will operate for *all* the following uses:
    a) under UNIX Sys V/386 Rel 3.2.2 on a 6386:
       *  uucp   
       *  tcp/ip 
       *  NFS or RFS
       *  etc.

    b) under MS-DOS 3.30 or 4.01, also on a 6386:
       *  PC-NFS   (or, FTP Software's PC/TCP will do in a pinch)
       *  Novell NetWare  (I can live without this, but it'd be nice)
    
A couple of 3Com cards come close - they are supported for PC-NFS and
for UNIX use under 386/ix or SCO (but not AT&T).  The AT&T Micom/
Interlan hardware for UNIX won't work with the DOS needs, nor will
the EN100/Wollongong combo, as far as I know.  (Plus, the Informix
I-NET products are only ported to the Micom combo so far).

Is this a pipe dream?  Any advice appreciated.
Followups to comp.sys.att.

--
Alan S. Denney  @  Informix Software, Inc.       "We're homeward bound
aland@informix.com  {pyramid|uunet}!infmx!aland   ('tis a damn fine sound!)
-----------------------------------------------   with a good ship, taut & free
 Disclaimer:  These opinions are mine alone.      We don't give a damn, 
 If I am caught or killed, the secretary          when we drink our rum
 will disavow any knowledge of my actions.        with the girls of old Maui."
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 90 01:28:54 GMT
From:      snorkelwacker!usc!samsung!emory!km@tut.cis.ohio-state.edu  (Ken Mandelberg)
To:        tcp-ip@nic.ddn.mil
Subject:   Hayley Connect Lan 100
Does anyone have any experience with this "Brouter". Our computer
center uses a few to bridge ethernets, but seems to be unable to get
any technical information on it. Each one puts out 10 packets a second
of some internal information. The packets don't seem to be anything I
can recognize. They don't look like ethernet or 802.3.

If anyone has any technical info on this box, I would love to hear
about it.
-- 
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
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 90 01:34:12 GMT
From:      sparkyfs!milk0.itstd.sri.com!rusti@ames.arc.nasa.gov  (Rusti Baker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Ethernet Throughput (AMD vs. Intel vs. Seeq)
I would be interested in seeing any type of discussion of 
the behaviour of the chips mentioned in this thread.

E.G. Clark, Jacobson et al provided this insight into the 
behavior of the LANCE in their June 1989 IEEE Comm.  article: 

"[the LANCE] locks up the memory bus during the transfer
thus stalling the processor"
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 90 02:53:30 GMT
From:      pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!romp!auschs!awdprime!kdillman.austin.ibm.com!ken@tut.cis.ohio-state.edu  (Ken Dillman)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PROFS -> SMTP interface query
Actually, I believe that we offer a Program Product called PROFS Extended
Mail that understands RFC 822 addresses and routes mail to and from an
SMTP agent running on VM.  Your local marketing rep should be able to
locate the product description for you.

Hope this helps.

-------------------------------------------------------------------------------
Ken Dillman           | 11400 Burnet Road | Phone: T/L 678-4804 or
AIX Technical Support | Austin, TX  78754 |            512/838-4804
ZIP 2830              |                   | VNET/PROFS: KDILLMAN at AUSTIN
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 90 03:51:13 GMT
From:      bronze!ebrill@iuvax.cs.indiana.edu  (Ed Brill)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Access to EARN/BITNET
In article <16106@smunews.UUCP> merlin@smu.edu (David Hayes) writes:
>We have a user who would like to access a machine on "EARN/BITNET".
>I can't find anything on this in the domain name tables.  Please,
>what is this, and how do I connect to it?  Thanks for as quick
>a response as possible,

>David Hayes	School of Engineering	Southern Methodist University
>merlin@smu.edu	uunet!smu!merlin

There are several machines on the Internet that act as gateways between
the Internet and BITNET.  Two examples I can think of are UICVM.UIC.EDU
and CUNYVM.CUNY.EDU.  You can address a message to
user%nodename.bitnet@uicvm.uic.edu 
where the message will be passed from the Internet to BITNET.  At least--
it usually works.



 Ed Brill -- University Computing Services | SysOp, The IU PC-Link Central BBS
 Indiana University, Bloomington, IN 47405 | (812) 855-7252 -- 3/12/24/96/14.4
 INTERNET:  ebrill@subcomm.ucs.indiana.edu | KA9TAW @ K9IU  [ham radio packet]
 "You mean BITNET isn't the only network we have to access the outside world?"
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 90 04:22:48 GMT
From:      mentor.cc.purdue.edu!dls@ee.ecn.purdue.edu  (David L Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Getting a commercial firm into Internet

	You might check out Cypress. It's a low-cost long haul network
developed here at Purdue with a gateway to the Internet. The person to
contact for information is Scott Ballew (smb@cs.purdue.edu).

-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 90 04:59:57 GMT
From:      amdcad!ncpmont@ucbvax.Berkeley.EDU  (Mark Montgomery)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Ethernet Throughput (AMD vs. Intel vs. Seeq)
In article <29914@sparkyfs.istc.sri.com> rusti@milk0.itstd.sri.com.UUCP (Rusti Baker) writes:
>I would be interested in seeing any type of discussion of 
>the behaviour of the chips mentioned in this thread.
>E.G. Clark, Jacobson et al provided this insight into the 
>behavior of the LANCE in their June 1989 IEEE Comm.  article: 
>"[the LANCE] locks up the memory bus during the transfer
>thus stalling the processor"

Yes, and how many times have we seen in this group and protocols people
asking if anybody knew why their 3c5xx board was locking up their
system.
	Well, 3c5xx's don't have LANCE's on them, they have N__ chips.
	Also if you'll re-read the article you'll see that what they
	were saying was that the LANCE was "stalling" the cpu while
	it did dma of the packet directly to memory.  Can't do that
	with an XYZ chip.  Of course you could have the cpu do the
	transfers or you could build a cache if you'd rather.
				Mark
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Sun, 11 Feb 90 04:13:19 PST
From:      christopher raczka <RACZKA@GLDOA.enet.dec.com>
To:        "att!cbnewsi!han@ucbvax.Berkeley.EDU"@11221.enet.dec.com
Subject:   RE: Copy of RFC1134 (Point-to-Point Protocol Spec) Needed
Han,

    I just sent this to you...Enjoy  (-:

regards,
christopher raczka
Digital Equipment Corp
------------------------------------------------------------------------
Standard Disclaimer....
------------------------------------------------------------------------
-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 90 20:38:55 GMT
From:      mips!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!km@apple.com  (Ken Mandelberg)
To:        tcp-ip@nic.ddn.mil
Subject:   Ethernet type 80F3 ?
Does anyone recognize ethernet type "80F3"? I don't
see it in RFC1010, but I am seeing it on our net.
-- 
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
-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 90 12:36:22 GMT
From:      zaphod.mps.ohio-state.edu!samsung!aplcen!wb3ffv!fallst!tkevans@tut.cis.ohio-state.edu  (Tim Evans)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mailbridge between the Internet and cc:Mail (PC LAN package)
In article <9002081357.aa23656@Note.NSF.GOV>, mmorse@NSF.GOV writes:
> 
> I've also
> enclosed limited information on similar gateways running at Proteon
> and other sites.
> 
>         There are two other protocols that have been used successfully: 
> UUCP and SMTP.
> 
> You can purchase a UUCP gateway from Oregon State.  Write to:
> 
>         Richard Kinoshita -- kinoshir@ccmail.orst.edu  (Internet)
>                             kinoshir@ORSTVM           (BITNET)
> 
> [Since I wrote this, cc:Mail has hired Richard to develop and support
> gateways.  --MHM]
> 
We run Richard's package (called "OutMail") at the Social Security Admini-
stration in Baltimore, where we have a potential universe of 5,000+ E-Mail
users--1,200 UNIX and 4,000 DOS users.

As Mike notes, Richard is now employed by cc:Mail, Inc., where, as I 
understand it, he's primarily working on a SMTP package that cc:Mail will
sell and support.  He's been fairly responsive to my requests for bug
fixes in OutMail.  Since SSA has a major contract with cc:Mail, we were
able to get OutMail; you may not because the copyright is held by Oregon
State.  (BTW, Richard's OSU mail address still works, even though he's
working in Palo Alto.)

With respect to the overall package, as Mike points out, cc:Mail works
well in the DOS environment.  Because most of our users, both DOS and
UNIX, are relatively unsophisticated, though, they've been having 
trouble understanding and using the gateway to get E-Mail to each other.
Of particular note is the uuencode/uudecode feature noted above.  This
is most a user problem, not a problem with cc:Mail or OutMail--obviously.

The one comment that should be made, though, is that cc:Mail is an
expen$ive package and that, in order to run any sort of gateway, 
including the public domain ones Mike describes in this posting, you
have to buy expen$ive add-ons from cc:Mail.  cc:Mail's message format
is some sort of encrypted, compressed one that is a proprietary secret,
so you have to buy the Import/Export utilities from them. Presumably,
the SMTP gateway Richard is working on will also be expen$ive.

DISCLAIMER:  I'm not speaking for SSA; I just administer the gateway.

-- 
UUCP:		{rutgers|ames|uunet}!mimsy!woodb!fallst!tkevans
INTERNET:	tkevans@wb3ffv.ampr.org
Tim Evans	2201 Brookhaven Ct, Fallston, MD 21047  (301) 965-3286
-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 90 19:16:38 GMT
From:      siucbal!tiwana@g.ms.uky.edu  (Gurmukh Tiwana )
To:        tcp-ip@nic.ddn.mil
Subject:   wanted information on 3-com 3c503 ethernet card


Hi folks,
    I am looking for documentation regarding the 3COM ETHERNET card
    3C503. I have the card but do not have the information for 
    programming it. If anyone has it and could send it to me it 
    would be a real help. Send e-mail to me if you have any 
    information.

Thank you,



------------------------------------------------------------
Gurumukh Tiwana, Southern Illinois University at  Carbondale 
tiwana@siucbal.UUCP
GR4024@SIUCVMB.BITNET
____________________________________________________________
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 90 20:54:25 GMT
From:      ucsdhub!hp-sdd!ncr-sd!ncrcae!wingo@ucsd.edu  (Dave Wingo)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip for 386 UNIX

In article <HWAJIN.90Feb7104552@ganges.wrs.com> hwajin@ganges.wrs.com (Hwa Jin Bae) writes:
>The Wollongong stuff is based on the LAI TCP/IP stuff.  I know cause I've
>looked at the sources. Trust me.


Be leary of those who ask you to trust them!!

Used car salesmen say the same thing.

I also think they have common ancestry

regards wingo@Columbia.NCR.Com
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 90 21:45:31 GMT
From:      att!cbnewsi!han@ucbvax.Berkeley.EDU  (han.q.nguyen)
To:        tcp-ip@nic.ddn.mil
Subject:   Thanks (Was: Copy of RFC1134 Needed)
Since posting the request for a copy of RFC1134, I have received
a couple of copies of this RFC as well as info on how I might have
obtained RFCs from the NIC via e-mail request.

Many thanks to those who responded (and also those who were about
to respond) to my request.

Han Nguyen
-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Feb 90 07:57:06 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        fab@saturn.acc.com
Cc:        tcp-ip@nic.ddn.mil, ietf@isi.edu
Subject:   re: TCP extensions

Fred:

    At the Internet Engineering Task Force Meeting last week a working
group made some progress on deciding what to do about the RFC 1072 options.
Here's a quick summary:

    (1) The RFC 1072 window shift option will be used to expand the
    window size (everyone likes it, and implementation is a snap).

    (2) We'll create a new Urgent Pointer option so it can point
    to urgent data anywhere in the expanded window.  (To use it,
    the URG bit is left off -- when the receiver processes options,
    it will see that there is urgent data).

    (3) The WG was divided among two options for expanded the sequence
    and ack space.  Thankfully some folks with supercomputers offerred
    to implement both options and report back this spring.  The two
    options were:

	(a) since we need an URG option anyway, steal the urgent
	field in the TCP header to get 8 more bits for each of the
	sequence # and the ack #.  These would be high order bits.

	(b) don't futz with the header (note that in most cases urgent
	data is likely to be within 2**16 of the current sequence number
	and thus the urgent field is still useful).  Instead, put an
	option at the end of each segment header, which contains an
	additional high order 16-bits of the sequence number and
	the ack number.

Based on experience, the WG will decide which path to take.
    
Craig
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 90 04:16:09 GMT
From:      snorkelwacker!mintaka!ogicse!plains!tinguely@tut.cis.ohio-state.edu  (Mark Tinguely)
To:        tcp-ip@nic.ddn.mil
Subject:   BIND TCP problem solved
Murphy was working against me again. I worked to a point of desperation, posted
a question to the net and found the solution a few hours later.

The bogus file descriptors and hash structure trashing were related,
if a resolution does a forward and queues the qstream structure on a
linked qinfo structure, and then before the forward can timeout out the TCP
connection is severed (detected by ns_main and initiates the removal of the
qstream in sqrm).  Eventually, the timer associated with the forward tries
to use the now released qstream havoc will follow with the error in the write
to a now bogus (and even if it was not bogus, it is at lease a closed) socket.
(this is not too serious).

The ns_forw code also writes on the old qstream space -- overwriting some
unfortunate structure that has since allocated that space. This is a critical
write when the new structure in this space is a hashbuf structure, causing
a bus or seqmentation error on the first occurrance of the structure.

I solved the problem, here, by checking and removing all qinfo entries
that refer to the qstream being deleted in sqrm(). I will provived the patches
to those that are interested, but this problem is for TCP CONNECTIONS ONLY,
and the symptom of this problem is FREQUENT coring of the name server.

-- 
Mark Tinguely           North Dakota State University,  Fargo, ND  58105
  UUCP:       		...!uunet!plains!tinguely
  BITNET:      		tinguely@plains.bitnet
  INTERNET:   		tinguely@plains.NoDak.edu
-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Feb 90 10:10:00 EST
From:      mep@aqua.whoi.edu (Michael E. Pare)
To:        ingr!b11!guy!guy@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Re:  SLIP on async lines
We have instances of people running slip from their home PC's (and MAC's)
over 9600baud dial up lines to get to their systems at work.  They use
NCSA Telnet on it with great success.  So it does work on async lines.
-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 90 07:54:51 GMT
From:      zaphod.mps.ohio-state.edu!uwm.edu!bionet!turbo.bio.net!alcor.usc.edu@tut.cis.ohio-state.edu  (Tony Li)
To:        tcp-ip@nic.ddn.mil
Subject:   comp.dcom.sys.cisco -- Second call for votes

A vote is currently underway for the creation of the newsgroup
comp.dcom.sys.cisco.  A mass acknowledgement has been posted to
news.groups.  Attached is the original call for votes:
----------------------------------------------------------------------

Group: 		comp.dcom.sys.cisco 

Charter: 	Vendor specific discussion about data communications
		products from cisco Systems Inc. 

Management: 	The group will be unmoderated.

Gateway:	The Internet cisco mailing list will have a one-way
		gateway into this group.  At some future time, the
		newsgroup may gateway into the mailing list.  This
		will be the topic of a separate vote, and should not
		be considered part of this newsgroup proposal.

Voting:		Votes should be sent to "tli@usc.edu" or "usc!tli".
		Per the USEnet newsgroup creation rules, votes must be
		explicit.  They should be of the form "I vote for the
		group comp.dcom.sys.cisco as proposed" or "I vote
		against the group comp.dcom.sys.cisco as proposed."
		Ambiguous votes will not count and will be returned to
		the sender.

Deadline:	Votes must be received by 11:59pm PST, Wed. Feb 28,
		1990 in my mailbox. 

Tony Li - USC Computer Science Department
Internet: tli@usc.edu Uucp: usc!tli
Thus spake the master programmer: "A well written program is its own
heaven; a poorly-written program its own hell."
-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 90 11:06:24 GMT
From:      cbmvax!grr@rutgers.edu  (George Robbins)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Ethernet Throughput (AMD vs. Intel vs. Seeq)
In article <29914@sparkyfs.istc.sri.com> rusti@milk0.itstd.sri.com.UUCP (Rusti Baker) writes:
> 
> E.G. Clark, Jacobson et al provided this insight into the 
> behavior of the LANCE in their June 1989 IEEE Comm.  article: 
> 
> "[the LANCE] locks up the memory bus during the transfer
> thus stalling the processor"

Again, this is not neccessarily an attribute of the Lance chip, but rather
how a particular interface/system implements the Lance DMA/memory interface.
A different interface might implement a (logically) dual ported buffer
memory or other scheme and thus avoid this particular constraint.

Clearly indentifying the thruput constraints for each of the major ethernet
chipsets (let along their common instantiations) would be a major task.  Chip
selection is usually done on the basis of cost, familiarity, ease of interface
and sometimes even avoidance of known problems...

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)
-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 90 12:57:06 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: TCP extensions


Fred:

    At the Internet Engineering Task Force Meeting last week a working
group made some progress on deciding what to do about the RFC 1072 options.
Here's a quick summary:

    (1) The RFC 1072 window shift option will be used to expand the
    window size (everyone likes it, and implementation is a snap).

    (2) We'll create a new Urgent Pointer option so it can point
    to urgent data anywhere in the expanded window.  (To use it,
    the URG bit is left off -- when the receiver processes options,
    it will see that there is urgent data).

    (3) The WG was divided among two options for expanded the sequence
    and ack space.  Thankfully some folks with supercomputers offerred
    to implement both options and report back this spring.  The two
    options were:

	(a) since we need an URG option anyway, steal the urgent
	field in the TCP header to get 8 more bits for each of the
	sequence # and the ack #.  These would be high order bits.

	(b) don't futz with the header (note that in most cases urgent
	data is likely to be within 2**16 of the current sequence number
	and thus the urgent field is still useful).  Instead, put an
	option at the end of each segment header, which contains an
	additional high order 16-bits of the sequence number and
	the ack number.

Based on experience, the WG will decide which path to take.
    
Craig

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 90 13:32:22 GMT
From:      zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!jarvis.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!davecb@tut.cis.ohio-state.edu  (David Collier-Brown)
To:        tcp-ip@nic.ddn.mil
Subject:   Simple smtp implementations requested

  Does anyone have a very simple smtp implementation for use
on leaf nodes (or DOS machines, or the like)?  Once upon a time
I did one for CP/M (and then lost it somewhere in a maze of
floppy disks, all alike), so I tend to regard it as a smallish
task...  save for the fact I'm lazy.

--dave
-- 
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.
-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 90 14:37:23 GMT
From:      deimos!dino!cs.iastate.edu!hascall@uunet.uu.net  (John Hascall)
To:        tcp-ip@nic.ddn.mil
Subject:   Proper handling of TCP PUSH by sender?

   Hi!

      I am working on a TCP implementation and have a question about
   the proper handling of PUSH by the sender which doesn't seem to
   be addressed (at least clearly) in any RFC I can find.   I would
   greatly appreciate any information anyone might have.

      Say you have two chunks of data (chunk1 and chunk2) from the user
   and chunk1 was PUSHed but chunk2 was not.  These two chunks have been
   held for whatever reason (window closed, unACKed data, whatever).
      Now, however, you are clear to send, I see three cases (associated
   with three different window sizes) and I am unsure what is the "right"
   thing to do in any of them.


         3 3 3 3 3 3 3 3 3 3 4 4|4 4 4 4 4 4 4 4 5 5 5     (example sequence
         0 1 2 3 4 5 6 7 8 9 0 1|2 3 4 5 6 7 8 9 0 1 2      number space)
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |         chunk1        |        chunk2       |
        +-+-+-+-+-+-+-+-+-+-+-+p+-+-+-+-+-+-+-+-+-+-+-+

 case 1 |<--window--->|
 case 2 |<----------window----------->|
 case 3 |<--------------------window--------------------->|
     

    Case 1:  do I hold off, waiting for a bigger window?  (deadlock?)
             do I send what I can?                        (efficiency?)

    Case 2:  do I hold off, waiting for a bigger window?  (doesn't seem right)
             do I send only chunk1 (setting PUSH)         (my current guess)
             do I send all I can (setting PUSH)           (too much pushed?)

    Case 3:  do I send only chunk1 (setting PUSH)         (correct?)
             do I send it all (setting PUSH)              (too much pushed?)


Thanks for any help, pointers, references you might have,
John Hascall  /  Iowa State Univ  /  hascall@atanasoff.cs.iastate.edu
-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 90 15:53:08 GMT
From:      wasmith@gollum.UUCP (Wayne A. Smith)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Multiple Master Servers for NFS YP

Why does Yellow Pages in NFS restrict there being only one
master server per domain? What makes multiple masters difficult
to implement? Are there some design constraints on Sun of which
I am not aware? What I want is to have a replicated master on the
net so that if one master goes down (machines don't break, do they?),
the other can respond to requests. This provides more reliability.
Is there any way to provide this functionality myself. Is there
a way to automate changing a slave server to a master when THE master
goes down?
  
Thanks in advance to any who respond.
 
Wayne Smith
E&M Columbia
NCR Corporation
wasmith@ncrcae.Columbia.NCR.COM

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 90 15:36:08+0100
From:      Inge Dahl <Inge.Dahl@sintef.no>
To:        <TCP-IP@SRI-NIC.arpa>
Subject:   Ethernet type 80F3 ?
I have a piece of information that include ethernet type or IEEE802.3 type
packet Hex 80F3 and identifies it to :

Appletalk Address Resolution Protocol (AARP).

My list probably come from URBANIAK@G.BBN.COM or

   US Mail at   Bolt, Beranek & Newman, Inc
   10 Fawcett Street
   Cambridge , MA 02138
   att: Walter Urbaniak, MS021

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 90 17:55:53 GMT
From:      cs.utexas.edu!samsung!umich!sharkey!cfctech!teemc!ka3ovk!ki4pv!cdin-1!dsinc!netnews.upenn.edu!cps3xx!raja@tut.cis.ohio-state.edu
To:        tcp-ip@nic.ddn.mil
Subject:   WANTED:  communications software "KA9Q"

If you know where I can get a public
domain communications package called
"KA9Q", could you please email me?

Thank you.


Narayan Sriranga Raja.
  raja%frith.egr.msu.edu@uunet.uu.net
-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 90 18:02:50 GMT
From:      amdahl!twg.com!lefty@apple.com  (David N. Schlesinger)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Ethernet type 80F3 ?
In article <4981@emory.mathcs.emory.edu> km@mathcs.emory.edu (Ken 
Mandelberg) writes:
> Does anyone recognize ethernet type "80F3"? I don't see it in RFC1010, 
> but I am seeing it on our net.

Ethernet type 0x80F3 is used by AppleTalk for address resolution.  You 
must have Macs on your network which are directly connected to Ethernet.  
These packets are used by the Mac (generally at startup) to determine a valid AppleTalk node number.

There are basically three flavors of AARP (AppleTalk Address Resolution 
Protocol) packets: request, response and probe.  These can be distinguished by the value in the word at offset 20 in the packet: a value of 1 is a Request, 2 is a Response and 3 is a Probe.

Starting at offset 22, these packets will contain the following: a source 
Ethernet address (6 bytes), a source AppleTalk address (4 bytes),  a 
destination Ethernet address (in the case of a Response; 0 otherwise) (6 
bytes), and an AppleTalk address (4 bytes).  Details of what's actually going 
on with these can be found in "Inside AppleTalk", published by 
Addison-Wesley.  See chapters 2 and 3 on "AppleTalk Address Resolution 
Protocol" and "Ethernet Link Access Protocol" respectively.

Hope this helps.

Lefty

===========================================================================
          David N. Schlesinger   || "There's a word for it: words don't
          The Wollongong Group   ||  mean a thing.  There's a name for it;
Internet: Lefty@twg.com          ||  names make all the difference in the
POTS:     415/962-7219           ||  world..." -- David Byrne
===========================================================================
-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 90 18:36:28 GMT
From:      zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!brutus.cs.uiuc.edu!jarthur!elroy.jpl.nasa.gov!hacgate!janus!todd@tut.cis.ohio-state.edu  (Todd Booth)
To:        tcp-ip@nic.ddn.mil
Subject:   Subnet Mask Problems
Hi netWorkers,

It appears that a lot of TCP/IP software out there does not fully
support subnetting.  Is this true?  I'd like to use the last 6 bits
for host addresses and therefore the netmask is 0xffffffc0.  This
would translate the ip address 130.224.4.78 into:

net:  130.224.4.64
host:   0.000.0.14
------------------
      130.224.4.78, right?

But when I set up my routing tables with 

route add net 130.224.4.64 130.224.4.78 0

lots of TCP/IP software has trouble.  The software appears to assume that
a subnet can't use any of the last 8 bits.
 
--todd 

ps. I can't wait to get back on internet (estimated date - next week).
-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 90 20:00:40 GMT
From:      amdcad!pepsi!phil@ucbvax.Berkeley.EDU  (Phil Ngai)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Ethernet Throughput (AMD vs. Intel vs. Seeq)
In article <29914@sparkyfs.istc.sri.com> rusti@milk0.itstd.sri.com.UUCP (Rusti Baker) writes:
|"[the LANCE] locks up the memory bus during the transfer
|thus stalling the processor"

My guess as to what was meant by this is that they are talking about the
LANCE requiring 600 ns to perform a memory cycle. That is, a zero wait
state memory cycle is 600 ns. (I don't know if you can do wait states.
This is based on my experience 6 years ago.) Although this might not
have been considered unusual when the LANCE came out in the early 80's,
10 MHz processors were only a dream at the time) it may seem slow in
an age of 25 MHz processors.

Any DMA device will lock up the memory bus, the question is how long?
The people who wrote your quote probably thought 600 ns was too long.

This is the kind of thing that a new device would probably do better.

I am not an official or unofficial spokesman for the company. This
is only my opinion.

Copyright 1990 by Phil Ngai. You may only distribute with the above
disclaimer.

--
Phil Ngai, phil@amd.com		{uunet,decwrl,ucbvax}!amdcad!phil
When guns are outlawed, only governments will have guns.
-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 90 20:40:33 GMT
From:      hercules!sparkyfs!milk0.itstd.sri.com!rusti@apple.com  (Rusti Baker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Ethernet Throughput (AMD vs. Intel vs. Seeq)

Thanks to Mark Montgomery and George Robbins for clarification of the
problem of characterizing the performance of a chip set without considering
the interface/system.

>	Also if you'll re-read the article you'll see that what they
>	were saying was that the LANCE was "stalling" the cpu while
>	it did dma of the packet directly to memory.  Can't do that
>	with an XYZ chip.  Of course you could have the cpu do the
>	transfers or you could build a cache if you'd rather.
>				Mark

I was intrigued by the use of the word "stalling", versus "blocking" etc.
I had interpreted the remark in the article to mean that there was something
else going on (like the DMA had some other side effect).  Since the
authors did not elaborate, I was curious.
-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 90 20:57:31 GMT
From:      matrix!neeraj@uunet.uu.net  (neeraj sangal)
To:        tcp-ip@nic.ddn.mil
Subject:   Questions about IEEE 802 packets on ethernet media

I understand Ethernet packets and now I am trying to understand IEEE802
packets.  (Please bear with me if these are naive questions).  According
to what I understand by looking at the limited documentation I have,
the 802.3+802.2 packet looks as follows:

	destination	6 bytes
	source		6 bytes
	length		2 bytes	(must be less than 0x0600)

	dsap		1 byte
	ssap		1 byte
	control		1 byte

If dsap = ssap = 170 then the following fields (SNAP header) are also included:

	protid		3 bytes (always 0)
	ethertype	2 bytes


Questions:

1. Is the ethertype same as the ethertype in ethernet packet header?

2. Will dsap and ssap ever be different i.e.  What is the justification for
   having two numbers?

3. In practice which protocols use SNAP. I think IP uses SNAP, do
   other protocols such as DECNET, Apple Talk, Novell etc. which
   have ethertype assigned to them always use SNAP or do they have
   newer dsap and ssap numbers assigned to them?

4. Which protocols do not use SNAP?  What are the current assigned
   values of dsap and ssap?

4. When is protid not zero?

Any answers or pointers to where answers could be found will be
greatly appreciated.  Please email directly to me. Thanks.

Neeraj Sangal
Matrix Computer Systems, Inc.           7 1/2 Harris Rd, Nashua, NH 03062
uunet!matrix!neeraj                     (603) 888-7790
-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 90 22:44:44 GMT
From:      chuq@Apple.COM (Chuq Von Rospach)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Multiple Master Servers for NFS YP

wasmith@gollum.UUCP (Wayne A. Smith) writes:

>Why does Yellow Pages in NFS restrict there being only one
>master server per domain? What makes multiple masters difficult
>to implement?

The concept of the master server is to have one place where the original
data resides, so there is only one place where the data has to be changed,
letting the system worry about propogation details. Having multiple master
servers by definition screws this up because each would have separate master
databases, meaning it's much more likely that data will get out of sync.

>Are there some design constraints on Sun of which
>I am not aware? What I want is to have a replicated master on the
>net so that if one master goes down (machines don't break, do they?),
>the other can respond to requests. This provides more reliability.

What you really want (based on what you just said) is to have a single
master server and a series of slave servers. The servers read the data from
the master server, you only update the data in a single place, and if the
master server goes down the slaves take up the slack and continue offering
the service until it comes back up. the only limitation is you can't make
changes to the data on a slave server, so you can't update databases when
the master is down (on the other hand, if your master crashes, you're
probably doing other things than adding users, anyway...)


-- 

Chuq Von Rospach   <+>   chuq@apple.com   <+>   [This is myself speaking]

Rumour has it that Larry Wall, author of RN, is a finalist in the race for
the Nobel Peace Prize for his invention of the kill file.

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 90 01:40:42 GMT
From:      attctc!sulaco!allen@EDDIE.MIT.EDU  (Allen Gwinn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TN3270 for PCs/MACs, Summary Posting
In article <1990Feb8.204127.3258@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes:

>For VT102 + TN3270, the cost is $295.00 for a single copy.  For VT240+TN3270,
>it's $495.00.  

Or you can get NCSA Telnet and/or PCIP for free from your friendly
neighborhood uunet :-)
-- 
Allen Gwinn  sulaco!allen      DISCLAIMER: The opinions, if any, are my own.
"You insecure, obscure, homozygous adolecent.  Take your plebe-infested,
 flea-bitten rectum to the closest 220VAC outlet, and learn the true
 meaning of the word flame." - Jim Thompson   jthomp@central.sun.com
-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 90 04:27:29 GMT
From:      wiltzius@lll-lcc.llnl.gov  (Dave P. Wiltzius)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP Retries

I'm testing my port of a version of 4.3BSD TCP/IP code.  In
doing so, I discard in the loopback driver every Nth packet
(say, N=10).  This results in the MBUF pool being quickly
depleted.  I discovered that the TCP input routine will
save all out of order TCP packets waiting for the TCP retry
to fill in the gaps.  Hence most of the MBUF pool is
enqueued on this TCP fragment/reassembly list for this
TCPCB.  Also, the sender continues to get ACKs advertising
the largest window since the receive socket buffer is
empty.

Nothing particularly evil happens and since this is
a very degenerate case, perhaps I should just shrug
my shoulders and go on with life.  But it does bother
me a bit - rightfully so?  (Couldn't the window advertised
by the receiver close, or a limit made on the number
of out-of-order TCP packets on a TCPCB?)

Thanks for any help.
  Dave (wiltzius@lll-lcc.llnl.gov)
-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Feb 90 10:33:03 EST
From:      Jack Haverty <haverty@BBN.COM>
To:        zaphod.mps.ohio-state.edu!usc!srhqla!nrcvax!ihm@tut.cis.ohio-state.edu
Cc:        haverty@BBN.COM, tcp-ip@nic.ddn.mil
Subject:   Re:  About RFCs in Postscript and Ascii
Re: Postscript/ascii RFCs

Sorry for the gap in this "conversation" - I spent a week at COMNET
electronically incommunicado in a sea of products from the
communications industry!

Vint clarified the intent of the policy for me - to provide machine-processable
versions of all RFCs for ease of searching, etc.  I fully support that notion;
after all, we're supposed to be applying computers and communications to 
getting work done in a better way than manual brute-force techniques.

At the risk of opening yet another round.....

Speaking of brute force, perhaps interesting documents on the Internet
should be made available in SEARCHABLE format, as the next obvious step
beyond ascii and FTP.  By this I mean supplementing the "file servers"
which are sprinkled throughout the system with database servers in which
the documents are stored, and which could be queried through some kind
of language (SQL, grep, whatever). Rather than forcing everyone to FTP
all of the files to all of their local computers, and search them there,
we could allow people to send queries to the server machine(s) to find
the identity of relevant documents which could then be transferred.

This idea is of course hardly new - the "DataComputer" on the Arpanet in
1975 or so provided such a capability, and services such as IQUEST accessible
through networks such as CompuServe provide similar capabilities for the more
formal publications.

Perhaps such a capability should now be on the Internet?  Is anyone thinking or
working on this?  Maybe it already exists and I'm just not aware of it?

Jack
-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Feb 90 12:13:03 EST
From:      Guest <guest@osi3.ncsl.nist.gov>
To:        iso-relay@nic.ddn.mil, tcp-ip@nic.ddn.mil
Subject:   US GOSIP and related document information
														Feb. 13, 1990

There are often questions about where to obtain documents relating to GOSIP, in
particular, GOSIP, the Implementors Agreements, and the GOSIP Users' Guide.  I
put together the information provided below to answer these questions.  For
further information contact one of the individuals or organizations identified
most closely with your question; do not respond to this address except with
helpful comments (e.g., additional information that we might provide in the
future), as no one reads the mail on this account with any regularity.  NIST
will periodically reissue updated versions of this letter as information
changes.

Hope this helps,
Richard Colella
NIST

-------------------------------cut here-------------------------------------


Jan 24 09:37 1990  NIST Documents Page 1


							January 19, 1990

Below is the information needed to obtain the U.S. GOSIP and NIST/OSI Implemen-
tors Workshop (OIW) documents.  All prices are in U.S. dollars and represent
the most up-to-date information available at this time; for further pricing
information and ordering details, contact the seller (all addresses and tele-
phone numbers are to be found at the end).


                                 +-------+
                                 | GOSIP |
                                 +-------+

GOSIP Version 1.
----------------

GOSIP Version 1 (Federal Information Processing Standard 146) was published in
August 1988.  It becomes mandatory in applicable federal procurements in August
1990.

    NIST Point of Contact:
	Jerry Mulvenna

    hardcopy:
	NTIS
	Order Number: FIPS PUB 146
	Price: $17.00 (paper); $8.00 (microfiche)

    on-line:
	The federal register announcement, FIPS 146, as well as GOSIP
	are available:

        - through anonymous ftp from nic.ddn.mil (10.0.0.52, 26.0.0.73) as

		<PROTOCOLS>GOSIP-FEDREG.TXT
		<PROTOCOLS>GOSIP-FIPS-DRAFT.TXT
		<PROTOCOLS>GOSIP-V1.TXT

	- through anonymous ftp or FTAM (ISODE 5.0, user: ftam, realstore=unix)
	  from osi3.ncsl.nist.gov (129.6.48.100) as

		./pub/gosip/gosip_v1_fedreg.txt		-- ascii
		./pub/gosip/fips146_draft.txt		-- ascii
		./pub/gosip/gosip_v1.txt		-- ascii
		./pub/gosip/gosip_v1.txt.Z		-- ...compressed



GOSIP Version 2.
----------------

GOSIP Version 2 is currently a draft.  It has undergone public review and
comment.  Comments will be addressed by the GOSIP Advanced Requirements
Committee in March, 1990.  Final text is expected to be available in June,
1990.








Jan 24 09:37 1990  NIST Documents Page 2



    NIST Point of Contact:
	Jerry Mulvenna

    hardcopy:
        NIST Standards Processing Coordinator (ADP)
 
    on-line:
        available through anonymous ftp or FTAM (ISODE 5.0, user: ftam,
        realstore=unix) from osi3.ncsl.nist.gov (129.6.48.100) as
 
                ./pub/gosip/gosip_v2_draft.txt		-- ascii
                ./pub/gosip/gosip_v2_draft.txt.Z	-- ...compressed
                ./pub/gosip/gosip_v2_draft.ps		-- PostScript
                ./pub/gosip/gosip_v2_draft.ps.Z		-- ...compressed

	available through anonymous ftp from nic.ddn.mil (10.0.0.52,
	26.0.0.73) as

		<PROTOCOLS>GOSIP-V2-DRAFT.DOC
 
 

             +-------------------------------------------------+
             | NIST Workshop for Implementors of OSI Documents |
             +-------------------------------------------------+

The output of the NIST Workshop for Implementors of OSI (OIW) is a pair of
aligned documents, one representing Stable Implementation Agreements (SIA), the
other containing Working Implementation Agreements (WIA) that have not yet gone
into the stable document.  Material is in either one or the other of these
documents, but not both, and the documents have the same index structure.

The SIA is reproduced in its entirety at the beginning of each calendar year,
with an incremented version number.  Replacement page sets are distributed
subsequently three times during each year (after each Workshop), reflecting
errata to the stable material.  The replacement pages constitute the next
edition of that year's version.

The WIA is reproduced in its entirety after each Workshop (held in March, June,
September and December). OIW attendees automatically receive the WIA.  OIW meet-
ing dates in 1990 are: March 12-16; June 18-22; September 10-14; and December
10-14.

    NIST Points of Contact:

	Tim Boland	--management information
	Chairman, OIW

	Brenda Gray	--administrative information
	OIW Registrar












Jan 24 09:37 1990  NIST Documents Page 3



SIA, Version 1.
--------------

SIA, Version 1, Edition 1 (Dec, 1987).

The SIA, V1E1 is published as NIST Special Publication 500-150.  It is the
appropriate version and edition of the SIA for GOSIP Version 1 (FIPS 146).

    hardcopy:
	U.S. Government Printing Office
	GPO Stock Number: 003-02838-0
	Price: $20.00

	NTIS
	Order Number: PB 88-168331
	Price: $31.00 (paper); $8.00 (microfiche)


SIA, Version 1, Edition 3 (August, 1988).

The SIA, V1E3 is also published as NBS Special Publication 500-150 (note the
different GPO Stock Number when ordering).

    hardcopy:
        U.S. Government Printing Office
        GPO Stock Number: 003-003-02838-0
        Price: $12.00 (paper)

    on-line:
        available through anonymous ftp or FTAM (ISODE 5.0, user: ftam,
        realstore=unix) from from osi3.ncsl.nist.gov (129.6.48.100) as

                ./pub/gosip/nist_osiws_sia_v1e3.txt          -- ascii
                ./pub/gosip/nist_osiws_sia_v1e3.txt.Z        -- ...compressed

        available through anonymous ftp from nic.ddn.mil (10.0.0.52,
        26.0.0.73) as
 
		<PROTOCOLS>NBSOSI-AGREEMENTS.DOC
 

SIA, Version 2.
--------------

SIA, Version 2, Edition 1 (Dec, 1988).

The SIA, V2E1 is published as NBS Special Publication 500-162.
 
    hardcopy:
 
        U.S. Government Printing Office 
        GPO Stock Number: 003-003-02921-1
        Price: $26.00
 








Jan 24 09:37 1990  NIST Documents Page 4


	IEEE Computer Society
	ISBN 0-8186-9022-4
	Book No. 2022
	Price: $75.00 (casebound)
	(a subscription service is available from IEEE)

	NTIS
	Order Number: PB 89193312
	Price: $53.00 (paper); $8.00 (microfiche)


SIA, Version 2, Editions 2-4.

These are available as hardcopy from NIST staff, subject to staff availability. 
Contact:

	Brenda Gray	--administrative information
	OIW Registrar


SIA, Version 3, Edition 1 (Dec, 1989).

The SIA V3E1 is expected to be available in the first half of 1990.  It may be
ordered from the IEEE Computer Society and the U.S. GPO.  Future editions of
Version 3 are expected to be available from NTIS, and possibly GPO and the IEEE
Computer Society.


WIA (August, 1989).
------------------

The August, 1989 WIA, published as a NIST Interagency Report (IR-89-4140) is
the most recent copy of the WIA that is available to order.  The December, 1989
WIA will be available from NTIS and the IEEE Computer Society in the spring of
1990.  The August, 1989 WIA (NIST IR-89-4140) is available in hardcopy from:

	NTIS
	Order Number: PB 89235931/AS
	Price: $36.95 (paper); $6.95 (microfiche)



                           +--------------------+
                           | GOSIP Users' Guide |
                           +--------------------+

This publication assists federal agencies in planning for and procuring OSI.
It provides tutorial information on OSI protocols as well as information on OSI
registration, GOSIP technical evaluation, and GOSIP transition strategies.

    hardcopy:

	NTIS
	Order Number: PB 90-111212
	Price: $23 (paper); $8 (microfiche)








Jan 24 09:37 1990  NIST Documents Page 5




                      +-----------------------------+
                      | Addresses/Telephone Numbers |
                      +-----------------------------+

	Jerry Mulvenna
	Technology, B217
	Gaithersburg, MD  20899
	(301) 975-3631
	mulvenna@ecf.ncsl.nist.gov

	Tim Boland	--management information
	Chairman, OIW
	Technology, B217
	Gaithersburg, MD  20899
	(301) 975-3608
	boland@ecf.ncsl.nist.gov

	Brenda Gray	--administrative information
	OIW Registrar
	Technology, B217
	Gaithersburg, MD  20899
	(301) 975-3664

	National Technical Information Service (NTIS)
	U.S. Department of Commerce
	5285 Port Royal Road
	Springfield, VA  22161
	(703)487-4650

	IEEE Computer Society
	Order Department
	10662 Los Vaqueros Circle
	Los Alamitos, CA  90720
	1-800-272-6657

	U.S. Government Printing Office 
	Washington, DC  20402 
	(202) 783-3238

	Standards Processing Coordinator (ADP)
	National Institute of Standards and Technology
	Technology Building, Room B-64
	Gaithersburg, MD  20899
	(301) 975-2816















-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Feb 90 12:39:55 EST
From:      sbbur%CONNCOLL.BITNET@CUNYVM.CUNY.EDU
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Looking for PC Telnet with printer port support
Does anyone know of a PC Telnet implementation with vt100 terminal emulation
that supports printing to a local printer via auto-print mode?

We're currently running NCSA Telnet 2.2.  Although it does support a
"capture file", it doesn't seem to support a local printer.

Thanks.

Scott Burdick                   BITNET:  sbbur@conncoll
Connecticut College
New London, CT  06320
(203) 447-7516

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Feb 90 14:23:11 EST
From:      Robert Allen Woodburn <woody@SAIC.COM>
To:        tcp-ip@nic.ddn.mil
Subject:   Making modifications to UNIX IP routing code...

Has anyone tried using the Tahoe IP routing code on a SUN workstation (OS 4.0.1)
We're gearing up to do some experiments in the ORWG and we'd like to get
started as quickly as possible.  I have tried using the Tahoe version
of net/route.c, but it seems to break my kernel a bit.  Any thoughts?  Is
this a plain stupid idea?

wood y
-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Tue 13 Feb 90 17:37:29-PST
From:      William "Chops" Westfield <BILLW@MATHOM.CISCO.COM>
To:        hercules!sparkyfs!milk0.itstd.sri.com!rusti@APPLE.COM
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: TCP Ethernet Throughput (AMD vs. Intel vs. Seeq)
What happens is that the ethernet chips (both the Lance and Intel chips),
in their efforts to do fancy buffer managment, operate in a manner
similar to a processor (bus master), and have to share the bus with
the CPU chip.  To do this they implement a general purpose DMA scheme
that goes something like this:

	Ethernet: Can I have the bus?
	CPU:	OK (from this point on, the CPU can't access memory, and
		is "stalled").
	Ethernet: Lets, see, heres some address.  Now the address is valid,
		and here is some data... (and so on, hopefully for several
		words worth of data transfer).
	Ethernet: Ok, Im done.
	CPU:	Ok, I can start using the bus again...

This has the following problem:

    o	The DMA handshake takes several cycles, durring which no
	"useful" work is being done.
    o	The Lance and Intel chips both use multiplexed address/data
	pins, so that memory accesses by them take more cycles than
	they really ought to.
    o	The clock on the ethernet chip is typically 10MHz - much slower
	than most modern CPU chips.  This slows down both the memory
	accesses by the ethernet chip, and the the DMA handshake.
    o	A quick look at my lance book shows that the lance will
	take about 600 nS to read one word of memory - an eternity
	in a world of 80 nS main memory and 25 nS caches... Another
	250 nS goes by in between the time the DMA handshake finishes
	and the first DMA access starts.

So that's how ethernet controllers can "stall" a processor.  As others
have pointed out - clever hardware designs can get around this by using
dual ported memory, or other features.

Intel, AMD, and NS all have second generation chips out now.  I don't
know anything about them.  I do know that we in "higher level"
industry view any new chips with deep suspicion - early versions of
the first generation each had their share of serious bugs.  The Lance
and competitors may not be perfect, but at least they have reached the
point where they are fairly well understood.

BillW
-------
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 90 12:00:41 GMT
From:      scfisher@dtoa1.dt.navy.mil (Fisher)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Multiple Master Servers for NFS YP

In article <38566@apple.Apple.COM> chuq@Apple.COM (Chuq Von Rospach) writes:
>wasmith@gollum.UUCP (Wayne A. Smith) writes:
8>
8>>Why does Yellow Pages in NFS restrict there being only one
8>>I am not aware? What I want is to have a replicated master on the
8>>net so that if one master goes down (machines don't break, do they?),
8>>the other can respond to requests. This provides more reliability.
8>
8>What you really want (based on what you just said) is to have a single
8>master server and a series of slave servers. The servers read the data from
8>the master server, you only update the data in a single place, and if the
8>master server goes down the slaves take up the slack and continue offering
8>the service until it comes back up. the only limitation is you can't make
8>changes to the data on a slave server, so you can't update databases when
8>the master is down (on the other hand, if your master crashes, you're
8>probably doing other things than adding users, anyway...)
8>
8>
Yes, but what happens if the power goes out, and the master & slaves shut down,
and when the power goes back on, the master won't come back up?  My slaves
on my network don't seem to retain their data from prior to the power outage.



steve.

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Feb 90 17:40:37 EST
From:      ted@NADC.ARPA (T. Calkins)
To:        tcp-ip@nic.ddn.mil
Subject:   4.3BSD Ether Setup
 
We are having somewhat of a problem getting the UNIX(tm) 4.3BSD tables
setup correctly for an ethernet. Hopefully someone has seen this before
and can point the error(s).
 
We have an (unofficial) Class B address of 190.200. Using a DEC DELUA
card. First, setting the tables as follows:
 
/etc/hosts:
	127.0.0.1		localhost
	#
	190.200.46.1		devvax1.arpa devvax1
	190.200.35.1		sun386i
	190.200.38.1		apollo1
	190.200.1.2		NCS2
	    :			  :
 
/etc/networks:
	local-net		190.200.46
	loopback		127.0.0
	   :			   :
 
/etc/rc.local
	hostname devvax1
	   :
	ifconfig de0 inet `hostname` -trailers up netmask 255.255.255.0
	ifconfig lo0 localhost
	route add `hostname` localhost 0
	   :
 
Now then, the command "ifconfig de0" produces,
	de0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
	        inet  190.200.46.1 netmask ffffff00 broadcast 190.200.46.255
And, the command "ifconfig lo0" produces,
	lo0: flags=9<UP,LOOPBACK>
	        inet  127.0.0.1 netmask ff000000
The command "netstat -in", produces,
	Name   Mtu    Network     Address      Ipkts   Ierrs Opkts  Oerrs Collis
	de0    1500   190.200.46  190.200.46.1 253     0     13     0     0
 	lo0    1536   127         127.0.0.1    56      0     56     0     0
And, the command "netstat -rn", produces,
	Routing tables
	Destination           Gateway             Flags     Refcnt Use     Interface
        190.200.46.1          127.0.0.1           UH        0      38      lo0
        127.0.0.1             127.0.0.1           UH        0      18      lo0
        190.200.46            190.200.46.1        U         2      9       de0
 
   The kicker, with this setup, is that one can 'telnet localhost' ok,
but attempting to access the net via telnet produces
	Trying...
	telnet: connect: Network is unreachable
 
   Now, if all that gets changed is the ifconfig statement in the /etc/
rc.local file, as follows,
 
/etc/rc.local
	hostname devvax1
	   :
	ifconfig de0 inet `hostname` -trailers up netmask 255.255.0.0
 
The command "ifconfig de0" produces
	de0: flags=67<UP,BROADCAST,NOTRAILERS,RUNNING>
	        inet 190.200.46.1 netmask ffff0000 broadcast 190.200.255.255
 
And, the command "ifconfig lo0" produces,
	lo0: flags=8<LOOPBACK>
 
THe command "netstat -in" produces,
	Name   Mtu   Network    Address      Ipkts   Ierrs Opkts   Oerrs Collis
	de0    1500  190.200    190.200.46.1 1134    0     736     0     0
        lo0*   1536  none       none         0       0     0       0     0
 
And the command "netstat -rn" produces,
	Routing tables
	Destination           Gateway          Flags       Refcnt   Use    Interf
	192                   190.200.99.100   UG          0        0      De0
        190.200               190.200.46.1     U           2        730    de0
        193                   190.200.99.100   UG          0        0      de0
   Now, attempting 'telnet localhost' produces "localhost: unknown host"
and it is possible to access the hosts on the ethernet.
   Any help, is of course, much appreciated.
   (Have I omitted anything?)
                               Ted Calkins  ( ted@NADC.NAVY.MIL ) 
-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 90 14:58:34 GMT
From:      dino!cs.iastate.edu!hascall@uunet.uu.net  (John Hascall)
To:        tcp-ip@nic.ddn.mil
Subject:   Proper handling of PUSH & small window by sender?

 [I sent this a few days ago (probably with a different subject), but
  never saw it here, so I'm trying again (sorry if you got this twice).]

   Hi!

      I am working on a TCP implementation and have a question about
   the proper handling of PUSH by the sender which doesn't seem to
   be addressed (at least clearly) in any RFC I can find.   I would
   greatly appreciate any information anyone might have.

      Say you have two chunks of data (chunk1 and chunk2) from the user
   and chunk1 was PUSHed but chunk2 was not.  These two chunks have been
   held for whatever reason (window closed, unACKed data, whatever).
      Now, however, you are clear to send, I see three cases (associated
   with three different window sizes) and I am unsure what is the "right"
   thing to do in any of them.


         3 3 3 3 3 3 3 3 3 3 4 4|4 4 4 4 4 4 4 4 5 5 5     (example sequence
         0 1 2 3 4 5 6 7 8 9 0 1|2 3 4 5 6 7 8 9 0 1 2      number space)
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |         chunk1        |        chunk2       |
        +-+-+-+-+-+-+-+-+-+-+-+p+-+-+-+-+-+-+-+-+-+-+-+

 case 1 |<--window--->|
 case 2 |<----------window----------->|
 case 3 |<--------------------window--------------------->|
     

    Case 1:  do I hold off, waiting for a bigger window?  (deadlock?)
             do I send what I can?                        (efficiency?)

    Case 2:  do I hold off, waiting for a bigger window?  (doesn't seem right)
             do I send only chunk1 (setting PUSH)         (my current guess)
             do I send all I can (setting PUSH)           (too much pushed?)

    Case 3:  do I send only chunk1 (setting PUSH)         (correct?)
             do I send it all (setting PUSH)              (too much pushed?)


Thanks for any help, pointers, references you might have,
John Hascall  /  Iowa State Univ  /  hascall@atanasoff.cs.iastate.edu
-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 90 15:33:03 GMT
From:      haverty@BBN.COM (Jack Haverty)
To:        comp.protocols.tcp-ip
Subject:   Re:  About RFCs in Postscript and Ascii

Re: Postscript/ascii RFCs

Sorry for the gap in this "conversation" - I spent a week at COMNET
electronically incommunicado in a sea of products from the
communications industry!

Vint clarified the intent of the policy for me - to provide machine-processable
versions of all RFCs for ease of searching, etc.  I fully support that notion;
after all, we're supposed to be applying computers and communications to 
getting work done in a better way than manual brute-force techniques.

At the risk of opening yet another round.....

Speaking of brute force, perhaps interesting documents on the Internet
should be made available in SEARCHABLE format, as the next obvious step
beyond ascii and FTP.  By this I mean supplementing the "file servers"
which are sprinkled throughout the system with database servers in which
the documents are stored, and which could be queried through some kind
of language (SQL, grep, whatever). Rather than forcing everyone to FTP
all of the files to all of their local computers, and search them there,
we could allow people to send queries to the server machine(s) to find
the identity of relevant documents which could then be transferred.

This idea is of course hardly new - the "DataComputer" on the Arpanet in
1975 or so provided such a capability, and services such as IQUEST accessible
through networks such as CompuServe provide similar capabilities for the more
formal publications.

Perhaps such a capability should now be on the Internet?  Is anyone thinking or
working on this?  Maybe it already exists and I'm just not aware of it?

Jack

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 90 15:50:18 GMT
From:      mentor.cc.purdue.edu!dls@purdue.edu  (David L Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Proper handling of PUSH & small window by sender?
In article <589@dino.cs.iastate.edu>, hascall@cs.iastate.edu (John Hascall) writes:
>         +-+-+-+-+-+-+-+-+-+-+-+p+-+-+-+-+-+-+-+-+-+-+-+
>  case 1 |<--window--->|
>  case 2 |<----------window----------->|
>  case 3 |<--------------------window--------------------->|
> 
>     Case 1:  do I hold off, waiting for a bigger window?  (deadlock?)

	I'd say this depends on how big a segment you can send. If you can
send multiple full segments for chunk1, send all the full segments you can
up to the window (no "PUSH" set). When the window opens past chunk1, you
send that segment promptly (full or not) with PUSH set.

>     Case 2:  do I hold off, waiting for a bigger window?  (doesn't seem right)
>              do I send only chunk1 (setting PUSH)         (my current guess)
>              do I send all I can (setting PUSH)           (too much pushed?)

	I say the 3rd, because it says that "...PUSH bit will be set in the
last TCP segent created from the buffer." Since PUSH is not a record mark,
that segment can contain other data as well. It should not WAIT for other
data (buffering), but if the data is there already... In other words, this
interpretation is "send AT LEAST chunk1 promptly." Since PUSH is to avoid
buffering delays (and NOT, for example, for URGENT data), it's ok to use
the extra buffer the receiver has told you he has. The user will get a more
full buffer on his receive (better) and that's ok, because PUSH is not a
record mark.

>     Case 3:  do I send only chunk1 (setting PUSH)         (correct?)
>              do I send it all (setting PUSH)              (too much pushed?)

	Send it all. Set PUSH in the segment containing data that corresponded
to the last octets of "chunk1". Again, if the receiver has the buffer space, it
makes everything better.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 90 16:12:47 GMT
From:      mcsun!ukc!axion!planet!mdc@uunet.uu.net  (Martin Chapman)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Voice over Ethernet

In reponse to the following: 

 Does anybody out there know of any voice/phone packages that run over ethernet
 (and/or TCP/IP). I am interested in being able to plug in a microphone or
 telephone into my Sun Sparc station, and be able to phone other people on the
 net.

Here are some of the replies. 

  >From: dwf@gov.lanl.acl.hope
  >
  >Get the audio.shar file from expo.lcs.mit.edu in the contrib
  >directory.  It implements an audio extension to X and allows one to
  >talk with a microphone to any number of other Workstations, sort of a
  >conference call. Pretty slick.  Who needs the telephone company?
  >
  >David Forslund
  >Advanced Computing Laboratory
  >MS B287
  >Los Alamos National Laboratory
  >Los Alamos, NM 87545
  >
  >(505) 665-1907
  >(dwf@lanl.gov)

  >From: bender@com.sun
  >
  > You could try something like this (check my syntax):
  >
  >   $ rsh remote_machine cat \>/dev/audio </dev/audio
  >
  >this should take whatever you input over the audio port and send
  >it to the remote machine's audio port
  >
  >mike bender
  >sun

  >From: gnu@com.toad
  >
  >The program "/usr/demo/sound" can be hacked down to do this.
  >Probably the best thing to do is to split it into two programs,
  >one that just plays sounds from standard input, the other records
  >sounds and spits them out on standard output.  Then you can do:
  >
  >   $ mike | rsh hostname speaker
  >   $ rsh hostname mike | speaker
  >
  >and have a two-way audio conduit set 
  >	John Gilmore

  >From: sakoh@jp.co.sra.us.sraco2
  >
  >Yes, I have one.
  >
  >Actually it was posted onto the news group 'fj.sources' in 
  >JUNET (japan university network). It's called vtalk (voice talk).
  >
  >The author's e-mail address is:
  >
  >	kamei@cs1.cs.oki.co.jp
  >
  >I also have a copy of the source, and I can send it to you.
  >Unfortunately, all documents are written in Japanese.
  >But it would be easy to install since it is a very small (== 1K lines in C)
  >program.
  >
  >-- H. Sakoh
  >
  >				sakoh@sraco1.uu.net


Thanks for the replies.

--
Martin Chapman PhD, BSc, SMBCS, B/Tec, GCE, CSE, 11+
British Telecom Research Labs, Martlesham Heath, Suffolk, U.K.

"Life's a Bitch, then you die."
-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 90 16:27:44 GMT
From:      well!rbp@apple.com  (Bob Pasker)
To:        tcp-ip@nic.ddn.mil
Subject:   can a router do this?
I have a customer with a multi storey building who has different
segments of ethernet for different business purposes.  There is no way
that these segments will be joined for business (read: political)
reasons.  My application needs to disseminate information to machines
on all of these different segments in realtime, but keep them isolated
from each other.  These segments and all their twisted pair are run
over a broadband network which runs up and down the floors. Putting
separate ethernet adapters in my box is not an acceptable solution.

Any ideas?

thanks,
-- 
- bob
;-----------------------------------------------------------------
; Bob Pasker, San Francisco, CA	 	| rbp@well.sf.ca.us
; +1 415-695-8741			| {apple|pacbell}!well!rbp
-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 90 16:46:27 GMT
From:      intercon!news@uunet.uu.net  (Amanda Walker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TN3270 for PCs/MACs, Summary Posting
In article <531@sulaco.Sigma.COM>, allen@sulaco.Sigma.COM (Allen Gwinn) writes:
> Or you can get NCSA Telnet and/or PCIP for free from your friendly
> neighborhood uunet :-)

Actually, that's the Clarkson version you're thinking of, not vanilla NCSA
Telnet.  Nice looking stuff, from what I've seen.

--
Amanda Walker
InterCon Systems Corporation

"Many of the truths we cling to depend greatly upon our own point of view."
	--Obi-Wan Kenobi in "Return of the Jedi"
-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 90 19:01:56 GMT
From:      buit13!kwe@CS.BU.EDU  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Getting a commercial firm into Internet
In article <9002062137.AA14927@cwh.cam.nist.gov>
 craig@CWH.CAM.NIST.GOV (Craig Hunt) writes:
>One of our network users, who is doing extensive work with a commercial
>firm, asked how that firm could have access to the Internet. Does
>anyone know who is offering a service to connect commercial users into
>Internet services.  I suggested UUNET and CSNET.  I also thought
>perhaps Merit. Suggestions, contacts, addresses would all be
>appreciated.


	While we are all getting our plugs in; I should point out that
under many circumstances it is entirely appropriate for a commercial
concern to connect to a so-called "mid-level" network.

	The choice of connecting a commercial or educational
institution to the Internet via a commercial service provider or via a
not-for-profit so-called "regional" or "mid-level" service provider
depends on what services are being sought.  In all cases, there are
appropriate use guidelines to consider when sending traffic across a
subsidized portion of the Internet, particularly the NSFnet backbone.
Permission to use the NSFnet backbone comes from the NSF DNCRI headed
by Steve Wolff.  These considerations apply to traffic from commercial
service providers as well as subsidized and unsubsidized "mid-level"
networks.  

	The reasons I can think of to use a commercial service
provider versus your friendly neighborhood mid-level is:

	a) you have some traffic that does not fit your mid-level
network's appropriate use guidelines and a commercial concern offers
you a way to move that traffic to where it needs to go.  Some
not-for-profit mid-level networks allow any kind of traffic within
their networks.  NYSERnet is the first, to my knowledge, to announce
unrestricted use of NYSERnet by members.  I predict there will be
others.  However, there are no non-subsidized paths among the
mid-level networks today.

	b) you think that the commercial service provider offers
better service according to some metric than your mid-level network
for access to the Internet.  If what you really want is access to the
Internet and not some private or commercial internet, then a
commercial service provider is equivalent to a mid-level service
provider (for moving datagrams) since you are bound by the appropriate
use guidelines in either case.  Just because you get your connection
from a profit making outfit does not entitle you to pass any traffic
you wish across the NSFnet backbone, BITnet, or any mid-level network
you please.  So, you choose service according to the criterion of who
does the best job connecting you to the Internet and who offers you
the mix of services you want and are willing to pay for.

	I hope this makes the relationship of the mid-level networks
to the commercial service providers a little clearer.  I should note
that Uunet is not-for-profit, so perhaps we should refer to subsidized
and unsubsidized service providers, rather than the commercial versus
non-commercial labels.  Or perhaps we should talk about national
versus "quasi-regional"?  Nah.  Competitive versus uncompetitive?
Maybe.  :-)

	Now for my equal time plug; anyone who is interested in a
connection in the Northeast neighborhood should contact John Rugo, the
business manager for NEARnet, the New England Academic and Research
Network.  NEARnet is a not-for-profit network service provider.

	jrugo@nic.near.net
	(617) 873-2935

	John can tell you exactly what you get and how much it costs
and he can give it to you in writing.  I understand there may be other
not-for-profit or even commercial service providers thinking about the
New England area.  Lots of choice for you.  Perhaps that is the
meaning of "commercialization" of the Internet.  Choice for the users
who pay the bills.  Sounds good to me.

	Kent England, one of the Boston University NEARnet reps
-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 90 19:17:11 GMT
From:      portal!portal!cup.portal.com!thinman@apple.com  (Lance C Norskog)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: DOS & UNIX ethernet board wish list (was Re: TCP/IP over St
> Dr. Scump at Informix writes:
> This brings to mind a question.  Does anybody know of an ethernet
> board which will operate for *all* the following uses:
>     a) under UNIX Sys V/386 Rel 3.2.2 on a 6386:
>        *  uucp   
>        *  tcp/ip 
>        *  NFS or RFS
>        *  etc.
> 
>     b) under MS-DOS 3.30 or 4.01, also on a 6386:
>        *  PC-NFS   (or, FTP Software's PC/TCP will do in a pinch)
>        *  Novell NetWare  (I can live without this, but it'd be nice)

Unix V.3 uses a device interface spec called (variously) LLI or DLI.
This specifies a type of UNIX Streams driver which controls an Ethernet
card.  All four Streams TCP/IP brands (Streamlined, Wollongong, Lachman,
Interactive) use this standard, with proprietary extensions for error 
reporting.  Western Digital, Intel and Tiara Systems have written Streams 
LLI/DLI drivers for their boards and give them out under non-disclosure.
I don't know if the Intel board (PC586) is supported under DOS, but the
the other two (WD 8013 and Tiara LanE-16) are for all three DOS packages 
mentioned.  All three boards have 16-bit bus interfaces and 16-64k of 
buffer RAM; all have worked well here at Streamlined.  (WD, Irvine, CA;
Tiara, Mt. View, CA; Intel, Hillsborough, 503-696-8080).

The above TCP vendors also generally have a miscellany of drivers for old
8-bit Ethernet cards like the 3com's, UB, Micom dumb cards, etc.  We don't
recommend any of these cards; we get a 150-200% performance improvement with
16-bit Ethernet cards.  (In particular, 3com 501's should be buried with
a soldering iron through the heart.)

Other news: for $3500 you can get FDDI cards with UNIX Streams and DOS Novell 
drivers (Speed International, La Habra, CA).  Also, Thomas-Conrad (Austin) has 
announced a proprietary 100-mbit fiber protocol whose boards cost ~$1000 and 
are totally compatible with existing Arcnet drivers.  If you wondered what poin
t
there was to an RFC for running IP over Arcnet (I certainly did), now you know.

Lance Norskog
Sales Engineer
Streamlined Networks
415-659-1450 
-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 90 19:53:51 GMT
From:      zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!grebyn!schultz@tut.cis.ohio-state.edu  (Ronald Schultz)
To:        tcp-ip@nic.ddn.mil
Subject:   LAN lifecycle costs

We are considering the lifecycle maintenance costs associated with a
large broadband network for one of our clients.  My management has
requested some information that I need some help on.

1) What is the average life expectancy of an active component, eg a
power supply or network interface unit, if the MTBF is around 10,000
hours.

2) If the LAN is fully operational today, how much of it would have to
be replaced over a 10 year period ?  Over a five year period ?

3) Are there references or studies available to assist in determining the
life cycle cost of various LAN alternatives, ie fiber vs. broadband vs.
baseband.

I know this is very little to go on, but I desperately need some help.

Thanx,

Ron Schultz
schultz@grebyn.com
614 841-4103
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 90 23:20:31 GMT
From:      cs.utexas.edu!jarvis.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!utzoo!henry@tut.cis.ohio-state.edu  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP on async lines
In article <7414@b11.ingr.com> guy@guy.uucp (Guy Streeter) writes:
>I seem to recall hearing that SLIP will only run on synchronous serial
>lines.  Is this true?  ... is there something about SLIP which precludes it's
>being implemented over async lines?

Other way around:  SLIP is designed for async lines and is not a good
fit on sync lines.  PPP works on either, and is what you should be
implementing if you're implementing something.
-- 
"The N in NFS stands for Not, |     Henry Spencer at U of Toronto Zoology
or Need, or perhaps Nightmare"| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 90 01:14:28 GMT
From:      gds%oahu.cs.ucla.edu@cs.ucla.edu  (Greg Skinner)
To:        tcp-ip@nic.ddn.mil
Subject:   queueing theory poll results
The results of my poll are available for anonymous ftp on
shemp.cs.ucla.edu in the file pub/queueing.  If you cannot get access
to this site, send mail to me and I will send you a copy.

Thanks for all your help,
--gregbo
-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 90 02:15:24 GMT
From:      voder!pyramid!infmx!aland@ucbvax.Berkeley.EDU  (Dr. Scump)
To:        tcp-ip@nic.ddn.mil
Subject:   386 UNIX tcp/ip connections to existing ethernets: examples desired
I'd like to hear from any sites who have networked 386 UNIX boxes
(running System V/386 Release 3.2+, whether AT&T, 386/ix, SCO UNIX,
or whatever) with pre-existing UNIX ethernet setups, especially
if the Wollongong WIN/tcp for Streams product was used.

My objective:  adding some AT&T 386 UNIX boxes to our existing 
network (uses "thinnet" ethernet cable, if that makes a difference),
which consists primarily of Sun and Pyramid boxes.  I know that
the Micom/Interlan product that AT&T sells works, but I'd like
to set it up using more standard network cards (like 3Com 3C503
or WD 8003E) such that the same card can be used for UNIX-UNIX
or DOS-UNIX (e.g. Sun's PC-NFS) use.

On a related note, I'd also like to hear from anybody using the 
AT&T EN100 card with the WIN/tcp software (PE Code 2614111 ??)
combination that AT&T is currently recommending.  Wollongong's
direct sales people are telling me that the EN100 is not supported,
so I'm really confused...

Please provide any pertinent details (hardware used, TCP/IP package,
versions, etc.) via email, and I will summarize if there is interest.

Thanks in advance.

--
Alan S. Denney  @  Informix Software, Inc.       "We're homeward bound
aland@informix.com  {pyramid|uunet}!infmx!aland   ('tis a damn fine sound!)
-----------------------------------------------   with a good ship, taut & free
 Disclaimer:  These opinions are mine alone.      We don't give a damn, 
 If I am caught or killed, the secretary          when we drink our rum
 will disavow any knowledge of my actions.        with the girls of old Maui."
-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 90  08:20 EST
From:      mmorse@NSF.GOV
To:        tcp-ip@NSF.GOV
Subject:   cc:Mail to Internet gateway -- Correction
   My previous message contained an error that has caused some folks
at Oregon State University some unnecessary hardship.  The UUCP-style
gateway is *not* available from Oregon State.  The cc:Mail company
hired the developer, Richard Kinoshita, and licensed the software,
which it now sells as a supported product.  Since Richard was gone,
Oregon State dropped support for the product.  So, please don't call
Oregon State, call cc:Mail.  I apologize for the hassles my message
caused both for information seekers, and for Oregon State folks.

--Mike
-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 90 03:56:19 GMT
From:      lanta!nn@sun.com  (Neal Nuckolls)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Ethernet Throughput (AMD vs. Intel vs. Seeq)
In article <29138@amdcad.AMD.COM>, phil@pepsi.amd.com (Phil Ngai) writes:
> In article <29914@sparkyfs.istc.sri.com> rusti@milk0.itstd.sri.com.UUCP (Rusti Baker) writes:
> |"[the LANCE] locks up the memory bus during the transfer
> |thus stalling the processor"
> 
> My guess as to what was meant by this is that they are talking about the
> LANCE requiring 600 ns to perform a memory cycle. That is, a zero wait
> state memory cycle is 600 ns. (I don't know if you can do wait states.
> This is based on my experience 6 years ago.) Although this might not
> have been considered unusual when the LANCE came out in the early 80's,
> 10 MHz processors were only a dream at the time) it may seem slow in
> an age of 25 MHz processors.
> 

Actually, an 8-word LANCE burst requires a full 4.8 us from start
to finish (600 ns/word).  The keyword with ethernet chips is
latency -- not bandwidth.  The bandwidth is easy.  Satisfying
the latency needs for, say, a LANCE, in applications more complex
than your typical PC is difficult.

------
Re: TCP Ethernet Throughput

Memory-to-memory TCP throughput between two SPARCstations 1's in
single user mode over an empty ethernet running SunOS 4.1 using a
32k send/receive window is approximately  1030 Kbytes/s .

Interestingly, the bottleneck in squeezing out the final few
Kbytes/s is the medium itself -- the receiver cannot return window
update (acknowledgment) packets and defers while the transmitter
is sending full 1500 byte ethernet frames back-to-back so the
transmitter runs out of "window" after 32k, then it gets all the
acknowledgments in one flood, short pause, then it transmits the
next 32k.  This type of behavior is a manifestation of CSMA/CD.


neal nuckolls
sun microsystems
nn@sun.com
-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Feb 90 19:03:02 -0800
From:      wrs!yuba!hwajin@uunet.UU.NET (Hwa Jin Bae)
To:        dcrocker@nsl.dec.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP bind question
>Let me caution you.  Each Streams implementation of TCP/IP appears to be
>quite different, in its interface both to sockets() and TLI.  Especially
>TLI.  The semantics for sockets() are well-defined, by virtue of having
>the BSD code as the reference implementation.  However, the mapping
>of TLI syntax and semantics into TCP functionality is subject to
>considerable interpretation.  Such flexibility is, always, exercised when
>there are multiple implementors.  It is the great fun of open systems.

This is quite true.  Having been involved with an implementation of such
a beast myself, I tend to agree that there does seem to be many different
ways of implementing the same thing, although the original question was
specifically related to an implementation that claims to be compliant to
the AT&T TPI* Specification.  If an implementation is to follow the AT&T
Specification for TPI (yes, there is such a document available to the
developers) the interface between TLI and TPI is very well defined and
*should* not pose incompatibility problems.  The TPI Spec defines a state
machine and all the messages available, which means that there is almost
one-to-one correspondence between a TLI function and a TPI message (not 
quite 100%, but pretty close, for the most part).  Another point is
that while the semantics/syntax for sockets are well-defined, not all 
of the socket implementations work the same way -- I know, because the
implementation that I worked on was NOT based on Berkeley code; it
talked directly with the TPI STREAMS multiplexor via TPI messages just 
like the native TLI implementation -- and not all of the commericial
socket libs are 4.3 BSD compatible.  TLI seems to suffer from about the 
same level of incompatibility problems as sockets.  In reality, IMHO,
these differences are easy to work around and no big deal.

TLI syntax/semantics are just as concretely defined as sockets.  The
problems in "the real world" seems to be specific to the implmentation
problems, not the definition problems.  The point about "mapping TLI
syntax/semantics into TCP functionality" is also quite implementation
specific.  For example, in the aforementioned implementation, there was
no direct mapping between TLI and TCP.  The mappings were always between
TLI and TPI.  TPI can multiplex various transport protocols: TCP, UDP,
TP4, etc.  The actual mapping problems could occur between TPI and these
various protocols although when you're actually implementing any of these
such problems are rather trivial compared to other problems associated 
with STREAMS environment and Unix in general.  

hwajin
--
hwajin@wrs.com (uunet!wrs!hwajin)   "Omnibus ex nihil ducendis sufficit unum."
Hwa Jin Bae, Wind River Systems, 1351 Ocean Avenue, Emeryville, CA 94606, USA

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Feb 90 16:09:04 PST
From:      Dave Crocker <dcrocker@nsl.dec.com>
To:        amdahl!rtech!wrs!hwajin@apple.com (Hwa Jin Bae)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP bind question
"the UDP/IP.  The system calls (whether you use bind() or t_bind()) get turned
into STREAMS messages as they pass through the STREAM heads with types that TPI
multiplexor module understands (in case of bind request it would be"

Let me caution you.  Each Streams implementation of TCP/IP appears to be
quite different, in its interface both to sockets() and TLI.  Especially
TLI.  The semantics for sockets() are well-defined, by virtue of having
the BSD code as the reference implementation.  However, the mapping
of TLI syntax and semantics into TCP functionality is subject to
considerable interpretation.  Such flexibility is, always, exercised when
there are multiple implementors.  It is the great fun of open systems.

Dave
-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 90 12:03:54 GMT
From:      eru!luth!sunic!dkuug!freja!skinfaxe!seindal@bloom-beacon.mit.edu  (Rene' Seindal)
To:        tcp-ip@nic.ddn.mil
Subject:   free ftpd with statistics gathering.

I have pieced together a version of Berkeleys ftpd, with all
non-redistributable code rewritten.  It is based on a version found on
uunet.uu.net.

I have added a message of the day for anonymous ftp, and some statistics
gathering of anonymous file transfers.  These things were mostly made for
local convenience, but if they can be of use for others, great.

You'll find it in /pub/misc/ftpd.tar.Z, on ftp.diku.dk (129.142.96.1).

Rene' Seindal (seindal@diku.dk)


Here's the README file I made back then.

--- README.DIKU -------------------------------------------------------------
This is a modified version of the version of ftpd found on uunet.uu.net as of
20 Jan 1990.

The modifications are as follows.

The STAT command without arguments have been disabled, because the code caused
some unresolved externals.  As it is not normally used, it shouldn't be a
problem.  If the code does compile at your site, remove the definition of
NO_STATCMD from the Makefile.

A motd for anonymous ftp has been added.  To disable this, remove the
definition of MOTD from the Makefile.  If enabled, the motd lives in /etc/motd
after the server has chroot'ed.  If you place anonymous ftp in /, you will
have to change the name.

Logging of uses of anonymous ftp is added.  This is handy, to see which files
are used and which aren't.  To disable this, remove the definition of STATS
from the Makefile.  If enabled, the logfile lives in /usr/adm/ftp-log.

Finally, the globbing routines have been completely rewritten, which should
make the whole thing freely redistributable.

If yo have trouble with any of the things I have changed, please write to me.
My address is seindal@diku.dk.

Rene' Seindal -- Wed Jan 24 16:33:29 1990
------------------------------------------------------------------------

Here's an excerpt of our log file, as an example.

freja 10 $ tail -5 /usr/adm/ftp-log
Feb 14 07:00:49 1990!guest!UNSVAX.NEVADA.EDU!/pub/nn/nn-6.3.7.tar.Z!348361!102
Feb 14 07:13:41 1990!aa!thales.math.umass.edu!/pub/README!2278!1
Feb 14 07:18:23 1990!aa!thales.math.umass.edu!/pub/misc/hosts.dk!5692!4
Feb 14 07:18:32 1990!guest!UNSVAX.NEVADA.EDU!/pub/nn/nn-6.3.7.tar.Z!348361!380
Feb 14 07:20:45 1990!tot!otax.tky.hut.fi!/pub/GNU/gcc-diff/1.36-1.37.Z!165604!61

The fields are the date, the password, the host (or ipaddr), the file fetched,
its size, and the number of seconds the transfer took.  It is just about what
I could squeeze out of the program.

We mostly use the log file to see which files are unused, or less used,
because we are *always* low on space for all the things we'd like to have
available.  We can then remove the least used files first.
-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 90 13:27:49 GMT
From:      att!cbnewsc!billq@ucbvax.Berkeley.EDU  (william.r.quayle)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for Van Jacobson TCP/IP mods

Does anyone have any information on where I might anon ftp the
Van Jacobs[o|e]n mods for TCP/IP?

Sorry if this has been hit on before, I just don't recall seeing it
anywhere.

Thanks,
=========================================================
William R. Quayle       | ...!att!ihlpa!billq
M/S 1D-201              |
AT&T Bell Laboratories  |
2000 N Naperville Rd.   |
Naperville, Il. 60566   |    708-979-3137
-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 90 14:31:51 GMT
From:      zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!news@tut.cis.ohio-state.edu  (Russ Nelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: DOS & UNIX ethernet board wish list (was Re: TCP/IP over St
In article <26890@cup.portal.com> thinman@cup.portal.com (Lance C Norskog) writes:

   If you wondered what point there was to an RFC for running IP over
   Arcnet (I certainly did), now you know.

Um, Lance, some of our students plan to use twisted pair ARCNET to bring
TCP/IP into their dorm rooms.  Yes, at 2Mbit.

--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
Violence never solves problems, it just changes them into more subtle problems
-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 90 15:44:15 GMT
From:      mcsun!hp4nl!philapd!ssp18!michiel@uunet.uu.net  (Michiel Fierst van Wijnandsbergen)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP under MS-Windows
Is there any one who has a TCP communication program working under MS-Windows?

We tried to use TCP of FTP Software and WIN/TCP of Wollongong,
but with both versions we are having problems with the first
'socket' call.  TCP of FTP is crashing and WIN/TCP of Wollongong
gives the error(19) "no such device".

We use in combination with TCP of FTP a NI5210 ethernet card and
in combination with WIN/TCP a 3com Ethernet link II.

We only have these problems under MS-Windows.  The MS-Dos equivalent of our
programs is running with both TCP versions.

If you have a TCP version running under MS-Window, please tell us some details
about your TCP version, configuration of your PC (hardware and
software) and maybe some c program how to open a connection.

-- 
#  Michiel Fierst van Wijnandsbergen   Internet fierst@idca.tds.philips.nl #
#  Philips Telecomm. and Data Systems  UUCP       ...!mcvax!philapd!fierst #
-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 90 16:30:48 GMT
From:      emv@MATH.LSA.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for PC Telnet with printer port support


A solution (not necessarily the one you want) --

run an int14 redirector like TNGLASS from FTP Software, and
use MS-Kermit v3.0 on top of it.  It supports the VT102
escape sequences that shove stuff to the locally attached
printer.

Costs $$$, I haven't seen a free int14 redirector yet.

Might also ask in PCIP, aka comp.protocols.tcp-ip.ibmpc.

--Ed

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 90 18:25:29 GMT
From:      mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu  (Bob Sutterfield)
To:        tcp-ip@nic.ddn.mil
Subject:   MacSLIP?
Is there a SLIP for Macintoshen?  Where might I find it (free is, as
always, better - NCSA perhaps?)
-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 90 21:12:53 GMT
From:      elroy.jpl.nasa.gov!hacgate!ladcgw!hermes!fmayhar@decwrl.dec.com  (Frank Mayhar)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Need routed (Routing daemon) for System V or HPUX.
In article <4817@helios.ee.lbl.gov>, milburn@me10.lbl.gov (John Milburn)
writes:
> In article <1990Feb8.184343.16431@ladc.bull.com>
fmayhar@hermes.ladc.bull.com (Frank Mayhar) writes:
> >I have an HP 9000/300 that needs to be used as a gateway.  Unfortunately,
> >HPUX 6.5 doesn't come with a 'routed' daemon, which makes things kind of
> >painful.  So I need one.  ...
> 
> Why not upgrade to hpux 7.0. It comes standard with gated, which can
> handle rip, hello, and egp. 7.0 also has full nameserver support.
> 
> -jem

Well, that's what a lot of people have said.  Unfortunately, I can't,
because there
are some applications that we need, that don't yet run under 7.0.  When
they do,
we'll upgrade.  In the meantime, I appear to have successfully hacked
the BSD routed
into a form that runs under HPUX.  If anyone is interested in it, let me know.
--
Frank Mayhar  fmayhar@hermes.ladc.bull.com (..!{uunet,hacgate}!ladcgw!fmayhar)
              Bull HN Information Systems Inc.  Los Angeles Development Center
              5250 W. Century Blvd., LA, CA  90045    Phone:  (213) 216-6241
-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 90 21:21:22 GMT
From:      usenet.ins.cwru.edu!mailrus!uflorida!beach.cis.ufl.edu!mw@tut.cis.ohio-state.edu  (Michael Wohlgemuth)
To:        tcp-ip@nic.ddn.mil
Subject:   TN3270
I am having some trouble with TN3270 and was told that I might not have the
latest version.  What is the latest version and where can I get it?

Thanks
Mike
-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 90 21:26:39 GMT
From:      cs.utexas.edu!mailrus!umich!ox.com!itivax!scs@tut.cis.ohio-state.edu  (Steve Simmons)
To:        tcp-ip@nic.ddn.mil
Subject:   Use Domain In Hostname Or Not?

Over the years I've noticed that most folks set the hostname to the
fully qualified domain name.  We've always made them simple hostnames,
then relied on proper sendmail.cfs, etc, to add our domain as
appropriate.  Recently we've bumped into some vendor software bugs for
which the workaround is to make hostname == FQDN.  The vendor agrees
their performance isn't correct, but we're not likely to see a real fix
in the next couple of days.  We're loathe to do things different on
'just one machine', and would prefer consistancy.  I'm interested in
any and all comments on why or why not to set hostname to FQDN.
-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 90 22:12:23 GMT
From:      hp-ses!hpcuhb!hpindda!subbu@hplabs.hp.com  (MCV Subramaniam)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Retries
>
>I'm testing my port of a version of 4.3BSD TCP/IP code.  In
>doing so, I discard in the loopback driver every Nth packet
>(say, N=10).  This results in the MBUF pool being quickly
>depleted.  I discovered that the TCP input routine will
>save all out of order TCP packets waiting for the TCP retry
>to fill in the gaps.  Hence most of the MBUF pool is
>enqueued on this TCP fragment/reassembly list for this
>TCPCB.  Also, the sender continues to get ACKs advertising
>the largest window since the receive socket buffer is
>empty.
>
>Nothing particularly evil happens and since this is
>a very degenerate case, perhaps I should just shrug
>my shoulders and go on with life.  But it does bother
>me a bit - rightfully so?  (Couldn't the window advertised
>by the receiver close, or a limit made on the number
>of out-of-order TCP packets on a TCPCB?)
>
	Remember, the ACK number in all those ACK packets is the
	last sequence number recevied *in order*. So, decreasing
	the available window will mean shrinking the window, which
	is not acceptable as good behavior.

	It is the sender's responsibility to realize (on seeing old ACKs,
	and timing out for not receiving new ACKs) that old segments
	have to be retransmitted. 

	Btw, are you using 4.3 BSD for the sender too?

>Thanks for any help.

	Hope this helps.

>  Dave (wiltzius@lll-lcc.llnl.gov)
PS: You could also tune your implementation to set a limit on the number
or segments (or mbufs, or memory, whatever) on the reassembly queue.
This way, you won't run out of mbufs for other protocols/applications.

-Subbu
email: subbu@hpindaw.hp.com
-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Feb 90 07:27:36 PST
From:      Dave Crocker <dcrocker@nsl.dec.com>
To:        sun!wrs!yuba!hwajin@decpa.pa.dec.com (Hwa Jin Bae)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP bind question
Well, there certainly is a difference between TPI and TLI, and I did
miss your reference in the original note, but I'm afraid that I don't
think it helps the issue much.

TPI is the in-kernel interface.  TLI is the application level mapping
to TPI, as you describe.

Unfortunately, the mapping between TPI and TCP (or UDP) is NOT
subject to inherent or even universal definition.  Basically, the
TLI and TPI interfaces assumed a TP4 environment.  (Yes, I know that
they claim to be protocol independent.  So did sockets.)  But there
still are places where a TCP implementor has choices of how to
make some of the functionality available.  The acid test is to
see the continued need for IOCTL within common applications.

Dave
28
-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Feb 90 12:37:51 -0500
From:      Stephen Wolff <steve@cise.nsf.gov>
To:        buit13!kwe@CS.BU.EDU, tcp-ip@NIC.DDN.MIL
Subject:   Re: Getting a commercial firm into Internet
> Perhaps that is the meaning of "commercialization" of the Internet.
> Choice for the users who pay the bills.  Sounds good to me.

Yeah; that's what I mean.  Sounds good to me, too.  -s

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Thu 15 Feb 90 16:54:33-PST
From:      William "Chops" Westfield <BILLW@MATHOM.CISCO.COM>
To:        dino!cs.iastate.edu!hascall@UUNET.UU.NET
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Proper handling of PUSH & small window by sender?
PUSH is currently considered rather a bad idea.  It is more of a
user->tcp level thing, as opposed to something that belongs in the
protocol layer.

You should be doing Silly Window Syndrome avoidance regardless of
whether the user sets the PUSH bits, etc.

In theory, once you hand both chunks to the TCP, the boundry between
them dissappears, so if they both fit within a single packet, both
case 2 and case 3, you should probably send a single packet with the
push bit set (offhand, though, it sounds like your application is
not using PUSH correctly - you should read what the hosts requirement
RFC (RFC1122) says about push.)

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |         chunk1        |        chunk2       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 case 1 |<--window--->|
 case 2 |<----------window----------->|
 case 3 |<--------------------window--------------------->|

BillW
-------
-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Feb 90 17:39:24 -0500
From:      gvaudre@NRI.Reston.VA.US
To:        "han.q.nguyen" <att!cbnewsi!han@ucbvax.berkeley.edu>
Cc:        tcp-ip@nic.ddn.mil, gvaudre@NRI.Reston.VA.US
Subject:   Re: Thanks (Was: Copy of RFC1134 Needed)
I hope this helps.....

Greg Vaudreuil
National Research Initiatives
-----------------------------------------




Network Working Group                                         D. Perkins
Request for Comments: 1134                                           CMU
                                                           November 1989


       The Point-to-Point Protocol: A Proposal for Multi-Protocol
          Transmission of Datagrams Over Point-to-Point Links


                           Table of Contents

   Status of this Memo ...................................    2
   Abstract ..............................................    2
   1. Introduction .......................................    2
   1.1 Motivation ........................................    2
   1.2 Overview of PPP ...................................    3
   1.3 Organization of the document ......................    4
   2. Physical Layer Requirements ........................    4
   3. The Data Link Layer ................................    4
   3.1 Frame Format ......................................    5
   4. The PPP Link Control Protocol (LCP) ................    8
   4.1 The LCP Automaton .................................    9
   4.1.1 Overview ........................................    9
   4.1.2 State Diagram ...................................   10
   4.1.3 State Transition Table ..........................   12
   4.1.4 Events ..........................................   12
   4.1.5 Actions .........................................   14
   4.1.6 States ..........................................   16
   4.2 Loop Avoidance ....................................   19
   4.3 Packet Format .....................................   19
   4.3.1 Configure-Request ...............................   21
   4.3.2 Configure-Ack ...................................   21
   4.3.3 Configure-Nak ...................................   22
   4.3.4 Configure-Reject ................................   24
   4.3.5 Terminate-Request and Terminate-Ack .............   25
   4.3.6 Code-Reject .....................................   26
   4.3.7 Protocol-Reject .................................   27
   4.3.8 Echo-Request and Echo-Reply .....................   28
   4.3.9 Discard-Request .................................   29
   4.4 Configuration Options .............................   30
   4.4.1 Format ..........................................   31
   5. A PPP Network Control Protocol (NCP) for IP ........   32
   5.1 Sending IP Datagrams ..............................   33
   APPENDICES ............................................   33
   A. Asynchronous HDLC ..................................   33
   B. Fast Frame Check Sequence (FCS) Implementation .....   35
   B.1 FCS Computation Method ............................   35
   B.2 Fast FCS table generator ..........................   36



Perkins                                                         [Page 1]

RFC 1134                          PPP                      November 1989


   REFERENCES ............................................   37
   AUTHOR'S ADDRESS ......................................   38

Status of this Memo

   This memo defines a proposed protocol for the Internet community.

   This proposal is the product of the Point-to-Point Protocol Working
   Group of the Internet Engineering Task Force (IETF).  Comments on this
   memo should be submitted to the IETF Point-to-Point Protocol Working
   Group chair by January 15, 1990.  Comments will be reviewed at the
   February 1990 IETF meeting, with the goal of advancing PPP to draft
   standard status.  Distribution of this memo is unlimited.

Abstract

   The Point-to-Point Protocol (PPP) provides a method for transmitting
   datagrams over serial point-to-point links.  PPP is composed of three
   parts:

      1. A method for encapsulating datagrams over serial links.

      2. An extensible Link Control Protocol (LCP).

      3. A family of Network Control Protocols (NCP) for establishing
         and configuring different network-layer protocols.

   This document defines the encapsulation scheme, the basic LCP, and an
   NCP for establishing and configuring the Internet Protocol (IP)
   (called the IP Control Protocol, IPCP).

   The options and facilities used by the LCP and the IPCP are defined
   in separate documents.  Control protocols for configuring and
   utilizing other network-layer protocols besides IP (e.g., DECNET,
   OSI) are expected to be developed as needed.

1.  Introduction

1.1.  Motivation

   In the last few years, the Internet has seen explosive growth in the
   number of hosts supporting TCP/IP.  The vast majority of these hosts
   are connected to Local Area Networks (LANs) of various types,
   Ethernet being the most common.  Most of the other hosts are
   connected through Wide Area Networks (WANs) such as X.25 style Public
   Data Networks (PDNs).  Relatively few of these hosts are connected
   with simple point-to-point (i.e., serial) links.  Yet, point-to-point
   links are among the oldest methods of data communications and almost



Perkins                                                         [Page 2]

RFC 1134                          PPP                      November 1989


   every host supports point-to-point connections.  For example,
   asynchronous RS-232-C [1] interfaces are essentially ubiquitous.

   One reason for the small number of point-to-point IP links is the
   lack of a standard encapsulation protocol.  There are plenty of non-
   standard (and at least one defacto standard) encapsulation protocols
   available, but there is not one which has been agreed upon as an
   Internet Standard.  By contrast, standard encapsulation schemes do
   exist for the transmission of datagrams over most popular LANs.

   One purpose of this memo is to remedy this problem.  But even more
   importantly, the Point-to-Point Protocol proposes more than just an
   encapsulation scheme.  Point-to-Point links tend to exacerbate many
   problems with the current family of network protocols.  For instance,
   assignment and management of IP addresses, which is a problem even in
   LAN environments, is especially difficult over switched point-to-
   point circuits (e.g., dialups).

   Some additional issues addressed by PPP include asynchronous
   (start/stop) and bit-oriented synchronous encapsulation, network
   protocol multiplexing, link configuration, link quality testing,
   error detection, and option negotiation for such capabilities as
   network-layer address negotiation and data compression negotiation.

   PPP addresses these issues by providing an extensible Link Control
   Protocol (LCP) and a family of Network Control Protocols (NCP) to
   negotiate optional configuration parameters and facilities.

1.2.  Overview of PPP

   PPP has three main components:

      1. A method for encapsulating datagrams over serial links.  PPP
         uses HDLC as a basis for encapsulating datagrams over point-
         to-point links.

      2. An extensible Link Control Protocol (LCP) to establish,
         configure, and test the data-link connection.

      3. A family of Network Control Protocols (NCP) for establishing
         and configuring different network-layer protocols.  PPP is
         designed to allow the simultaneous use of multiple network-
         layer protocols.

   In order to establish communications over a point-to-point link, the
   originating PPP would first send LCP packets to configure and test
   the data link.  After the link has been establish and optional
   facilities have been negotiated as needed by the LCP, the originating



Perkins                                                         [Page 3]

RFC 1134                          PPP                      November 1989


   PPP would send NCP packets to choose and configure one or more
   network-layer protocols.  Once each of the chosen network-layer
   protocols has been configured, datagrams from each network-layer
   protocol can be sent over the link.

   The link will remain configured for communications until explicit LCP
   or NCP packets close the link down, or until some external event
   occurs (e.g., inactivity timer expires or user intervention).

1.3.  Organization of the document

   This memo is divided into several sections.  Section 2 discusses the
   physical-layer requirements of PPP.  Section 3 describes the Data
   Link Layer including the PPP frame format and data link encapsulation
   scheme.  Section 4 specifies the LCP including the connection
   establishment and option negotiation procedures.  Section 5 specifies
   the IP Control Protocol (IPCP), which is the NCP for the Internet
   Protocol, and describes the encapsulation of IP datagrams within PPP
   packets.  Appendix A summarizes important features of asynchronous
   HDLC, and Appendix B describes an efficient table-lookup algorithm
   for fast Frame Check Sequence (FCS) computation.

2.  Physical Layer Requirements

   The Point-to-Point Protocol is capable of operating across any
   DTE/DCE interface (e.g., EIA RS-232-C, EIA RS-422, EIA RS-423 and
   CCITT V.35).  The only absolute requirement imposed by PPP is the
   provision of a duplex circuit, either dedicated or switched, which
   can operate in either an asynchronous (start/stop) or synchronous
   bit-serial mode, transparent to PPP Data Link Layer frames.  PPP does
   not impose any restrictions regarding transmission rate, other than
   those imposed by the particular DTE/DCE interface in use.

   PPP does not require the use of modem control signals, such as
   Request To Send (RTS), Clear To Send (CTS), Data Carrier Detect
   (DCD), and Data Terminal Ready (DTR).  However, using such signals
   when available can allow greater functionality and performance.

3.  The Data Link Layer

   The Point-to-Point Protocol uses the principles, terminology, and
   frame structure of the International Organization For
   Standardization's (ISO) High-level Data Link Control (HDLC)
   procedures (ISO 3309-1979 [2]), as modified by ISO 3309:1984/PDAD1
   "Addendum 1: Start/stop transmission" [5].  ISO 3309-1979 specifies
   the HDLC frame structure for use in synchronous environments.  ISO
   3309:1984/PDAD1 specifies proposed modifications to ISO 3309-1979 to
   allow its use in asynchronous environments.



Perkins                                                         [Page 4]

RFC 1134                          PPP                      November 1989


   The PPP control procedures use the definitions and Control field
   encodings standardized in ISO 4335-1979 [3] and ISO 4335-
   1979/Addendum 1-1979 [4].  The PPP frame structure is also consistent
   with CCITT Recommendation X.25 LAPB [6], since that too is based on
   HDLC.

      Note: ISO 3309:1984/PDAD1 is a Proposed Draft standard.  At
      present, it seems that ISO 3309:1984/PDAD1 is stable and likely to
      become an International Standard.  Therefore, we feel comfortable
      about using it before it becomes an International Standard.  The
      progress of this proposal should be tracked and encouraged by the
      Internet community.

   The purpose of this memo is not to document what is already
   standardized in ISO 3309.  We assume that the reader is already
   familiar with HDLC, or has access to a copy of [2] or [6].  Instead,
   this paper attempts to give a concise summary and point out specific
   options and features used by PPP.  Since "Addendum 1: Start/stop
   transmission", is not yet standardized and widely available, it is
   summarized in Appendix A.

3.1.  Frame Format

   A summary of the standard PPP frame structure is shown below.  The
   fields are transmitted from left to right.

      +----------+---------+---------+----------+------------
      |   Flag   | Address | Control | Protocol | Information
      | 01111110 | 1111111 | 0000011 | 16 bits  |      *
      +----------+---------+---------+----------+------------
              ---+---------+----------+
                 |   FCS   |   Flag   |
                 | 16 bits | 01111110 |
              ---+---------+----------+

   This figure does not include start/stop bits (for asynchronous links)
   or any bits or octets inserted for transparency.  When asynchronous
   links are used, all octets are transmitted with one start bit, eight
   bits of data, and one stop bit.  There is no provision in either PPP
   or ISO 3309:1984/PDAD1 for seven bit asynchronous links.

   To remain consistent with standard Internet practice, and avoid
   confusion for people used to reading RFCs, all binary numbers in the
   following descriptions are in Most Significant Bit to Least
   Significant Bit order, reading from left to right, unless otherwise
   indicated.  Note that this is contrary to standard ISO and CCITT
   practice which orders bits as transmitted (i.e., network bit order).
   Keep this in mind when comparing this document with the international



Perkins                                                         [Page 5]

RFC 1134                          PPP                      November 1989


   standards documents.

   Flag Sequence

      The Flag Sequence is a single octet and indicates the beginning or
      end of a frame.  The Flag Sequence consists of the binary sequence
      01111110 (hexadecimal 0x7e).

   Address Field

      The Address field is a single octet and contains the binary
      sequence 11111111 (hexadecimal 0xff), the All-Stations address.
      PPP does not assign individual station addresses.  The All-
      Stations address should always be recognized and received.  Frames
      with other Addresses should be silently discarded.

   Control Field

      The Control field is a single octet and contains the binary
      sequence 00000011 (hexadecimal 0x03), the Unnumbered Information
      (UI) command with the P/F bit is set to zero.  Frames with other
      Control field values should be silently discarded.

   Protocol Field

      The Protocol field is two octets and its value identifies the
      protocol encapsulated in the Information field of the frame.  The
      most up-to-date values of the Protocol field are specified in the
      most recent "Assigned Numbers" RFC [11].  Initial values are also
      listed below.

      Protocol field values in the "cxxx" range identify datagrams as
      belonging to the Link Control Protocol (LCP) or associated
      protocols.  Values in the "8xxx" range identify datagrams belonging
      to the family of Network Control Protocols (NCP).  Values in the
      "0xxx" range identify the network protocol of specific datagrams.

      This Protocol field is defined by PPP and is not a field defined
      by HDLC.  However, the Protocol field is consistent with the ISO
      3309 extension mechanism for Address fields.  All Protocols MUST be
      odd; the least significant bit of the least significant octet MUST
      equal "1".  Also, all Protocols MUST be assigned such that the
      least significant bit of the most significant octet equals "0".
      Frames received which don't comply with these rules should be
      considered as having an unrecognized Protocol, and should be
      handled as specified by the LCP.  The Protocol field is
      transmitted and received most significant octet first.




Perkins                                                         [Page 6]

RFC 1134                          PPP                      November 1989


      The Protocol field is initially assigned as follows:

         Value (in hex)          Protocol

         0001 to 001f            reserved (transparency inefficient)
         0021                    Internet Protocol
         0023                  * ISO CLNP
         0025                  * Xerox NS IDP
         0027                  * DECnet Phase IV
         0029                  * Appletalk
         002b                  * Novell IPX
         002d                  * Van Jacobson Compressed TCP/IP 1
         002f                  * Van Jacobson Compressed TCP/IP 2

         8021                    Internet Protocol Control Protocol
         8023                  * ISO CLNP Control Protocol
         8025                  * Xerox NS IDP Control Protocol
         8027                  * DECnet Phase IV Control Protocol
         8029                  * Appletalk Control Protocol
         802b                  * Novell IPX Control Protocol
         802d                  * Reserved
         802f                  * Reserved

         c021                    Link Control Protocol
         c023                  * User/Password Authentication Protocol

            * Reserved for future use; not described in this document.

   Information Field

      The Information field is zero or more octets.  The Information
      field contains the datagram for the protocol specified in the
      Protocol field.  The end of the Information field is found by
      locating the closing Flag Sequence and allowing two octets for the
      Frame Check Sequence field.  The default maximum length of the
      Information field is 1500 octets.  By prior agreement, consenting
      PPP implementations may use other values for the maximum
      Information field length.

      On transmission, the Information field may be padded with an
      arbitrary number of octets up to the maximum length.  It is the
      responsibility of each protocol to disambiguate padding characters
      from real information.

   Frame Check Sequence (FCS) Field

      The Frame Check Sequence field is normally 16 bits (two octets).
      By prior agreement, consenting PPP implementations may use a 32-



Perkins                                                         [Page 7]

RFC 1134                          PPP                      November 1989


      bit (four-octet) FCS for improved error detection.

      The FCS field is calculated over all bits of the Address, Control,
      Protocol and Information fields not including any start and stop
      bits (asynchronous) and any bits (synchronous) or octets
      (asynchronous) inserted for transparency.  This does not include
      the Flag Sequences or FCS field.  The FCS is transmitted with the
      coefficient of the highest term first.

      For more information on the specification of the FCS, see ISO 3309
      or CCITT X.25.

         Note: A fast, table-driven implementation of the 16-bit FCS
         algorithm is shown in Appendix B.  This implementation is based
         on [7] and [8].

   Modifications to the Basic Frame Format

      The Link Control Protocol can negotiate modifications to the
      standard PPP frame structure.  However, modified frames will
      always be clearly distinguishable from standard frames.

4.  The PPP Link Control Protocol (LCP)

   The Link Control Protocol (LCP) provides a method of establishing,
   configuring, maintaining and terminating the point-to-point
   connection.  LCP goes through four distinct phases:

   Phase 1: Link Establishment and Configuration Negotiation

      Before any network-layer datagrams (e.g., IP) may be exchanged,
      LCP must first open the connection through an exchange of
      Configure packets.  This exchange is complete, and the Open state
      entered, once a Configure-Ack packet (described below) has been
      both sent and received.  Any non-LCP packets received before this
      exchange is complete are silently discarded.

      It is important to note that LCP handles configuration only of the
      link; LCP does not handle configuration of individual network-
      layer protocols.  In particular, all Configuration Parameters
      which are independent of particular network-layer protocols are
      configured by LCP.  All Configuration Options are assumed to be at
      default values unless altered by the configuration exchange.

   Phase 2: Link Quality Determination

      LCP allows an optional Link Quality Determination phase following
      transition to the LCP Open state.  In this phase, the link is



Perkins                                                         [Page 8]

RFC 1134                          PPP                      November 1989


      tested to determine if the link quality is sufficient to bring up
      network-layer protocols.  This phase is completely optional.  LCP
      may delay transmission of network-layer protocol information until
      this phase is completed.

      The procedure for Link Quality Determination is unspecified and
      may vary from implementation to implementation, or because of
      user-configured parameters, but only so long as the procedure
      doesn't violate other aspects of LCP.  One suggested method is to
      use LCP Echo-Request and Echo-Reply packets.

      What is important is that this phase may persist for any length of
      time.  Therefore, implementations should avoid fixed timeouts when
      waiting for their peers to advance to phase 3.

   Phase 3: Network-Layer Protocol Configuration Negotiation

      Once LCP has finished the Link Quality Determination phase,
      network-layer protocols may be separately configured by the
      appropriate Network Control Protocols (NCP), and may be brought up
      and taken down at any time.  If LCP closes the link, it informs
      the network-layer protocols so that they may take appropriate
      action.

   Phase 4: Link Termination

      LCP may terminate the link at any time.  This will usually be done
      at the request of a human user, but may happen because of a
      physical event such as the loss of carrier, or the expiration of
      an idle-period timer.

4.1.  The LCP Automation

4.1.1.  Overview

   LCP is specified by a number of packet formats and a finite-state
   automation.  This section presents an overview of the LCP automation,
   followed by a representation of it as both a state diagram and a
   state transition table.

   There are three classes of LCP packets:

      1. Link Establishment packets used to establish and configure a
         link, (e.g., Configure-Request, Configure-Ack, Configure-Nak
         and Configure-Reject)

      2. Link Termination packets used to terminate a link, (e.g.,
         Terminate-Request and Terminate-Ack)



Perkins                                                         [Page 9]

RFC 1134                          PPP                      November 1989


      3. Link Maintenance packets used to manage and debug a link,
         (e.g., Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply
         and Discard-Request)

   The finite-state automation is defined by events, state transitions
   and actions.  Events include receipt of external commands such as
   Open and Close, expiration of the Restart timer, and receipt of
   packets from a LCP peer.  Actions include the starting of the Restart
   timer and transmission of packets.

4.1.2.  State Diagram

   The state diagram which follows describes the sequence of events for
   reaching agreement on Configuration Options (opening the PPP
   connection) and for later closing of the connection.  The state
   machine is initially in the Closed state (1).  Once the Open state
   (6) has been reached, both ends of the link have met the requirement
   of having both sent and received a Configure-Ack packet.

   In the state diagram, events are shown above horizontal lines.
   Actions are shown below horizontal lines.  Two types of LCP packets -
   Configure-Naks and Configure-Rejects - are not differentiated in the
   state diagram.  As will be described later, these packets do indeed
   serve different, though similar, functions.  However, at the level of
   detail of this state diagram, they always cause the same transition.

   Since a more detailed specification of the LCP automation is given in
   a state transition table in the following section, implementation
   should be done by consulting it rather than this state diagram.






















Perkins                                                        [Page 10]

RFC 1134                          PPP                      November 1989


                                    +------------------------------+
                                    |                              |
                                    V                              |
        +---2---+           PO +---1---+        RTA +---7---+      |
        |       |<-------------|       |<-----------|       |      |
        |Listen |              |Closed |            |Closing|      |
    RCR |       | C            |       | PLD        |       |      |
   +----|       |----->+------>|       |<---Any     |       |<--+  |
   |scr +-------+      ^       +-------+    State   +-------+   |  |
   |                   |     AO  |                    ^   | TO  |  |
   |       +-----------+     --- |                    |   +---->+  |
   |       |                 SCR |     C              |     str ^  |
   |    C  |   RCN/TO            |   +----------------+         |  |
   |    -- | +-------->+<--------+   | str                      |  |
   |       | | scr     |             |                          |  |
   |    +---3---+      V   TO  +---4---+            +-------+   |  |
   |    |       |<-----+<------|       |<-----------|       |   |  |
   |    | Req-  |          scr | Ack-  |        scn | Good  |   |  |
   |    | Sent  | RCA          | Rcvd  | RCR        | Req?  |   |  |
   |    |       |------------->|       |----------->|       |   |  |
   |    +-------+              +-------+            +-------+   |  |
   |       | ^                                         |        |  |
   |   RCR | +<--------+                               |        |  |
   |   --- | |         |     TO        RCN         --- |        |  |
   |       | | ---     +---------+   +-----+       sca |        |  |
   |       V | scn           scr |   | scr |           V        |  |
   |    +-------+              +---5---+   |        +---6---+ C |  |
   +--->|       |------------->|       |<--+        |       |---+  |
        | Good  | sca          | Ack-  |            | Open  | str  |
        | Req?  |          RCR | Sent  | RCA        |       |      |
        |       |<-------------|       |----------->|       |      |
        +-------+              +-------+            +-------+      |
              ^                                       |   |        |
              |                                   RCR |   | RTR    |
              +---------------------------------------+   +--------+
                                                  scr       sta

   Events                                  Actions
   RCR - Receive-Configure-Request         scr - Send Configure-Request
   RCA - Receive-Configure-Ack             sca - Send Configure-Ack
   RCN - Receive-Configure-Nak or Reject   scn - Send Configure-Nak or
   RTR - Receive-Terminate-Req                   Reject
   RTA - Receive-Terminate-Ack             str - Send Terminate-Req
   AO  - Active-Open                       sta - Sent Terminate-Ack
   PO  - Passive-Open
   C   - Close
   TO  - Timeout
   PLD - Physical-Layer-Down



Perkins                                                        [Page 11]

RFC 1134                          PPP                      November 1989


4.1.3.  State Transition Table

   The complete state transition table follows.  States are indicated
   horizontally, and events are read vertically.  State transitions and
   actions are represented in the form action/new-state.  Two actions
   caused by the same event are represented as action1&action2.

         | State
         |   1       2        3        4        5        6        7
   Events| Closed  Listen  Req-Sent Ack-Rcvd Ack-Sent  Open    Closing
   ------+-------------------------------------------------------------
     AO  | scr/3   scr/3      3        4        5        6      scr/3
     PO  |   2       2        2*       4        5        6      sta/3*
     C   |   1       1        1*       1      str/7    str/7      7
     TO  |   1       2      scr/3    scr/3    scr/3      6      str/7*
    PLD  |   1       1        1        1        1        1        1
    RCR+ | sta/1 scr&sca/5  sca/5    sca/6    sca/5  scr&sca/5    7
    RCR- | sta/1 scr&scn/3  scn/3    scn/4    scn/3  scr&scn/3    7
    RCA  | sta/1   sta/2      4      scr/3      6      scr/3      7
    RCN  | sta/1   sta/2    scr/3    scr/3    scr/5    scr/3      7
    RTR  | sta/1   sta/2    sta/3    sta/3    sta/3    sta/1    sta/7
    RTA  |   1       2        3        3        3        1        1
    RCJ  |   1       2        1        1        1        1        1
    RUC  | scj/1   scj/1    scj/1    scj/1    scj/1    scj/1  1 scj/1
    RER  | sta/1   sta/2      3        4        5      ser/1      7

   Notes:
       RCR+ - Receive-Configure-Request (Good)
       RCR- - Receive-Configure-Request (Bad)
       RCJ  - Receive-Code-Reject
       RUC  - Receive-Unknown-Code
       RER  - Receive-Echo-Request
       scj  - Send-Code-Reject
       ser  - Send-Echo-Reply
        *   - Special attention necessary, see detailed text

4.1.4.  Events

   Transitions and actions in the LCP state machine are caused by
   events.  Some events are caused by commands executed at the local end
   (e.g., Active-Open, Passive-Open, and Close), others are caused by
   the receipt of packets from the remote end (e.g., Receive- Configure-
   Request, Receive-Configure-Ack, Receive-Configure-Nak, Receive-
   Terminate-Request and Receive-Terminate-Ack), and still others are
   caused by the expiration of the Restart timer started as the result
   of other events (e.g., Timeout).

   Following is a list of LCP events.



Perkins                                                        [Page 12]

RFC 1134                          PPP                      November 1989


   Active-Open (AO)

      The Active-Open event indicates the local execution of an Active-
      Open command by the network administrator (human or program).
      When this event occurs, LCP should immediately attempt to open the
      connection by exchanging configuration packets with the LCP peer.

   Passive-Open (PO)

      The Passive-Open event is similar to the Active-Open event.
      However, instead of immediately exchanging configuration packets,
      LCP should wait for the peer to send the first packet.  This will
      only happen after an Active-Open event in the LCP peer.

   Close (C)

      The Close event indicates the local execution of a Close command.
      When this event occurs, LCP should immediately attempt to close
      the connection.

   Timeout (TO)

      The Timeout event indicates the expiration of the LCP Restart
      timer.  The LCP Restart timer is started as the result of other
      LCP events.

      The Restart timer is used to time out transmissions of Configure-
      Request and Terminate-Request packets.  Expiration of the Restart
      timer causes a Timeout event, which triggers the corresponding
      Configure-Request or Terminate-Request packet to be retransmitted.
      The Restart timer MUST be configurable, but should default to
      three (3) seconds.

   Receive-Configure-Request (RCR)

      The Receive-Configure-Request event occurs when a Configure-
      Request packet is received from the LCP peer.  The Configure-
      Request packet indicates the desire to open a LCP connection and
      may specify Configuration Options.  The Configure-Request packet
      is more fully described in a later section.

   Receive-Configure-Ack (RCA)

      The Receive-Configure-Ack event occurs when a valid Configure-Ack
      packet is received from the LCP peer.  The Configure-Ack packet is
      a positive response to a Configure-Request packet.





Perkins                                                        [Page 13]

RFC 1134                          PPP                      November 1989


   Receive-Configure-Nak (RCN)

      The Receive-Configure-Nak event occurs when a valid Configure-Nak
      or Configure-Reject packet is received from the LCP peer.  The
      Configure-Nak and Configure-Reject packets are negative responses
      to a Configure-Request packet.

   Receive-Terminate-Request (RTR)

      The Receive-Terminate-Request event occurs when a Terminate-
      Request packet is received from the LCP peer.  The Terminate-
      Request packet indicates the desire to close the LCP connection.

   Receive-Terminate-Ack (RTA)

      The Receive-Terminate-Ack event occurs when a Terminate-Ack packet
      is received from the LCP peer.  The Terminate-Ack packet is a
      response to a Terminate-Request packet.

   Receive-Code-Reject (RCJ)

      The Receive-Code-Reject event occurs when a Code-Reject packet is
      received from the LCP peer.  The Code-Reject packet communicates
      an error that immediately closes the connection.

   Receive-Unknown-Code (RUC)

      The Receive-Unknown-Code event occurs when an un-interpretable
      packet is received from the LCP peer.  The Code-Reject packet is a
      response to an unknown packet.

   Receive-Echo-Request (RER)

      The Receive-Echo-Request event occurs when a Echo-Request, Echo-
      Reply, or Discard-Request packet is received from the LCP peer.
      The Echo-Reply packet is a response to a Echo-Request packet.
      There is no reply to a Discard-Request.

   Physical-Layer-Down (PLD)

      The Physical-Layer-Down event occurs when the Physical Layer
      indicates that it is down.

4.1.5.  Actions

   Actions in the LCP state machine are caused by events and typically
   indicate the transmission of packets and/or the starting or stopping
   of the Restart timer.  Following is a list of LCP actions.



Perkins                                                        [Page 14]

RFC 1134                          PPP                      November 1989


   Send-Configure-Request (scr)

      The Send-Configure-Request action transmits a Configure-Request
      packet.  This indicates the desire to open a LCP connection with a
      specified set of Configuration Options.  The Restart timer is
      started after the Configure-Request packet is transmitted, to
      guard against packet loss.

   Send-Configure-Ack (sca)

      The Send-Configure-Ack action transmits a Configure-Ack packet.
      This acknowledges the receipt of a Configure-Request packet with
      an acceptable set of Configuration Options.

   Send-Configure-Nak (scn)

      The Send-Configure-Nak action transmits a Configure-Nak or
      Configure-Reject packet, as appropriate.  This negative response
      reports the receipt of a Configure-Request packet with an
      unacceptable set of Configuration Options.  Configure-Nak packets
      are used to refuse a Configuration Option value, and to suggest a
      new, acceptable value.  Configure-Reject packets are used to
      refuse all negotiation about a Configuration Option, typically
      because it is not recognized or implemented.  The use of
      Configure-Nak vs. Configure-Reject is more fully described in the
      section on LCP Packet Formats.

   Send-Terminate-Req (str)

      The Send-Terminate-Request action transmits a Terminate-Request
      packet.  This indicates the desire to close a LCP connection.  The
      Restart timer is started after the Terminate-Request packet is
      transmitted, to guard against packet loss.

   Send-Terminate-Ack (sta)

      The Send-Terminate-Request action transmits a Terminate-Ack
      packet.  This acknowledges the receipt of a Terminate-Request
      packet or otherwise confirms the belief that a LCP connection is
      Closed.

   Send-Code-Reject (scj)

      The Send-Code-Reject action transmits a Code-Reject packet.  This
      indicates the receipt of an unknown type of packet.  This is an
      unrecoverable error which causes immediate transitions to the
      Closed state on both ends of the link.




Perkins                                                        [Page 15]

RFC 1134                          PPP                      November 1989


   Send-Echo-Reply (ser)

      The Send-Echo-Reply action transmits an Echo-Reply packet.  This
      acknowledges the receipt of an Echo-Request packet.

4.1.6.  States

   Following is a more detailed description of each LCP state.

   Closed (1)

      The initial and final state is the Closed state.  In the Closed
      state the connection is down and there is no attempt to open it;
      all connection requests from peers are rejected.  Physical-Layer-
      Down events always cause an immediate transition to the Closed
      state.

      There are two events which cause a transition out of the Closed
      state, Active-Open and Passive-Open.  Upon an Active-Open event, a
      Configure-Request is transmitted, the Restart timer is started,
      and the Request-Sent state is entered.  Upon a Passive-Open event,
      the Listen state is entered immediately.  Upon receipt of any
      packet, with the exception of a Terminate-Ack, a Terminate-Ack is
      sent.  Terminate-Acks are silently discarded to avoid creating a
      loop.

      The Restart timer is not running in the Closed state.

      The Physical Layer connection may be disconnected at any time when
      in the LCP Closed state.

   Listen (2)

      The Listen state is similar to the Closed state in that the
      connection is down and there is no attempt to open it.  However,
      peer connection requests are no longer rejected.

      Upon receipt of a Configure-Request, a Configure-Request is
      immediately transmitted and the Restart timer is started.  The
      received Configuration Options are examined and the proper
      response is sent.  If a Configure-Ack is sent, the Ack-Sent state
      is entered.  Otherwise, if a Configure-Nak or Configure-Reject is
      sent, the Request-Sent state is entered.  In either case, LCP
      exits its passive state, and begins to actively open the
      connection.  Terminate-Ack packets are sent in response to either
      Configure-Ack or Configure-Nak packets,

      The Restart timer is not running in the Listen state.



Perkins                                                        [Page 16]

RFC 1134                          PPP                      November 1989


   Request-Sent (3)

      In the Request-Sent state an active attempt is made to open the
      connection.  A Configure-Request has been sent and the Restart
      timer is running, but a Configure-Ack has not yet been received
      nor has one been sent.

      Upon receipt of a Configure-Ack, the Ack-Received state is
      immediately entered.  Upon receipt of a Configure-Nak or
      Configure-Reject, the Configure-Request Configuration Options are
      adjusted appropriately, a new Configure-Request is transmitted,
      and the Restart timer is restarted.  Similarly, upon the
      expiration of the Restart timer, a new Configure-Request is
      transmitted and the Restart timer is restarted.  Upon receipt of a
      Configure-Request, the Configuration Options are examined and if
      acceptable, a Configure-Ack is sent and the Ack-Sent state is
      entered.  If the Configuration Options are unacceptable, a
      Configure-Nak or Configure-Reject is sent as appropriate.

      Since there is an outstanding Configure-Request in the Request-
      Sent state, special care must be taken to implement the Passive-
      Open and Close events; otherwise, it is possible for the LCP peer
      to think the connection is open.  Processing of either event
      should be postponed until there is reasonable assurance that the
      peer is not open.  In particular, the Restart timer should be
      allowed to expire.

   Ack-Received (4)

      In the Ack-Received state, a Configure-Request has been sent and a
      Configure-Ack has been received.  The Restart timer is still
      running since a Configure-Ack has not yet been transmitted.

      Upon receipt of a Configure-Request with acceptable Configuration
      Options, a Configure-Ack is transmitted, the Restart timer is
      stopped and the Open state is entered.  If the Configuration
      Options are unacceptable, a Configure-Nak or Configure-Reject is
      sent as appropriate.  Upon the expiration of the Restart timer, a
      new Configure-Request is transmitted, the Restart timer is
      restarted, and the state machine returns to the Request-Sent
      state.

   Ack-Sent (5)

      In the Ack-Sent state, a Configure-Ack and a Configure-Request
      have been sent but a Configure-Ack has not yet been received.  The
      Restart timer is always running in the Ack-Sent state.




Perkins                                                        [Page 17]

RFC 1134                          PPP                      November 1989


      Upon receipt of a Configure-Ack, the Restart timer is stopped and
      the Open state is entered.  Upon receipt of a Configure-Nak or
      Configure-Reject, the Configure-Request Configuration Options are
      adjusted appropriately, a new Configure-Request is transmitted,
      and the Restart timer is restarted.  Upon the expiration of the
      Restart timer, a new Configure-Request is transmitted, the Restart
      timer is restarted, and the state machine returns to the Request-
      Sent state.

   Open (6)

      In the Open state, a connection exists and data may be
      communicated over the link.  The Restart timer is not running in
      the Open state.

      In normal operation, only two events cause transitions out of the
      Open state.  Upon receipt of a Close command, a Terminate-Request
      is transmitted, the Restart timer is started, and the Closing
      state is entered.  Upon receipt of a Terminate-Request, a
      Terminate-Ack is transmitted and the Closed state is entered.
      Upon receipt of an Echo-Request, an Echo-Reply is transmitted.
      Similarly, Echo-Reply and Discard-Request packets are silently
      discarded or processed as expected.  All other events cause
      immediate transitions out of the Open state and should be handled
      as if the state machine were in the Listen state.

   Closing (7)

      In the Closing state, an active attempt is made to close the
      connection.  A Terminate-Request has been sent and the Restart
      timer is running, but a Terminate-Ack has not yet been received.

      Upon receipt of a Terminate-Ack, the Closed state is immediately
      entered.  Upon the expiration of the Restart timer, a new
      Terminate-Request is transmitted and the Restart timer is
      restarted.  After the Restart timer has expired Max-Restart times,
      this action may be skipped, and the Closed state may be entered.
      Max-Restart MUST be a configurable parameter.

      Since there is an outstanding Terminate-Request in the Closing
      state, special care must be taken to implement the Passive-Open
      event; otherwise, it is possible for the LCP peer to think the
      connection is open.  Processing of the Passive-Open event should
      be postponed until there is reasonable assurance that the peer is
      not open.  In particular, the implementation should wait until the
      state machine would normally transition to the Closed state
      because of a Receive-Terminate-Ack event or Max-Restart Timeout
      events.



Perkins                                                        [Page 18]

RFC 1134                          PPP                      November 1989


4.2.  Loop Avoidance

   Note that the protocol makes a reasonable attempt at avoiding
   Configuration Option negotiation loops.  However, the protocol does
   NOT guarantee that loops will not happen.  As with any negotiation,
   it is possible to configure two PPP implementations with conflicting
   policies that will never converge.  It is also possible to configure
   policies which do converge, but which take significant time to do so.
   Implementors should keep this in mind and should implement loop
   detection mechanisms or higher level timeouts.  If a timeout is
   implemented, it MUST be configurable.

   For example, implementations could take care to avoid Configure-
   Request or Terminate-Request livelocks by using a Max-Retries
   counter.  A Configure-Request livelock could occur when an
   originating PPP sends and re-sends a C-R without receiving a reply
   (e.g., the receiving PPP entity may have died).  A Terminate-Request
   livelock could occur when the originating PPP sends and re-sends a
   T-R without receiving a Terminate-Ack (e.g., the T-A may have been
   lost, but the remote PPP may have already terminated).  Max-Retries
   indicates the number of packet retransmissions that are allowed
   before there is reasonable assurance that a livelock situation
   exists.  Max-Retries MUST also be configurable, but should default to
   ten (10) retransmissions.

4.3  Packet Format

   Exactly one Link Control Protocol packet is encapsulated in the
   Information field of PPP Data Link Layer frames where the Protocol
   field indicates type hex c021 (Link Control Protocol).

   A summary of the Link Control Protocol packet format is shown below.
   The fields are transmitted from left to right.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Code      |  Identifier   |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+

   Code

      The Code field is one octet and identifies the kind of LCP packet.
      LCP Codes are assigned as follows:





Perkins                                                        [Page 19]

RFC 1134                          PPP                      November 1989


         1       Configure-Request
         2       Configure-Ack
         3       Configure-Nak
         4       Configure-Reject
         5       Terminate-Request
         6       Terminate-Ack
         7       Code-Reject
         8       Protocol-Reject
         9       Echo-Request
         10      Echo-Reply
         11      Discard-Request

   Identifier

      The Identifier field is one octet and aids in matching requests
      and replies.

   Length

      The Length field is two octets and indicates the length of the LCP
      packet including the Code, Identifier, Length and Data fields.
      Octets outside the range of the Length field should be treated as
      Data Link Layer padding and should be ignored on reception.

   Data

      The Data field is zero or more octets as indicated by the Length
      field.  The format of the Data field is determined by the Code
      field.

   Regardless of which Configuration Options are enabled, all LCP
   packets are always sent in the full, standard form, as if no
   Configuration Options were enabled.  This ensures that LCP
   Configure-Request packets are always recognizable even when one end
   of the link mistakenly believes the link to be Open.

   This document describes Version 1 of the Link Control Protocol.  In
   the interest of simplicity, there is no version field in the LCP
   packet.  If a new version of LCP is necessary in the future, the
   intention is that a new Data Link Layer Protocol field value should
   be used to differentiate Version 1 LCP from all other versions.  A
   correctly functioning Version 1 LCP implementation will always
   respond to unknown Protocols (including other versions) with an
   easily recognizable Version 1 packet, thus providing a deterministic
   fallback mechanism for implementations of other versions.






Perkins                                                        [Page 20]

RFC 1134                          PPP                      November 1989


4.3.1.  Configure-Request

   Description

      A LCP implementation wishing to open a connection MUST transmit a
      LCP packet with the Code field set to 1 (Configure-Request) and
      the Options field filled with any desired changes to the default
      link Configuration Options.

      Upon reception of a Configure-Request, an appropriate reply MUST
      be transmitted.

   A summary of the Configure-Request packet format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Options ...
   +-+-+-+-+

   Code

      1 for Configure-Request.

   Identifier

      The Identifier field should be changed on each transmission.  On
      reception, the Identifier field should be copied into the
      Identifier field of the appropriate reply packet.

   Options

      The options field is variable in length and contains the list of
      zero or more Configuration Options that the sender desires to
      negotiate.  All Configuration Options are always negotiated
      simultaneously.  The format of Configuration Options is further
      described in a later section.

4.3.2.  Configure-Ack

   Description

      If every Configuration Option received in a Configure-Request is
      both recognizable and acceptable, then a LCP implementation should
      transmit a LCP packet with the Code field set to 2 (Configure-



Perkins                                                        [Page 21]

RFC 1134                          PPP                      November 1989


      Ack), the Identifier field copied from the received Configure-
      Request, and the Options field copied from the received
      Configure-Request.  The acknowledged Configuration Options MUST
      NOT be reordered or modified in any way.

      On reception of a Configure-Ack, the Identifier field must match
      that of the last transmitted Configure-Request, or the packet is
      invalid.  Additionally, the Configuration Options in a Configure-
      Ack must match those of the last transmitted Configure-Request, or
      the packet is invalid.  Invalid packets should be silently
      discarded.

      Reception of a valid Configure-Ack indicates that all
      Configuration Options sent in the last Configure-Request are
      acceptable.

   A summary of the Configure-Ack packet format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Options ...
   +-+-+-+-+

   Code

      2 for Configure-Ack.

   Identifier

      The Identifier field is a copy of the Identifier field of the
      Configure-Request which caused this Configure-Ack.

   Options

      The Options field is variable in length and contains the list of
      zero or more Configuration Options that the sender is
      acknowledging.  All Configuration Options are always acknowledged
      simultaneously.

4.3.3.  Configure-Nak

   Description

      If every element of the received Configuration Options is



Perkins                                                        [Page 22]

RFC 1134                          PPP                      November 1989


      recognizable but some are not acceptable, then a LCP
      implementation should transmit a LCP packet with the Code field
      set to 3 (Configure-Nak), the Identifier field copied from the
      received Configure-Request, and the Options field filled with only
      the unacceptable Configuration Options from the Configure-Request.
      All acceptable Configuration Options should be filtered out of the
      Configure-Nak, but otherwise the Configuration Options from the
      Configure-Request MUST NOT be reordered.  Each of the nak'd
      Configuration Options MUST be modified to a value acceptable to
      the Configure-Nak sender.  Finally, an implementation may be
      configured to require the negotiation of a specific option.  If
      that option is not listed, then that option may be appended to the
      list of nak'd Configuration Options in order to request the remote
      end to list that option in its next Configure-Request packet.  The
      appended option must include a value acceptable to the Configure-
      Nak sender.

      On reception of a Configure-Nak, the Identifier field must match
      that of the last transmitted Configure-Request, or the packet is
      invalid and should be silently discarded.

      Reception of a valid Configure-Nak indicates that a new
      Configure-Request should be sent with the Configuration Options
      modified as specified in the Configure-Nak.

   A summary of the Configure-Nak packet format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Options ...
   +-+-+-+-+

   Code

      3 for Configure-Nak.

   Identifier

      The Identifier field is a copy of the Identifier field of the
      Configure-Request which caused this Configure-Nak.

   Options

      The Options field is variable in length and contains the list of



Perkins                                                        [Page 23]

RFC 1134                          PPP                      November 1989


      zero or more Configuration Options that the sender is nak'ing.
      All Configuration Options are always nak'd simultaneously.

4.3.4.  Configure-Reject

   Description

      If some Configuration Options received in a Configure-Request are
      not recognizable or are not acceptable for negotiation (as
      configured by a network manager), then a LCP implementation should
      transmit a LCP packet with the Code field set to 4 (Configure-
      Reject), the Identifier field copied from the received Configure-
      Request, and the Options field filled with only the unrecognized
      Configuration Options from the Configure-Request.  All
      recognizable and negotiable Configuration Options must be filtered
      out of the Configure-Reject, but otherwise the Configuration
      Options MUST not be reordered.

      On reception of a Configure-Reject, the Identifier field must
      match that of the last transmitted Configure-Request, or the
      packet is invalid.  Additionally, the Configuration Options in a
      Configure-Reject must be a proper subset of those in the last
      transmitted Configure-Request, or the packet is invalid.  Invalid
      packets should be silently discarded.

      Reception of a Configure-Reject indicates that a new Configure-
      Request should be sent which does not include any of the
      Configuration Options listed in the Configure-Reject.

   A summary of the Configure-Reject packet format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Options ...
   +-+-+-+-+

   Code

      4 for Configure-Reject.

   Identifier

      The Identifier field is a copy of the Identifier field of the
      Configure-Request which caused this Configure-Reject.



Perkins                                                        [Page 24]

RFC 1134                          PPP                      November 1989


   Options

      The Options field is variable in length and contains the list of
      zero or more Configuration Options that the sender is rejecting.
      All Configuration Options are always rejected simultaneously.

4.3.5.  Terminate-Request and Terminate-Ack

   Description

      LCP includes Terminate-Request and Terminate-Ack Codes in order to
      provide a mechanism for closing a connection.

      A LCP implementation wishing to close a connection should transmit
      a LCP packet with the Code field set to 5 (Terminate-Request) and
      the Data field filled with any desired data.  Terminate-Request
      packets should continue to be sent until Terminate-Ack is
      received, the Physical Layer indicates that it has gone down, or a
      sufficiently large number have been transmitted such that the
      remote end is down with reasonable certainty.

      Upon reception of a Terminate-Request, a LCP packet MUST be
      transmitted with the Code field set to 6 (Terminate-Ack), the
      Identifier field copied from the Terminate-Request packet, and the
      Data field filled with any desired data.

      Reception of an unelicited Terminate-Ack indicates that the
      connection has been closed.

   A summary of the Terminate-Request and Terminate-Ack packet formats
   is shown below.  The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+

   Code

      5 for Terminate-Request;

      6 for Terminate-Ack.






Perkins                                                        [Page 25]

RFC 1134                          PPP                      November 1989


   Identifier

      The Identifier field is one octet and aids in matching requests
      and replies.

   Data

      The Data field is zero or more octets and contains uninterpreted
      data for use by the sender.  The data may consist of any binary
      value and may be of any length from zero to the established value
      for the peer's MRU.

4.3.6.  Code-Reject

   Description

      Reception of a LCP packet with an unknown Code indicates that one
      of the communicating LCP implementations is faulty or incomplete.
      This error MUST be reported back to the sender of the unknown Code
      by transmitting a LCP packet with the Code field set to 7 (Code-
      Reject), and the inducing packet copied to the Rejected-Packet
      field.

      Upon reception of a Code-Reject, a LCP implementation should make
      an immediate transition to the Closed state, and should report the
      error, since it is unlikely that the situation can be rectified
      automatically.

   A summary of the Code-Reject packet format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Rejected-Packet ...
   +-+-+-+-+-+-+-+-+

   Code

      7 for Code-Reject.

   Identifier

      The Identifier field is one octet and is for use by the
      transmitter.




Perkins                                                        [Page 26]

RFC 1134                          PPP                      November 1989


   Rejected-Packet

      The Rejected-Packet field contains a copy of the LCP packet which
      is being rejected.  It begins with the rejected Code field; it
      does not include any PPP Data Link Layer headers.  The Rejected-
      Packet should be truncated to comply with the established value of
      the peer's MRU.

4.3.7.  Protocol-Reject

   Description

      Reception of a PPP frame with an unknown Data Link Layer Protocol
      indicates that the remote end is attempting to use a protocol
      which is unsupported at the local end.  This typically occurs when
      the remote end attempts to configure a new, but unsupported
      protocol.  If the LCP state machine is in the Open state, then
      this error MUST be reported back to the sender of the unknown
      protocol by transmitting a LCP packet with the Code field set to 8
      (Protocol-Reject), the Rejected-Protocol field set to the received
      Protocol, and the Data field filled with any desired data.

      Upon reception of a Protocol-Reject, a LCP implementation should
      stop transmitting frames of the indicated protocol.

      Protocol-Reject packets may only be sent in the LCP Open state.
      Protocol-Reject packets received in any state other than the LCP
      Open state should be discarded and no further action should be
      taken.

   A summary of the Protocol-Reject packet format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Rejected-Protocol       |      Rejected-Information ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code

      8 for Protocol-Reject.

   Identifier

      The Identifier field is one octet and is for use by the



Perkins                                                        [Page 27]

RFC 1134                          PPP                      November 1989


      transmitter.

   Rejected-Protocol

      The Rejected-Protocol field is two octets and contains the
      Protocol of the Data Link Layer frame which is being rejected.

   Rejected-Information

      The Rejected-Information field contains a copy from the frame
      which is being rejected.  It begins with the Information field,
      and does not include any PPP Data Link Layer headers or the FCS.
      The Rejected-Information field should be truncated to comply with
      the established value of the peer's MRU.

4.3.8.  Echo-Request and Echo-Reply

   Description

      LCP includes Echo-Request and Echo-Reply Codes in order to provide
      a Data Link Layer loopback mechanism for use in exercising both
      directions of the link.  This is useful as an aid in debugging,
      link quality determination, performance testing, and for numerous
      other functions.

      An Echo-Request sender transmits a LCP packet with the Code field
      set to 9 (Echo-Request) and the Data field filled with any desired
      data, up to but not exceeding the receivers established MRU.

      Upon reception of an Echo-Request, a LCP packet MUST be
      transmitted with the Code field set to 10 (Echo-Reply), the
      Identifier field copied from the received Echo-Request, and the
      Data field copied from the Echo-Request, truncating as necessary
      to avoid exceeding the peer's established MRU.

      Echo-Request and Echo-Reply packets may only be sent in the LCP
      Open state.  Echo-Request and Echo-Reply packets received in any
      state other than the LCP Open state should be discarded and no
      further action should be taken.

   A summary of the Echo-Request and Echo-Reply packet formats is shown
   below.  The fields are transmitted from left to right.









Perkins                                                        [Page 28]

RFC 1134                          PPP                      November 1989


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Magic-Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+

   Code

      9 for Echo-Request;

      10 for Echo-Reply.

   Identifier

      The Identifier field is one octet and aids in matching Echo-
      Requests and Echo-Replies.

   Magic-Number

      The Magic-Number field is four octets and aids in detecting
      loopbacked links.  Unless modified by a Configuration Option, the
      Magic-Number MUST always be transmitted as zero and MUST always be
      ignored on reception.  Further use of the Magic-Number is beyond
      the scope of this discussion.

   Data

      The Data field is zero or more octets and contains uninterpreted
      data for use by the sender.  The data may consist of any binary
      value and may be of any length from zero to the established value
      for the peer's MRU.

4.3.9.  Discard-Request

   Description

      LCP includes a Discard-Request Code in order to provide a Data
      Link Layer data sink mechanism for use in exercising the local to
      remote direction of the link.  This is useful as an aid in
      debugging, performance testing, and and for numerous other
      functions.

      A discard sender transmits a LCP packet with the Code field set to
      11 (Discard-Request) and the Data field filled with any desired



Perkins                                                        [Page 29]

RFC 1134                          PPP                      November 1989


      data, up to but not exceeding the receivers established MRU.

      A discard receiver MUST simply throw away an Discard-Request that
      it receives.

      Discard-Request packets may only be sent in the LCP Open state.

   A summary of the Discard-Request packet formats is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Magic-Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+

   Code

      11 for Discard-Request.

   Identifier

      The Identifier field is one octet and is for use by the Discard-
      Request transmitter.

   Magic-Number

      The Magic-Number field is four octets and aids in detecting
      loopbacked links.  Unless modified by a configuration option, the
      Magic-Number MUST always be transmitted as zero and MUST always be
      ignored on reception.  Further use of the Magic-Number is beyond
      the scope of this discussion.

   Data

      The Data field is zero or more octets and contains uninterpreted
      data for use by the sender.  The data may consist of any binary
      value and may be of any length from zero to the established value
      for the peer's MRU.

4.4.  Configuration Options

   LCP Configuration Options allow modifications to the standard
   characteristics of a point-to-point link to be negotiated.



Perkins                                                        [Page 30]

RFC 1134                          PPP                      November 1989


   Negotiable modifications include such things as the maximum receive
   unit, async control character mapping, the link authentication
   method, the link encryption method, etc..  The Configuration Options
   themselves are described in separate documents.  If a Configuration
   Option is not included in a Configure-Request packet, the default
   value for that Configuration Option is assumed.

   The end of the list of Configuration Options is indicated by the end
   of the LCP packet.

   Unless otherwise specified, a specific Configuration Options should
   be listed no more than once in a Configuration Options list.
   Specific Configuration Options may override this general rule and may
   be listed more than once.  The effect of this is Configuration Option
   specific and is specified by each such Configuration Option.

   Also unless otherwise specified, all Configuration Options apply in a
   half-duplex fashion.  When negotiated, they apply to only one
   direction of the link, typically in the receive direction when
   interpreted from the point of view of the Configure-Request sender.

4.4.1.  Format

   A summary of the Configuration Option format is shown below.  The
   fields are transmitted from left to right.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |    Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      The Type field is one octet and indicates the type of
      Configuration Option.  The most up-to-date values of the Type
      field are specified in the most recent "Assigned Numbers" RFC
      [11].

   Length

      The Length field is one octet and indicates the length of this
      Configuration Option including the Type, Length and Data fields.
      If a negotiable Configuration Option is received in a Configure-
      Request but with an invalid Length, a Configure-Nak should be
      transmitted which includes the desired Configuration Option with
      an appropriate Length and Data.




Perkins                                                        [Page 31]

RFC 1134                          PPP                      November 1989


   Data

      The Data field is zero or more octets and indicates the value or
      other information for this Configuration Option.  The format and
      length of the Data field is determined by the Type and Length
      fields.

5.  A PPP Network Control Protocol (NCP) for IP

   The IP Control Protocol (IPCP) is responsible for configuring,
   enabling, and disabling the IP protocol modules on both ends of the
   point-to-point link.  As with the Link Control Protocol, this is
   accomplished through an exchange of packets.  IPCP packets may not be
   exchanged until LCP has reached the network-layer Protocol
   Configuration Negotiation phase.  Likewise, IP datagrams may not be
   exchanged until IPCP has first opened the connection.

   The IP Control Protocol is exactly the same as the Link Control
   Protocol with the following exceptions:

   Data Link Layer Protocol Field

      Exactly one IP Control Protocol packet is encapsulated in the
      Information field of PPP Data Link Layer frames where the Protocol
      field indicates type hex 8021 (IP Control Protocol).

   Code field

      Only Codes 1 through 7 (Configure-Request, Configure-Ack,
      Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
      and Code-Reject) are used.  Other Codes should be treated as
      unrecognized and should result in Code-Rejects.

   Timeouts

      IPCP packets may not be exchanged until the Link Control Protocol
      has reached the network-layer Protocol Configuration Negotiation
      phase.  An implementation should be prepared to wait for Link
      Quality testing to finish before timing out waiting for a
      Configure-Ack or other response.  It is suggested that an
      implementation give up only after user intervention or a
      configurable amount of time.

   Configuration Option Types

      The IPCP has a separate set of Configuration Options.  The most
      up-to-date values of the type field are specified in the most
      recent "Assigned Numbers" RFC [11].



Perkins                                                        [Page 32]

RFC 1134                          PPP                      November 1989


5.1.  Sending IP Datagrams

   Before any IP packets may be communicated, both the Link Control
   Protocol and the IP Control Protocol must reach the Open state.

   Exactly one IP packet is encapsulated in the Information field of PPP
   Data Link Layer frames where the Protocol field indicates type hex
   0021 (Internet Protocol).

   The maximum length of an IP packet transmitted over a PPP link is the
   same as the maximum length of the Information field of a PPP data
   link layer frame.  Larger IP datagrams must be fragmented as
   necessary.  If a system wishes to avoid fragmentation and reassembly,
   it should use the TCP Maximum Segment Size option [12], or a similar
   mechanism, to discourage others from sending large datagrams.

A.  Asynchronous HDLC

   This appendix summarizes the modifications to ISO 3309-1979 proposed
   in ISO 3309:1984/PDAD1.  These modifications allow HDLC to be used
   with 8-bit asynchronous links.

   Transmission Considerations

      Each octet is delimited by a start and a stop element.

   Flag Sequence

      The Flag Sequence is a single octet and indicates the beginning or
      end of a frame.  The Flag Sequence consists of the binary sequence
      01111110 (hexadecimal 0x7e).

   Transparency

      On asynchronous links, a character stuffing procedure is used.
      The Control Escape octet is defined as binary 01111101
      (hexadecimal 0x7d) where the bit positions are numbered 87654321
      (not 76543210, BEWARE).

      After FCS computation, the transmitter examines the entire frame
      between the two Flag Sequences.  Each Flag Sequence, Control
      Escape octet and octet with value less than hexadecimal 0x20 is
      replaced by a two character sequence consisting of the Control
      Escape octet and the original octet with bit 6 complemented (i.e.,
      exclusive-or'd with hexadecimal 0x20).

      Prior to FCS computation, the receiver examines the entire frame
      between the two Flag Sequences.  For each Control Escape octet,



Perkins                                                        [Page 33]

RFC 1134                          PPP                      November 1989


      that octet is removed and bit 6 of the following octet is
      complemented.  A Control Escape octet immediately preceding the
      closing Flag Sequence indicates an invalid frame.

         Note: The inclusion of all octets less than hexadecimal 0x20
         allows all ASCII control characters [10] excluding DEL (Delete)
         to be transparently communicated through almost all known data
         communications equipment.

      A few examples may make this more clear.  Packet data is
      transmitted on the link as follows:

         0x7e is encoded as 0x7d, 0x5e.
         0x7d is encoded as 0x7d, 0x5d.
         0x01 is encoded as 0x7d, 0x21.

   Aborting a Transmission

      On asynchronous links, frames may be aborted by transmitting a "0"
      stop bit where a "1" bit is expected (framing error) or by
      transmitting a Control Escape octet followed immediately by a
      closing Flag Sequence.

   Inter-frame Time Fill

      On asynchronous links, inter-octet and inter-frame time fill
      should be accomplished by transmitting continuous "1" bits (mark-
      hold state).

         Note: On asynchronous links, inter-frame time fill can be
         viewed as extended inter-octet time fill.  Doing so can save
         one octet for every frame, decreasing delay and increasing
         bandwidth.  This is possible since a Flag Sequence may serve as
         both a frame close and a frame begin.  After having received
         any frame, an idle receiver will always be in a frame begin
         state.

         Robust transmitters should avoid using this trick over-
         zealously since the price for decreased delay is decreased
         reliability.  Noisy links may cause the receiver to receive
         garbage characters and interpret them as part of an incoming
         frame.  If the transmitter does not transmit a new opening Flag
         Sequence before sending the next frame, then that frame will be
         appended to the noise characters causing an invalid frame (with
         high reliability).  Transmitters should avoid this by
         transmitting an open Flag Sequence whenever "appreciable time"
         has elapsed since the prior closing Flag Sequence.  It is
         suggested that implementations will achieve the best results by



Perkins                                                        [Page 34]

RFC 1134                          PPP                      November 1989


         always sending an opening Flag Sequence if the new frame is not
         back-to-back with the last.  The maximum value for "appreciable
         time" is likely to be no greater than the typing rate of a slow
         to average typist, say 1 second.

B.  Fast Frame Check Sequence (FCS) Implementation

B.1.  FCS Computation Method

   The following code provides a table lookup computation for
   calculating the Frame Check Sequence as data arrives at the
   interface.  The table is created by the code in section 2.

   /*
    * FCS lookup table as calculated by the table generator in section 2.
    */
   static unsigned short fcstab[256] = {
        0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf,
        0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7,
        0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e,
        0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876,
        0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd,
        0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5,
        0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c,
        0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974,
        0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb,
        0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3,
        0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a,
        0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72,
        0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9,
        0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1,
        0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738,
        0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70,
        0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7,
        0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff,
        0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036,
        0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e,
        0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5,
        0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd,
        0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134,
        0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c,
        0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3,
        0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb,
        0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232,
        0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a,
        0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1,
        0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9,
        0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330,



Perkins                                                        [Page 35]

RFC 1134                          PPP                      November 1989


        0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78
   };

   #define PPPINITFCS      0xffff  /* Initial FCS value */
   #define PPPGOODFCS      0xf0b8  /* Good final FCS value */


   /*
    * Calculate a new fcs given the current fcs and the new data.
    */
   unsigned short pppfcs(fcs, cp, len)
       register unsigned short fcs;
       register unsigned char *cp;
       register int len;
   {
       while (len--)
           fcs = (fcs >> 8) ^ fcstab[(fcs ^ *cp++) & 0xff];

       return (fcs);
   }

B.2.  Fast FCS table generator

   The following code creates the lookup table used to calculate the
   FCS.

   /*
    * Generate a FCS table for the HDLC FCS.
    *
    * Drew D. Perkins at Carnegie Mellon University.
    *
    * Code liberally borrowed from Mohsen Banan and D. Hugh Redelmeier.
    */

   /*
    * The HDLC polynomial: x**0 + x**5 + x**12 + x**16 (0x8408).
    */
   #define P       0x8408


   main()
   {
       register unsigned int b, v;
       register int i;

       printf("static unsigned short fcstab[256] = {");
       for (b = 0; ; ) {
           if (b % 8 == 0)



Perkins                                                        [Page 36]

RFC 1134                          PPP                      November 1989


               printf("0);

           v = b;
           for (i = 8; i--; )
               v = v & 1 ? (v >> 1) ^ P : v >> 1;

           printf("0x%04x", v & 0xFFFF);

           if (++b == 256)
               break;
           printf(",");
       }
      printf("0;0);
   }


References

  [1]  Electronic Industries Association, "Interface Between Data
       Terminal Equipment and Data Communications Equipment Employing
       Serial Binary Data Interchange", EIA Standard RS-232-C, August
       1969.

  [2]  International Organization For Standardization, "Data
       Communication - High-level Data Link Control Procedures - Frame
       Structure", ISO Standard 3309-1979, 1979.

  [3]  International Organization For Standardization, "Data
       Communication - High-level Data Link Control Procedures -
       Elements of Procedures", ISO Standard 4335-1979, 1979.

  [4]  International Organization For Standardization, "Data
       Communication - High-Level Data Link Control Procedures -
       Elements of Procedures - Addendum 1", ISO Standard 4335-
       1979/Addendum 1, 1979.

  [5]  International Organization For Standardization, "Information
       Processing Systems - Data Communication - High-level Data Link
       Control Procedures - Frame structure - Addendum 1: Start/stop
       Transmission", Proposed Draft International Standard ISO
       3309:1983/PDAD1, 1984.

  [6]  International Telecommunication Union, CCITT Recommendation X.25,
       "Interface Between Data Terminal Equipment (DTE) and Data Circuit
       Terminating Equipment (DCE) for Terminals Operating in the Packet
       Mode on Public Data Networks", CCITT Red Book, Volume VIII,
       Fascicle VIII.3, Rec. X.25., October 1984.




Perkins                                                        [Page 37]

RFC 1134                          PPP                      November 1989


  [7]  Perez, "Byte-wise CRC Calculations", IEEE Micro, June 1983.
       Morse, G., "Calculating CRC's by Bits and Bytes", Byte, September
       1986.

  [8]  LeVan, J., "A Fast CRC", Byte, November 1987.

  [9]  American National Standards Institute, "American National
       Standard Code for Information Interchange", ANSI X3.4-1977, 1977.

 [10]  Postel, J., "Internet Protocol", RFC 791, USC/Information
       Sciences Institute, September 1981.

 [11]  Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC 1010,
       USC/Information Sciences Institute, May 1987.

 [12]  Postel, J., "The TCP Maximum Segment Size Option and Related
       Topics", RFC 879, USC/Information Sciences Institute, November
       1983.

Security Considerations

   Security issues are not addressed in this memo.

Author's Address

   This proposal is the product of the Point-to-Point Protocol Working
   Group of the Internet Engineering Task Force (IETF). The working
   group can be contacted via the chair:

   Russ Hobby
   UC Davis
   Computing Services
   Davis, CA 95616

   Phone: (916) 752-0236

   EMail: rdhobby@ucdavis.edu

Acknowledgments

   Many people spent significant time helping to develop the Point-to-
   Point Protocol.  The complete list of people is too numerous to list,
   but the following people deserve special thanks: Ken Adelman (TGV),
   Craig Fox (NSC), Phill Gross (NRI), Russ Hobby (UC Davis), David
   Kaufman (Proteon), John LoVerso (Xylogics), Bill Melohn (Sun
   Microsystems), Mike Patton (MIT), Drew Perkins (CMU), Greg Satz
   (cisco systems) and Asher Waldfogel (Wellfleet).




Perkins                                                        [Page 38]

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 90 13:59:14 GMT
From:      mentor.cc.purdue.edu!wvanbeek@ee.ecn.purdue.edu  (William W. Van Beek)
To:        tcp-ip@nic.ddn.mil
Subject:   tn3270 for Mac that uses the MacIP stack

I know that the folks at CLarkson have a tn3270 that uses the NCSA IP stack.
Did this ever get ported over to use the MacIP stack?  If so where can one
get a copy of it?

...bill van beek               wvanbeek@mentor.cc.purdue.edu
-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 90 14:06:33 GMT
From:      mcsun!sunic!tut!jh@uunet.uu.net  (Juha Hein{nen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: MacSLIP?
Cisco just announced a NCSA telnet version with SLIP support.  I don't
have the original message arround anymore, but I placed the stuff
available for ftp in funet.fi (128.214.1.1) directory pub/mac.
--
--	Juha Heinanen, Tampere Univ. of Technology, Finland
	jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 90 17:54:29 GMT
From:      cica!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!mips!smsc.sony.com!tucker@tut.cis.ohio-state.edu  (Tim Tucker 817)
To:        tcp-ip@nic.ddn.mil
Subject:   Public domain SNMP source
I've heard that a public domain implementation of SNMP exists for TCP/IP.
Does anyone know how to/where to get it?  The reference came from the Feb
Sun Observer.  It mentions Carnegie-Mellon University.

Thanks,

Tim
tucker@sonyusa.sony.com
-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 90 18:03:26 GMT
From:      uokmax!munnari.oz.au!cs.mu.oz.au!kre@apple.com  (Robert Elz)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: DNS Query server?
From Jon Postel...
> The IEN-116 name server is an old idea who's time is past.  
> Kill and bury any code that still does IEN-116.

Isn't that a little harsh, IEN-116 is a trivial protocol
to implement, is very stable, and is ideal for proms, etc.

As long as the server does a DNS lookup (with addition of some
default domain if needed), what's the harm?

kre
-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 90 19:18:57 GMT
From:      dcatla!endrk@gatech.edu  (David R. Koch)
To:        tcp-ip@nic.ddn.mil
Subject:   TGV contact
Does anyone have any information on TGV (Two Guys and a Vax???)?
If so (phone #, address, anything...), please email.
Thank you,
David Koch				Racal-Milgo Information Systems
    					Alpharetta, Georgia 
(404)442-4738				{gatech, sun!sunatl} !dcatla!endrk
-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Feb 90 11:46:47 -0800
From:      wrs!yuba!hwajin@uunet.UU.NET (Hwa Jin Bae)
To:        sun!decwrl!dcrocker@uunet.UU.NET
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP bind question
>Well, there certainly is a difference between TPI and TLI, and I did
>miss your reference in the original note, but I'm afraid that I don't
>think it helps the issue much.

There are not just one, but *many* differences between TPI and TLI.
I'm afraid you're confusing the comment about "mapping" between TLI to 
TPI as the "difference" between TLI and TPI.  This is a trivial issue;
they're called differently because they are different (but similar, as
the similarity in the name suggests).  What "issue"?

>TPI is the in-kernel interface.  TLI is the application level mapping
>to TPI, as you describe.

Redundancy.

>Unfortunately, the mapping between TPI and TCP (or UDP) is NOT
>subject to inherent or even universal definition.  Basically, the
>TLI and TPI interfaces assumed a TP4 environment.  (Yes, I know that
>they claim to be protocol independent.  So did sockets.)  But there
>still are places where a TCP implementor has choices of how to
>make some of the functionality available.  The acid test is to
>see the continued need for IOCTL within common applications.

The reality is that there is no single universal definition of 
anything anyway.  But TPI/TLI interfaces did *not* assume a TP4 
environment; it assumed *any* OSI Transport Protocol (i.e. TP0,TP1,
TP2,TP3 and TP4) environment.  That's why the TPI STREAMS message 
types are modeled after the IS 8072 Transport Primitives.  If you 
have the TPI spec you can find a table which maps each of the 
TPI message types to corresponding IS 8072 Transport Primitives, 
although there are several TPI extensions that don't have 
corresponding ISO T Primitives.  It is all matter of "degrees";
sockets *are* protocol independent to a certain degree (IMHO,
to a very satisfying degree) -- it currently provides interfaces
for the following protocols: TCP, UDP, IP, ICMP, VMTP, XTP,
XNS (SPP, PE, etc.), TP4,  and several others.  TPI and TLI
are protocol independent to the same (arguably more) degree --
not at all perfect but pretty reasonable.  They're reasonably
useful for me and I can build useful stuff on top of them.  And
they're not really that bad to implement.  That's the bottom line.
What's your point anyways?

hwajin
--
hwajin@wrs.com (uunet!wrs!hwajin)   "Omnibus ex nihil ducendis sufficit unum."
Hwa Jin Bae, Wind River Systems, 1351 Ocean Avenue, Emeryville, CA 94606, USA
-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 90 02:24:15 GMT
From:      zephyr.ens.tek.com!tektronix!sequent!mikel@beaver.cs.washington.edu  (Mike Leonard)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP to X.25 Gatway Box
I am trying to find a gateway box that would sit as a node on a tcp-ip
ethernet LAN and pass packets to a X.25 WAN. Has anyone out there had any
experience with such a box? Any suggestions of a possible vendor?

Thanks for the help!

Please respond by email.


-- 
| Michael S. Leonard			Sequent Computer Systems       |
| (503) 526-5910			15450 Koll Parkway             |
| ...uunet!sequent!mikel		Beaverton, OR 97006-6063       |
-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Feb 90 10:50:54 -0500
From:      James M Galvin <galvin@TIS.COM>
To:        usenet.ins.cwru.edu!cwjcc!ncoast!sgtech!adnan@tut.cis.ohio-state.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Authentication for SNMP - Are there any standards?
	In reading the SNMP RFCs I find mention of authentication of PDUs.
	Are there any standards for authentication mechanisms.

I have not seen a reply on the TCP-IP list, so let me do that.

There is currently work in progress, which is closing fast, to define 3
authentication mechanisms.  The first is just a recasting of the trivial
authentication identified in the SNMP specification.  The remaining two are
an integrity mechanism and mechanism that supports both integrity and
confidentiality.

The draft of the first document is available via anonymous FTP from
nic.ddn.mil in the internet-drafts: directory.  You can not miss it.

There are 2 supporting documents to the specification that will be appearing
shortly.  They were all distributed at the IETF meeting last week.  Following
some final editing they will also become Internet drafts.

The 3 documents could be described as follows:

	1.  How to do integrity and confidentiality assuming the existence of
	the necessary secrets (for example the cryptographic key).

	2.  How to distribute the necessary secrets.

	3.  What MIB objects are useful to documents 1 and 2.

Jim

PS.  I am one of the authors of all three documents.
-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Feb 90 12:23:41 CST
From:      dab@opus.cray.com (Dave Borman)
To:        wiltzius@lll-lcc.llnl.gov
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  TCP Retries
> I'm testing my port of a version of 4.3BSD TCP/IP code.  In
> doing so, I discard in the loopback driver every Nth packet
> (say, N=10).  This results in the MBUF pool being quickly
> depleted.  I discovered that the TCP input routine will
> save all out of order TCP packets waiting for the TCP retry
> to fill in the gaps.  Hence most of the MBUF pool is
> enqueued on this TCP fragment/reassembly list for this
> TCPCB.  Also, the sender continues to get ACKs advertising
> the largest window since the receive socket buffer is
> empty.
> 
> Nothing particularly evil happens and since this is
> a very degenerate case, perhaps I should just shrug
> my shoulders and go on with life.  But it does bother
> me a bit - rightfully so?  (Couldn't the window advertised
> by the receiver close, or a limit made on the number
> of out-of-order TCP packets on a TCPCB?)
> 
> Thanks for any help.
>   Dave (wiltzius@lll-lcc.llnl.gov)

There are a few things to be aware of.  First, the TCP
reassembly queue will not grow for ever.  It can only
hold as much data as was offered in the window.  So,
in theory, this is no different that having the user
process stop reading the socket, and letting the
receive queue fill up with data.

But in actuallity, there are some differences.  The 4.3
code does not do any compression on the data in the
reassembly queue, like it does on the receive queue for
the socket.  Thus, if you have a window of, say, 4k, and
you have the data coming in in 1 byte packets, and you
loose the first packet, you could wind up having over
four thousand mbufs stuck in the reassembly queue.

There are two things that should be done to improve
this situation:
	1) fix the reassembly code to do compaction.
	2) When you run out of mbufs, flush the tcp
	   reassembly queues.

Both of these features have been in our networking
code for several releases.

		-Dave Borman, dab@cray.com
-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 90 08:50:36 GMT
From:      usenet.ins.cwru.edu!cwjcc!ncoast!sgtech!adnan@tut.cis.ohio-state.edu  (Adnan Yaqub)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: free ftpd with statistics gathering.
In article <1990Feb14.120354.15038@diku.dk> seindal@skinfaxe.diku.dk (Rene' Seindal) writes:

   I have pieced together a version of Berkeleys ftpd, with all
   non-redistributable code rewritten.  It is based on a version found on
   uunet.uu.net.

   You'll find it in /pub/misc/ftpd.tar.Z, on ftp.diku.dk (129.142.96.1).

Isn't this kind of like distributing the sources to compress in
compressed form? (:-)
--
Adnan Yaqub
Star Gate Technologies, 29300 Aurora Rd, Solon, OH, 44139, USA, +1 216 349 1860
[...cwjcc!ncoast ...uunet!abvax ...ism780c ...sco ...mstar]!sgtech!adnan
-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 90 10:01:41 GMT
From:      wesommer@BLOOM-BEACON.MIT.EDU  (Bill Sommerfeld)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: DNS Query server?
In article <3184@munnari.oz.au> kre@cs.mu.oz.au (Robert Elz) writes:

   Isn't that a little harsh, IEN-116 is a trivial protocol
   to implement, is very stable, and is ideal for proms, etc.

Not really; I've seen a simple DNS resolver which is under 1K of
object code (not counting a very primitive UDP/IP implementation).  It
*does* depend on knowing the address of another server which will
support queries with "recursion desired" set, but I suspect that the
IEN116 protocol has a similar requirement.

This isn't a full resolver -- it only knows how to translate hostnames
to addresses, but that's probably enough in most cases.

				- Bill

--
Henry Spencer is so much of a  |    Bill Sommerfeld at MIT/Project Athena
minimalist that I often forget |    sommerfeld@mit.edu
he's there - anonymous         |
-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 90 10:03:07 GMT
From:      mcsun!hp4nl!phcoms!roes@uunet.uu.net  (Aloys Roes)
To:        tcp-ip@nic.ddn.mil
Subject:   freeing socket on TCP close request
We have a network application that uses the socket interface. The
client-side used to get a free TCP socket on the local system and then
connect to a Well Known Socket at the remote node. 

However, to be able to completely control access over the wide area
network we decided that we would use a fixed set of local portnumbers
for outgoing active connections. The client will try to bind to each of
these ports in sequence until it finds a free one. 

When the client is done with it's work it sends a confirmation message
to the server process. The server will close the connection and the
client will do the same. We notice however that after the close the
socket sticks around for a while (between 1 and 4 minutes depending on
the implementation). We tried to change the code so that the client side
closes first but then then the server side will have the connection open
for a while. 

We checked the TCP/IP documentation and that states that this is what 
the TCP layer ought to do. It waits 2 times the Maximum Segment 
Lifetime to ensure that the remote side receives the final ack. In our 
case however it restricts us very much in the number of open connection 
we can have between any 2 hosts.

So the question is, whether there is a way to avoid this delay after 
the connection has been closed e.g. decrease the MSL just before the 
'close' or use 'shutdown' instead of 'close'.

Thanks in advance,

Aloys Roes, Philips Components, Building BC-136, |  Tel. : + 31 40 72 30 62
P.O.Box 218, 5600 MD Eindhoven, The Netherlands  |  Email: roes@seri.philips.nl
-- 
     regards,

Aloys Roes, Philips Components, Building BC-136, |  Tel. : + 31 40 72 30 62
P.O.Box 218, 5600 MD Eindhoven, The Netherlands  |  Email: roes@seri.philips.nl
-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Feb 90 23:29:36 -0800
From:      Marshall Rose <mrose@cheetah.nyser.net>
To:        tucker@smsc.sony.com (Tim Tucker 817)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Public domain SNMP source
There are at least 3 non-proprietary SNMP agents for BSD UNIX.  There is the
MIT release, the CMU release, and the ISODE release.  I'm not sure where
the MIT and CMU releases are kept.  You can get the ISODE 6.0 release both
via FTP and USPS.  Drop bug-isode@nisc.nyser.net a note if you want the
contact information.

/mtr
-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Feb 90 19:09:16 EST
From:      Ravi Sinnarajah <RAVI%UMUC.BITNET@CORNELLC.cit.cornell.edu>
To:        TCP/IP Discussion List <TCP-IP@NIC.DDN.MIL>
Subject:   Pointers for PRinT SerVeR [VM/SP - TCP/IP] Implementations

*Greetings*!


I would like to know whether, anyone has implemented a PRINT SERVER
for a VM/SP(CMS) machine.  We are running WISCONSIN's TCP/IP implement-
ation and are exploring ways to spool the printouts from other hosts,
also supporting TCP/IP and print it on the printer attached to the IBM.
I've come across the PRTSVR by Columbia U and I foundout that it would
be hard to adopt theirs.

ADmanythanxVANCE for any info. you may provide in this regard.



Virtually Yours,
/Ravi.
[Ravi Sinnarajah]
VM Systems Programmer
Academic Computing
U of Md - University College
College Park, MD 20742-1615
-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 90 14:51:13 GMT
From:      zaphod.mps.ohio-state.edu!usc!venera.isi.edu!gremlin!nrtc!wdarden@tut.cis.ohio-state.edu  (Bill Darden <zaphod.mps.ohio-state.edu!usc!venera.isi.edu!gremlin!nrtc!wdarden@tut.cis.ohio-state.edu>)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP to X.25 Gatway Box
In article <29630@sequent.UUCP> mikel@sequent.UUCP (Mike Leonard) writes:
>I am trying to find a gateway box that would sit as a node on a tcp-ip
>ethernet LAN and pass packets to a X.25 WAN. Has anyone out there had any
>experience with such a box? Any suggestions of a possible vendor?

You might want to look at the ACC 4130.

BiLL.....
-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 90 15:15:23 GMT
From:      wallis@wsucsa.uucp
To:        comp.os.vms,comp.unix.ultrix,comp.protocols.tcp-ip
Subject:   VAX to IBM Telnet software (tn3270) under VMS or ULTRIX?


      Dear Netlanders:

      I have heard about a product called tn3270 (or something like that) that
allows a user on a VAX to make a TELNET connection to an IBM mainframe 
(assuming, of course, the IBM speaks TCP/IP).  I have also heard that is allows
full-screen IBM access.  Is this so or not?  Is there a CMU version of this?
It would be very helpful here at Wichita State if we had this.  We run
CMU TCP 6.4 and VMS 5.2.  Also, any pointers to a similar ULTRIX V3.1 product 
would be appreciated.  Thanks in advance,

                          Tom Wallis


-------------------------------------------------------------------------------
Thomas Wallis                          BITNET: WALLIS@TWSUVAX
System Manager, Computer Science Dept. Internet: wallis@wsuiar.wsu.UKans.EDU
Wichita State University               UUCP: uunet!ncrlnk!ncrwic!wsucsa!wallis
Wichita, Ks.  67208                    Internet: wallis@wsucsa.wsu.UKans.EDU

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

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 90 16:33:00 GMT
From:      bu.edu!lectroid!jjmhome!cpoint!frog!tdh@eddie.mit.edu  (T. Dave Hudson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Ethernet type 80F3 ?
> Ethernet type 0x80F3 is used by AppleTalk for address resolution.

According to the Xerox Systems Institute's memo of 1990-1-2, this code
is owned by Kinetics (of Walnut Creek, CA).  I found no reference to
Apple in the memo.  What gives?

				David Hudson
-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 90 17:48:08 GMT
From:      zaphod.mps.ohio-state.edu!uwm.edu!mailrus!umich!umeecs!itivax!b-tech!zeeff@tut.cis.ohio-state.edu  (Jon Zeeff)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Voice over Ethernet
Sounds like it's time for some voice mail/voice talk standards.


-- 
	- Make the world a better place -
Jon Zeeff    	zeeff@b-tech.ann-arbor.mi.us  or b-tech!zeeff
-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 90 19:14:36 GMT
From:      cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!nelson@tut.cis.ohio-state.edu  (Russ Nelson)
To:        tcp-ip@nic.ddn.mil
Subject:   PC 3c505 packet driver
The 3c505 packet driver for the IBM PC is now orphaned.  The original authors
do not have the time to bring the driver into working order.  The current
state of the driver is that it will send and receive a limited number of
packets, and then it hangs.  The authors will hand over their copy of
the documentation to the new adoptive parent.  Anyone who is interested
in getting this driver should send me mail.
-- 
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
Violence never solves problems, it just changes them into more subtle problems
-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 90 19:44:08 GMT
From:      ucsdhub!hp-sdd!ncr-sd!ncrlnk!ncrcce!mercer@ucsd.edu  (Dan Mercer)
To:        tcp-ip@nic.ddn.mil
Subject:   PD slip for SVr5?
Is there a PD SLIP for SVR5 (3.2 and pre 3.2).  Could someone send it to
me.

Thanks in advance,

-- 

Dan Mercer
Reply-To: mercer@ncrcce.StPaul.NCR.COM (Dan Mercer)
-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 90 19:52:49 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!mips!prls!pyramid!infmx!kwang@ucsd.edu  (Kwang Sung)
To:        tcp-ip@nic.ddn.mil
Subject:   A Bridge between "pure" OSI stack and RFC 1085 based product

Hi... there,

	Does anybody have a bridge between "pure" OSI product and
RFC 1085 based product ??  We are implementing RDA on top of "pure" OSI
and also on top of RFC 1085 with ISODE 6.0 + Sunlink OSI 6.0 for 
SQL Access Group. This product will also talk to DDN in the future.
Thanx.


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang
-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 90 00:09:16 GMT
From:      RAVI@UMUC.BITNET (Ravi Sinnarajah)
To:        comp.protocols.tcp-ip
Subject:   Pointers for PRinT SerVeR [VM/SP - TCP/IP] Implementations


*Greetings*!


I would like to know whether, anyone has implemented a PRINT SERVER
for a VM/SP(CMS) machine.  We are running WISCONSIN's TCP/IP implement-
ation and are exploring ways to spool the printouts from other hosts,
also supporting TCP/IP and print it on the printer attached to the IBM.
I've come across the PRTSVR by Columbia U and I foundout that it would
be hard to adopt theirs.

ADmanythanxVANCE for any info. you may provide in this regard.



Virtually Yours,
/Ravi.
[Ravi Sinnarajah]
VM Systems Programmer
Academic Computing
U of Md - University College
College Park, MD 20742-1615

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18 Feb 90 00:31:18 EST
From:      Dave_Katz@um.cc.umich.edu
To:        neeraj%matrix.uucp@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   IEEE 802 packets on 802.3 media
For starters, you should decouple 802.2 from 802.3, they are quite
separate.  In fact, you won't see much 802.3 framing on LANs,
except for OSI packets.  SNAP framing for IP, in particular, is
virtually never done on 802.3; rather, ethernet framing is used
instead.  802.2/SNAP is the only way to go on token ring, token
bus, and FDDI, however.
 
> 1. Is the ethertype same as the ethertype in ethernet packet header?
 
Yes.  This provides a way of representing Ethernet protocols on 802
media, since Ethernet identifies the protocol above within the MAC
frame, whereas 802 effectively does not.
 
> 2. Will dsap and ssap ever be different i.e.  What is the justification for
>    having two numbers?
 
In the case of the SNAP SAP, SSAP will typically equal DSAP.  There are
some exception cases;  for instance, an 802.2 XID command can be sent
to the broadcast SAP, and each active SAP in the station would need
to respond (so in this case, in the request, SSAP=x, DSAP=BCAST, and in
the response, SSAP=SNAP, DSAP=x).  802.2 itself does not constrain the
use of SAPs, except to identify special cases (null, broadcast, and
group).  See IEEE 802.2 for gory details.
 
> 3. In practice which protocols use SNAP. I think IP uses SNAP, do
>    other protocols such as DECNET, Apple Talk, Novell etc. which
>    have ethertype assigned to them always use SNAP or do they have
>    newer dsap and ssap numbers assigned to them?
 
Right now, IP and ARP are the biggest users of SNAP (though on other
802 media, not 802.3).  It appears likely that "translucent" bridges
that connect ethernets together over other 802 media (in particular,
FDDI,  which is "802-like") will enapsulate ethernet frames in SNAP
headers to get them across the foreign media, so any ethernet protocol
could conceivably be carried this way.  SSAP/DSAP address space is
scarce (126 values, or thereabouts), so they are not given away
lightly.  All OSI protocols use a single SAP value, and are demuxed
at the network layer instead.  SAP values will tend to be assigned
to families of protocols, rather than specific ones.
 
> 4. Which protocols do not use SNAP?  What are the current assigned
>    values of dsap and ssap?
 
OSI protocols do not use SNAP.  IEEE keeps the registry of SAP values.
I recall that x'FE' means "OSI network layer protocol".  There are 
probably others, but not too many.
 
> 4. When is protid not zero?
 
This field is really the Organizationally Unique Indentifier, or OUI.
This allows proprietary protocols to be demuxed.  Organizations
can presumably stick their 23-bit IEEE-assigned org code in this
field and do whatever they want with the rest.  0-0-0 is a special
value assigned for ethernet encapsulation.
-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 90 20:00:24 GMT
From:      pacbell!rtech!wrs!hwajin@ames.arc.nasa.gov  (Hwa Jin Bae)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Ethernet Throughput (AMD vs. Intel vs. Seeq)
In article <12566152530.17.BILLW@MATHOM.CISCO.COM> BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes:
> [...]
>So that's how ethernet controllers can "stall" a processor.  As others
>have pointed out - clever hardware designs can get around this by using
>dual ported memory, or other features.

Oh yes... a voice of reason.  I know several designs that suffer from
this very problem.  Additionally, some of the VME CPU boards that have
on board LANCE chips (I won't mention names here...) and do not dedicate
a small pool of separate memory for the LANCE ring buffers should be banned.
A little separate RAM goes a long way... FAST.
-- 
hwajin@wrs.com (uunet!wrs!hwajin)   "Omnibus ex nihil ducendis sufficit unum."
Hwa Jin Bae, Wind River Systems, 1351 Ocean Avenue, Emeryville, CA 94606, USA
-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 90 00:07:13 GMT
From:      mcsun!ukc!axion!news@uunet.uu.net  (Martin Kirk)
To:        tcp-ip@nic.ddn.mil
Subject:   One-shot ftp client
Does anyone have a one-shot ftp client that takes all its arguments,
(host, username, password, filename, etc), from the command line?

I have seen several references to the existence of such a program and
now have a need for one. True to tradition I would like to avaoid
writing it if at all possible.

Thanks in advance,

Martin Kirk


============================================================================
E-Mail:       MKirk@axion.bt.co.uk (...mcvax!ukc!axion!mkirk)
Organisation: British Telecom Research Laboratories (RT3134)
Snail Mail:   BTRL, Rm 306A SSTF, Martlesham Heath, IPSWICH IP5 7RE, UK
Telephone:    +44 473 642518            Fax: +44 473 643019
Quote:        "It has been stated somewhere that men can be divided into
	       two classes - those who can and those who can not stop a dog
	       fight."          "Bulldog Drummond at Bay" by "Sapper"
============================================================================
-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 90 00:52:06 GMT
From:      tropez!dlucy@uunet.uu.net  (Doug Lucy)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP on Xenix and DOS
I've a couple of questions:

	What is pcip in the uunet dir /usr/spool/ftp/networking/pcip ?
	Is this a TCP/IP for PC's running DOS?
	Is there a PD version of TCP/IP for SCO Xenix ?

Thanks.

-- 

  "It's such a fine line between clever..."     < Doug Lucy           DC Pro >
  "...and stupid."                              < uucp:   uunet!tropez!dlucy >
  "Yeah, stupid."                               < bbs:          703-370-8672 >
-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 90 04:23:15 GMT
From:      drilex!dricejb@bbn.com  (Craig Jackson drilex1)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: DNS Query server?
The facts of IEN116 are: It's ridiculous for anything on the Internet.
It works fine for a small commercial Ethernet with a few PCs or 
terminal servers on it.

TCP/IP lives outside of the Internet.  Given the research/academic
orientation of the Internet, and the billing issues that exist,
commercial TCP/IP nets will likely continue to be isolated for quite
a long time.
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 90 04:45:20 GMT
From:      root@sbcs.sunysb.edu  (SBCS System Staff)
To:        tcp-ip@nic.ddn.mil
Subject:   Discarding fragment assembly queues in low mem situation
I have a port of Berkeley TCP-IP that I am interested in tuning.  One
area that is causing some trouble is the management of the fragment assembly
queue in a low/no memory situation.  The current Berkeley code simply
flushes all the fragment queues when the system is out of network
buffers.  One possible solution would be to LRU the queues out, but the
claim I heard was this will unduly penalize long delay networks.  Another
solution recommended was to just randomly discard queues when out of memory.
Does anyone have a better algorithm than the two discussed here?  It would
seem that something along the lines of LRU modified with information about 
average packet arrival rate would be more appropriate (but is it worth the
extra work).

					Rick Spanbauer
					State U of NY/Stony Brook
-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Feb 90 13:09:05 -0500 (EST)
From:      Marvin Sirbu <ms6b+@andrew.cmu.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use
One of the positive benefits of billing for use is that it provides an incentivefor users to invest in conservation.  The problem is similar to the problem
of apartment renters for whom energy costs are bundled:  they have no incentive
to close their windows, or turn down their thermostat.

Consider for example FTP of large files.  The published FTP spec has provisions
for a checkpointing procedure so that an FTP can be restarted if the
connection breaks, thus saving retransmission from the beginning of a large
tar file.  Yet virtually no FTP implementations in use today use this
facility.  If users were charged per packet, they could cost justify spending
money on a commercial implementation of FTP which did implement checkpointing.
Our campus LAN doesn't bill for usage, and one user was found backing up
a 10 MB file--in its entirety--to a server every few seconds.  If there were
a charge for usage, he would have spent the few hours
it would have taken to write a procedure
for saving incremental changes rather than the entire file.  Without usage
charges, there was no incentive to spend five minutes on the problem.

I agree with Alex that we must first decide what POLICY we want to have
and then design a pricing strategy accordingly.  I believe, however, that
one element of such a policy must be to provide an incentive for users
to spend effort|dollars on software which is conserving of network resources
when such expenditures are cheaper than adding to network capacity.


Marvin Sirbu
CMU
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Feb 90 13:50:17 PST
From:      Greg Satz <satz@cisco.com>
To:        mcsun!sunic!tut!jh@uunet.uu.net (Juha Hein{nen)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: MacSLIP?
I would like to restate that the NCSA Telnet available from cisco is
unsupported. It is something I do on my own time and cisco is kind enough
to provide a place to make it available.

Greg Satz
cisco

>> Cisco just announced a NCSA telnet version with SLIP support.  I don't
>> have the original message arround anymore, but I placed the stuff
>> available for ftp in funet.fi (128.214.1.1) directory pub/mac.
>> --
>> --	Juha Heinanen, Tampere Univ. of Technology, Finland
>> 	jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)
-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 90 06:37:33 GMT
From:      bywater!acheron!archet!larouch!yozzo@uunet.uu.net  (Ralph Yozzo)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network General
In article <841@ucs.UAlberta.CA> DKRUGER@ucs.UAlberta.CA writes:
>Does anyone have a telephone number for Network General?  I need a # which
>is accessable from Canada.
> 
>We need to have some repairs done on our Siffer ethernet card, and the
>vendor who originally supplied it wants an outrageous amount for its repair.
> 
>Dwight Kruger
>Network Software Development
>University of Alberta


The numbers that I have are

Network General Corp.
1945A Charleston Road
Mountian View, CA 94043

(415) 965-1800  Fax (415) 965-9608

==Ralph E. Yozzo == 
==Arpanet: yozzo@ibm.com==
==Bitnet: yozzo@yktvmx.bitnet==
==Home: ..!uunet!bywater!acheron!larouch!yozzo ===Ph:(914)945-3634 or 564-4731
-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Feb 90 17:08:16 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   needed -- tcp-ip-products

Hi folks:
    
    It seems to me that increasingly the TCP-IP list is being filled with
messages of the form "anyone know anything about product X?", to the
expense of interesting technical notes.  (I have to plow through
the product junk mail to find the interesting stuff).

    Does anyone else out there think it might be useful to create
a separate list for such requests and their answers?  (If you are afraid
that by splitting off the product side, the questions won't get answered,
I assure you that the vendors have a large interest in seeing product
related questions answered, and given a vendor and its competitors are
both on the list, an answer is likely to be accurate).

Craig
-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 90 08:57:08 GMT
From:      mcsun!hp4nl!ruuinf!praxis!edwin@uunet.uu.net  (Edwin Kremer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: free ftpd with statistics gathering.
In article <ADNAN.90Feb16085036@sgtech.UUCP> adnan@sgtech.UUCP
(Adnan Yaqub) writes:

    > In article <1990Feb14.120354.15038@diku.dk> Rene' Seindal writes:
    >   You'll find it in /pub/misc/ftpd.tar.Z, on ftp.diku.dk (129.142.96.1).

 | Isn't this kind of like distributing the sources to compress in
 | compressed form? (:-)

No, absolutely not. Rene' is talking about an ftp daemon and you *do not*
need an ftp daemon yourself to get his version: you need an ftp client
program.

						--[ Edwin ]--
--
Edwin Kremer (SysAdm), Dept. of Computer Science, Utrecht University
Padualaan 14,   P.O. Box 80.089,  3508 TB  Utrecht,  The Netherlands
Telephone: +31-30-534104  | UUCP: ...!uunet!mcsun!hp4nl!ruuinf!edwin
Telefax  : +31-30-513791  | Email: edwin@cs.ruu.nl    [131.211.80.5]
-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Feb 90 18:10:14 PST
From:      adelman@TGV.COM (Kenneth Adelman)
To:        dcatla!endrk@gatech.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: TGV contact
> Does anyone have any information on TGV (Two Guys and a Vax???)?
> If so (phone #, address, anything...), please email.

    TGV, Incorporated
    603 Mission Street
    Santa Cruz, CA  95060
    800-TGV-3440 (408-427-4366)

    or POSTMASTER@TGV.COM

    Now "Those Guys and VAXen" ;-) (6 Guys; 4 VAXen)

							    Ken
-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Feb 90 19:13:28 EST
From:      bzs@world.std.com (Barry Shein)
To:        uunet!think.com!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!emv@encore.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   billing for use

Well, I always say you can either bake more bread or organize bread
lines. I like to listen to the bread bakers myself.

I'm not sure simple conservationist ethics scale very well into the
computer biz. The wierd thing about networking (and computing in
general) is the stuff costs just as much whether it's being used or
not. Actually, it costs more if it's not being used, sorta the same
reasoning one would make about idle land to a farmer, lost opportunity
and all that.

I suppose if one postulates that there will never be enough so we may
as well make sure only the rich get fat. Let's face it, any charges
which are rational in the large will be a pittance to the wealthier
clients. That's why conservation has its limits, you can't charge
enough to stop the gluttonous without killing the starving.

The economics of networking are very subtle. But I do know one thing,
the BOCs don't increase charges soas to get everyone to simply use
less. It doesn't really work that way with infrastructure economics,
it just ain't that simple, or that depressing.

        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 90 14:46:17 GMT
From:      att!cbnewsj!wuu@ucbvax.Berkeley.EDU  (john.t.wuu)
To:        tcp-ip@nic.ddn.mil
Subject:   Seeking KA9Q UNIX porting experience
Hello World,

	I hope this is not a repeated question.

	Has anybody ported "KA9Q" on UNIX SysV ?
	Where can I get the source (Unix version) ?
	Is the effort a straightforward job ?

	Any information will be appreciated.

				John Wuu
-- 
John T. Wuu	..!att!feathers!wuu or wuu%feathers@att.com
-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Feb 90 23:28:48 EST
From:      "Louis A. Mamakos" <louie@sayshell.umd.edu>
To:        Craig Partridge <craig@nnsc.nsf.net>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: needed -- tcp-ip-products
YES! YES!  Many of us are on the verge of dropping off the TCP-IP list
because of the crummy signal-to-noise ratio lately.  Not much of the
traffic lately has had much to do with TCP-IP implementations and protocol
issues.

A seperate list, with those who are interested in products and things
might be just what both groups of folks need.

louie
-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 90 21:17:32 GMT
From:      zaphod.mps.ohio-state.edu!math.lsa.umich.edu!emv@think.com  (Edward Vielmetti)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use
In article <UZs3N1200ioEM8f4Ma@andrew.cmu.edu> ms6b+@ANDREW.CMU.EDU (Marvin Sirbu) writes:

   One of the positive benefits of billing for use is that it provides
   an incentive for users to invest in conservation.  The problem is
   similar to the problem of apartment renters for whom energy costs
   are bundled: they have no incentive to close their windows, or turn
   down their thermostat.

One of the problems associated with billing for use is that is
provides incentives to circumvent billing procedures, thus generating
possible non-optimal behavior.  Consider a tax on anonymous FTP
transactions; users will either find a way to make their anonymous
FTPs look like something else (run an FTP daemon on the SUPDUP port,
or hide it up in some un-numbered port) or turn to heavier use of
mail-based servers and clog up already jammed mail queues.  Similarly,
a tax on TCP services will induce people to use UDP even when it might
be sub-optimal for use on their particular network.

When you start to bill for use on a per-packet or per-connection
basis, the Law of Unintended Consequences is bound to strike.  
If you have naive or uneducated users, solve their inefficient
use of the network through education, not a tax on their foolishness.

--Ed
-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Feb 90 11:03:33 -0800
From:      wrs!yuba!hwajin@uunet.UU.NET (Hwa Jin Bae)
To:        unet!nsl.dec.com!dcrocker@uunet.UU.NET
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP bind question
[Dave Crocker writes...]
>The differences between sockets() implementations, as you state, is
>pretty much a case of implementation error, except to the extent that
>4.2BSD and 4.3BSD have differences or to the extent that one fixes
>bugs in the semantics of them.  (That is, the Berkeley implementations
>are the formal definition to sockets(), by definition.  But, they
>have bugs.  If one implements sockets() on a new platform, but fixes
>those bugs, you no longer conform to the 'formal' definition to
>sockets().)

Sure, most people already know this anyway.  We've all been once or
twice bitten by the differences between 4.1c, 4.2 and 4.3BSD differences.
The differences you describe, namely those between 4.2 and 4.3 are minor
compared to the differences between 4.1c and 4.2.  People who've used
them would know what I mean.  Still, it is not that terribly hard to
modify the application code to make them run on all of the above 4.*
systems.

In practice, the amount of code you have to change because of the 
differences in the socket interface for a given application is small 
compared to other system dependent changes that have to be made due to 
many other incompatible features such as TTY interface, directory 
handling, signals, and numerous other device specific ioctl's, etc.  
After all, that's why most people are hoping for POSIX althoug even 
with a formalized standard, it is pretty hard to get every 
implementation of any standard 100% compliant on anything.

Given this, I find no substance in your elaboration of the differences
in BSD socket interfaces;  I fail to see any crucial point in your 
discussion... and it's getting pretty stale, fast.  Are you complaining
merely of the imperfections in the 4.* BSD standardization of the socket
interface?  If so, what's the point?  Every other piece of software,
when implemented by various vendors, will have the exact same problem
unless people decide spend enough time and money to make some kind of
application code compatibility conformance test as a requirement for
the market.  The current situation indicates that this type of 
incompatibility is trivial and not worth the resources that may be 
required for such efforts -- although it seems to be changing --
for the better.  How many products are shipped with source codes
anyway?  Systems and application programmers can handle these
simple modifications with minor difficulty -- thus, the economics
rules.  [I agree, in principle, this is not so desirable.  But we're
not living in a perfect world.]

>The differences between implementation of TCP available through TPI or
>TLI are deeper.  Because the service interfaces to TPI and TLI are not
>perfectly matched to TCP, there are design choices to be made.  They
>are, of course, made differently by different implementors and therefor,
>they are incompatible.

Pretty much the only difference, if any, that exists between various
implementations has to do with the name of the STREAMS device you 
open via TLI to get a TCP STREAM or any other protocol STREAM.  One
other prevalent and possible difference seems to be the address
binding semantics.  Beyond these, there are *NOT* that many differences.

Feel free to research your findings and come up with some major
differences between different TLI implementation that will cause
major grief and condemn network programmers to hell.  I've written
TLI applications and test codes for my implementation and I also
ported them from Motorola Delta VME boxes running Unix V.3 to 
80386 PC's running ISC TCP/IP and 386 running Excelan's TCP/IP 
and 386 running Streamlined TCP/IP and 386 running Wollongong's 
-- no doubt you're familiar with this one -- TCP/IP with *no* problem 
what so ever.  It was easier to port the TLI application around 
over these various TLI implementations than to port 4.2BSD based 
socket application to 4.1c BSD  based socket interface.  

Do you have actual experience in doing the actual porting 
of TLI applications to these various platforms?  I do.  Do you have 
actual experience working on implentations of TLI library, a TPI
and TCP/IP in Unix kernel?  I do.  Your rhetorics sound good
but clearly indicates your superficial knowledge.  Besides, 
you still don't get it after all that I explained:  there is *no* 
direct mapping going on between TLI and TCP in an AT&T TPI 
spec conformant environment.  The mapping happens between TPI 
and TCP.  And there is no problem there.  Tell me about a 
specific problem that can not be reconciled.  Give me some examples.

As Douglas Hoftstadter once said, "You need to understand before you
can criticize."

>The test of this issue is the extent to which an application can be
>ported from one Streams environment with TCP to another one, without
>code change.  The answer is that many applications need to be changed.

Which ones?  In what way?

hwajin
--
hwajin@wrs.com (uunet!wrs!hwajin)   "Omnibus ex nihil ducendis sufficit unum."
Hwa Jin Bae, Wind River Systems, 1351 Ocean Avenue, Emeryville, CA 94606, USA
-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 90 21:49:31 GMT
From:      elroy.jpl.nasa.gov!usc!samsung!munnari.oz.au!kaukau.comp.vuw.ac.nz!asjl@decwrl.dec.com  (Andy Linton)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Ethernet Throughput (AMD vs. Intel vs. Seeq)
There have been a number of articles on the problems with the LANCE.

Has anyone any idea if this is used on the MICOM-Interlan boards, NI5010
and NP600A. I'm trying to track down a problem with transfer rates on
machines using these boards. Also there seems to be some debate about
whether the 3-Com boards use the LANCE.

Thanks
andy
--
SENDER = Andy Linton
EMAIL  = Andy.Linton@comp.vuw.ac.nz	PHONE = +64 4 721 000 x8978
-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 90 21:50:17 GMT
From:      satz@CISCO.COM (Greg Satz)
To:        comp.protocols.tcp-ip
Subject:   Re: MacSLIP?

I would like to restate that the NCSA Telnet available from cisco is
unsupported. It is something I do on my own time and cisco is kind enough
to provide a place to make it available.

Greg Satz
cisco

>> Cisco just announced a NCSA telnet version with SLIP support.  I don't
>> have the original message arround anymore, but I placed the stuff
>> available for ftp in funet.fi (128.214.1.1) directory pub/mac.
>> --
>> --	Juha Heinanen, Tampere Univ. of Technology, Finland
>> 	jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 90 22:08:16 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   needed -- tcp-ip-products


Hi folks:
    
    It seems to me that increasingly the TCP-IP list is being filled with
messages of the form "anyone know anything about product X?", to the
expense of interesting technical notes.  (I have to plow through
the product junk mail to find the interesting stuff).

    Does anyone else out there think it might be useful to create
a separate list for such requests and their answers?  (If you are afraid
that by splitting off the product side, the questions won't get answered,
I assure you that the vendors have a large interest in seeing product
related questions answered, and given a vendor and its competitors are
both on the list, an answer is likely to be accurate).

Craig

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Feb 90 06:34:13 PST
From:      Dave Crocker <dcrocker@nsl.dec.com>
To:        wrs!yuba!hwajin@uunet.uu.net (Hwa Jin Bae)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP bind question
The differences between sockets() implementations, as you state, is
pretty much a case of implementation error, except to the extent that
4.2BSD and 4.3BSD have differences or to the extent that one fixes
bugs in the semantics of them.  (That is, the Berkeley implementations
are the formal definition to sockets(), by definition.  But, they
have bugs.  If one implements sockets() on a new platform, but fixes
those bugs, you no longer conform to the 'formal' definition to
sockets().)

The differences between implementation of TCP available through TPI or
TLI are deeper.  Because the service interfaces to TPI and TLI are not
perfectly matched to TCP, there are design choices to be made.  They
are, of course, made differently by different implementors and therefor,
they are incompatible.

The test of this issue is the extent to which an application can be
ported from one Streams environment with TCP to another one, without
code change.  The answer is that many applications need to be changed.

Dave
28
-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 90 22:45:08 GMT
From:      uwm.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!winnie!zach!rcs89301@lll-winken.llnl.gov  ( Thomas E. Currey)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: One-shot ftp client

Off the top of my head: you might try this
It accepts the arguements you wanted

usage :  shftp address loginname password [file1 file2 file3 file4 file5 file6]


-----------------------CUT HERE Beware no comments read manual--------------
#! /bin/sh
cat "machine $1 login $2 password $3" >> $HOME/.netrc
chmod 600 $HOME/.netrc
echo "binary
get $4 
get $5 
get $6 
get $7 
get $8 
get $9 
quit" > $HOME/ftp.tmp
ftp $1 < $HOME/ftp.tmp > /dev/null       
rm $HOME/ftp.tmp
--------------------------------------------------------------------------

There is also a nifty program on simtel20. It dos the same thing
but with a timer. "auto-ftp"
-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Feb 90 07:17:47 EST
From:      Thomas Narten <narten@cs.albany.edu>
To:        "William " Chops " Westfield" <BILLW@mathom.cisco.com>
Cc:        dino!cs.iastate.edu!hascall@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Re: Proper handling of PUSH & small window by sender?
>PUSH is currently considered rather a bad idea.  It is more of a
>user->tcp level thing, as opposed to something that belongs in the
>protocol layer.

I'm not sure that PUSH can be swept under the rug as a "bad idea".  It
is a necessary compromise between deadlock avoidance and inefficiency.
For efficiency reasons, the transport layer wants to delay sending
data in order to coalesce several application write operations into a
single outgoing datagram.  (Likewise, the receiving TCP module might
delay handing data to the application layer until more data arrives.)
If the application sends one byte and then waits for a response,
however, delaying the sending of the data byte may produce a deadlock.
Applications use the PUSH operation to prevent the latter case.  It
directs TCP "flush its buffers" and hand any buffered data (up to the
PUSH mark) to the remote application.  In addition, PUSH does belong
in the protocol layer because it is the only way that the sending TCP
module can direct the receiving TCP module to flush its buffers.

Thomas Narten
-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Feb 90 11:42:32 -0500 (EST)
From:      Marvin Sirbu <ms6b+@andrew.cmu.edu>
To:        tcp-ip@nic.ddn.mil
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use


> The economics of networking are very subtle. But I do know one thing,
> the BOCs don't increase charges soas to get everyone to simply use
> less. It doesn't really work that way with infrastructure economics,
> it just ain't that simple, or that depressing.

I'm not advocating conservation for its own sake.  The key part of my
argument is the last sentence.

" I believe, however, that
one element of such a policy must be to provide an incentive for users
to spend effort|dollars on software which is conserving of network resources
when such expenditures are cheaper than adding to network capacity."

Additions to network capacity are not free.  To the extent that packet
conserving software allows costly expansion to be deferred, and the
software is less costly than the expansion, the software is to be
preferred.  True, off peak capacity has low marginal cost.  Conserving
capacity during off peak doesn't save much in plant expansion.  That's
why utilities with usage charges use peak load pricing.  They only need
to encourage conservation during peak hours, since it is peak hour use
which leads to the need for plant expansion.

Marvin Sirbu
 
-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Feb 90 12:17:59 PST
From:      postel@venera.isi.edu
To:        drilex!dricejb@bbn.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: DNS Query server?
 The facts of IEN116 are: It's ridiculous for anything on the Internet.
 It works fine for a small commercial Ethernet with a few PCs or 
 terminal servers on it.

 TCP/IP lives outside of the Internet.  Given the research/academic
 orientation of the Internet, and the billing issues that exist,
 commercial TCP/IP nets will likely continue to be isolated for quite
 a long time.


The notion that any network will remain small and isolated clearly ignores
all the experience of the last 20 years.

--jon.
-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Feb 90 09:35 EST
From:      "Barry L. Newton" <NEWTON@ENH.NIST.GOV>
To:        TCP-IP@NIC.DDN.MIL
Subject:   IBM SYS/36/38/AS400 TCP-IP
Is anyone aware of TCPIP implementations for the IBM
System/36/38/AS400 computers?  We asked this question a year or
two back and got several references to Mitek.  This year there
may actually be funding to do something, so it seems worth
another look at the market.

I am not on this list, so please send any responses directly to
me.  If anything worthwhile shows up, I will summarize to the
list.  (The short time I did spend on this list taught me a great
deal about brevity and economy.)

Thanks for any help.

Barry L. Newton
National Institute for Standards & Technology
(301/975-4070)
-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 90 05:14:53 GMT
From:      shelby!portia!jessica!morgan@decwrl.dec.com  (RL "Bob" Morgan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Questions about IEEE 802 packets on ethernet media

> 3. In practice which protocols use SNAP. I think IP uses SNAP, do
>    other protocols such as DECNET, Apple Talk, Novell etc. which
>    have ethertype assigned to them always use SNAP or do they have
>    newer dsap and ssap numbers assigned to them?

AppleTalk Phase 2 uses 802.2/SNAP encapsulation on 802.3 (Ethernet)
and 802.5 (Token Ring).  AppleTalk Phase 1 uses Ethernet encapsulation
on Ethernets.

 - RL "Bob" Morgan
   Networking Systems
   Stanford
-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Feb 90 11:55:39 EST
From:      Frank Kastenholz <kasten%interlan.interlan.com@RELAY.CS.NET>
To:        craig@NNSC.NSF.NET, tcp-ip@NIC.DDN.MIL
Subject:   Re:  needed -- tcp-ip-products
Craig,

A separate product list might be useful - but what would be more useful would
be to keep the list-of-lists more accurate. In a previous life, the product
that I was working on had its own discussion list - and that list was
very active and there was very little "noise" on the TCP-IP list. I think
that the people who create these lists should be made more aware of the
list-of-lists (I have no idea how :-) AND the folks in net-land should
be more aware of it. This is not a problem for list-of-lists maintainers..
It is that this kind of information gets sort of lost in the folklore
and new people don't know about it.

Cheers
Frank Kastenholz
Racal Interlan



-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Feb 90 12:44:44 EST
From:      Brian Holmes <BHOLMES@CMS.CC.WAYNE.EDU>
To:        TCP/IP newsgroup <TCP-IP@SRI-NIC.ARPA>
Subject:   DNS question
According to RFC1034 4.2.1, one should not have to code glue
RR's for name server's names unless they are below the cut.
When I don't put glue RR's in, and do a query for NS records,
the 'additional' field is left blank.  As far as I can tell,
all other zones I query for NS records have this filled with
the IP addresses of the NS hosts.  Is this required or
should I not be concerned that the additional field is empty?

                        Brian Holmes
                        UCC Operating Systems & Communications

PHONE:    (313) 577-3750  FAX=577-5626          Wayne State University
BITNET:   BHOLMES@WAYNEST1                      5925 Woodward
INTERNET: BHOLMES@CMS.CC.WAYNE.EDU              Detroit, MI 48202  U.S.A
-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Feb 90 14:35:49 EST
From:      dlj@proteon.com (Daniel L. Jones)
To:        zephyr.ens.tek.com!tektronix!sequent!mikel@beaver.cs.washington.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP to X.25 Gatway Box

  Proteon has an IP to X.25 Router, which can connect an Ethernet LAN
to an X.25 WAN (DDN or PDN).

Dan Jones
Proteon Customer Service
-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 90 11:33:54 GMT
From:      mcsun!ukc!strath-cs!jim@uunet.uu.net  (Jim Reid)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use
In article <EMV.90Feb19161732@duby.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes:
>One of the problems associated with billing for use is that is
>provides incentives to circumvent billing procedures, thus generating
>possible non-optimal behavior.

Exactly. What about exchanging routing information? If somebody starts
throwing misdirected packets at me, why should I have to pay for
returning ICMP redirects? Likewise, if I'm running EGP or some other
routing protocol, why should I have to pay for the packets I send to
other sites to tell them what is reachable through me?

		Jim
-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Feb 90 16:05 EDT
From:      James Dryfoos- PostMaster <DMPM%DUKEMC.BITNET@VTVM1.CC.VT.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   packet size for ethernet
What is the biggest TCP packet size that can be sent on ethernet?
What is largest ethernet packet?

-Jim
-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 90 14:09:24 GMT
From:      ww@reading.ac.uk (Weimin Weng)
To:        comp.protocols.tcp-ip
Subject:   Help on "Object identifier, Object name and Relative Distingulshed Name" needed

Hi:
Would anyone in this news group give me a few examples on how the Relative Distinguished
Name is configured and the relationships among the Object identifier, Object name and
Relative Distinguished Name. Many thanks.

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 90 14:35:00 GMT
From:      NEWTON@ENH.NIST.GOV ("Barry L. Newton")
To:        comp.protocols.tcp-ip
Subject:   IBM SYS/36/38/AS400 TCP-IP

Is anyone aware of TCPIP implementations for the IBM
System/36/38/AS400 computers?  We asked this question a year or
two back and got several references to Mitek.  This year there
may actually be funding to do something, so it seems worth
another look at the market.

I am not on this list, so please send any responses directly to
me.  If anything worthwhile shows up, I will summarize to the
list.  (The short time I did spend on this list taught me a great
deal about brevity and economy.)

Thanks for any help.

Barry L. Newton
National Institute for Standards & Technology
(301/975-4070)

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 90 16:51:16 GMT
From:      mcsun!sunic!dkuug!freja!skinfaxe!seindal@uunet.uu.net  (Rene' Seindal)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: free ftpd with statistics gathering.
adnan@sgtech.UUCP (Adnan Yaqub) writes:

> In article <1990Feb14.120354.15038@diku.dk> seindal@skinfaxe.diku.dk (Rene' Seindal) writes:

>    I have pieced together a version of Berkeleys ftpd, with all
>    non-redistributable code rewritten.  It is based on a version found on
>    uunet.uu.net.

>    You'll find it in /pub/misc/ftpd.tar.Z, on ftp.diku.dk (129.142.96.1).

> Isn't this kind of like distributing the sources to compress in
> compressed form? (:-)

No, it is the server end that is being distributed,not the client.  You only
need an FTP client to get it.

Rene' Seindal (seindal@diku.dk)
-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 90 17:44:44 GMT
From:      BHOLMES@CMS.CC.WAYNE.EDU (Brian Holmes)
To:        comp.protocols.tcp-ip
Subject:   DNS question

According to RFC1034 4.2.1, one should not have to code glue
RR's for name server's names unless they are below the cut.
When I don't put glue RR's in, and do a query for NS records,
the 'additional' field is left blank.  As far as I can tell,
all other zones I query for NS records have this filled with
the IP addresses of the NS hosts.  Is this required or
should I not be concerned that the additional field is empty?

                        Brian Holmes
                        UCC Operating Systems & Communications

PHONE:    (313) 577-3750  FAX=577-5626          Wayne State University
BITNET:   BHOLMES@WAYNEST1                      5925 Woodward
INTERNET: BHOLMES@CMS.CC.WAYNE.EDU              Detroit, MI 48202  U.S.A

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 90 17:45:14 GMT
From:      jmg@cernvax.UUCP (john gerard)
To:        comp.os.vms,comp.unix.ultrix,comp.protocols.tcp-ip
Subject:   Re: VAX to IBM Telnet software (tn3270) under VMS or ULTRIX?

In article <13536@wsucsa.uucp> wallis@wsucsa.uucp writes:
>      I have heard about a product called tn3270 (or something like that) that
>allows a user on a VAX to make a TELNET connection to an IBM mainframe 
>(assuming, of course, the IBM speaks TCP/IP).  I have also heard that is allows
>full-screen IBM access.  Is this so or not?  Is there a CMU version of this?
>It would be very helpful here at Wichita State if we had this.  We run
>CMU TCP 6.4 and VMS 5.2.  Also, any pointers to a similar ULTRIX V3.1 product 
>would be appreciated.  Thanks in advance,

We run a version of the old 3270 emulator, much rehashed to be faster,
better, smaller etc. etc., and have a lot of people using it on our
Ultrix systems (Vax and DECstations). The IBM speaks TCP/IP via an 8232
controller. The software also appears to run on Apollo and Sun.
As for a version on VMS, I have always had it in mind to make a version
by changing the terminal output from the current usage of low-level
termcap routines to a VMS equivalent, but haven't done it yet.
As for TCP 6.4, if I knew what it was ......
-- 
 _ _  o |             __                    |    jmg@cernvax.uucp
| | |   |     _      /  \  _   __  _   __  _|    jmg@cernvax.bitnet
| | | | |_)  /_)     |  __/_) | (___\ | (_/ |  J. M. Gerard, Div. DD, CERN,
| | |_|_| \_/\___    \__/ \___|   (_|_|   \_|_ 1211 Geneva 23, Switzerland

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 90 19:49:29 GMT
From:      haase@lanl.gov  (HAASE_PETER_K)
To:        tcp-ip@nic.ddn.mil
Subject:   NCSA Telnet
How can I obtain a copy of documentation for NCSA Telnet. I am
particularly interested in how to ftp. If it is not to much trouble 
could someone please send it to me via E-mail........Thanks 

-----------------------------------------------------------------------------
      Peter K. Haase				haase@meediv.lanl.gov
			(505) 667-2684
                Los Alamos National Laboratory (LANL)
-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 90 20:22:06 GMT
From:      haase@lanl.gov  (HAASE_PETER_K)
To:        tcp-ip@nic.ddn.mil
Subject:   NCSA Telnet
I have just installed NCSA Telnet 2.3 and I am in need of some
documentation. I am particularly interested in ftp. Can someone
please let me know how I can obtain a copy or maybe someone could
send it to me via E-mail........Thanks 

-----------------------------------------------------------------------------
      Peter K. Haase				haase@meediv.lanl.gov
			(505) 667-2684
                Los Alamos National Laboratory (LANL)
-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 90 20:46:54 GMT
From:      umabco!lwilson@cvl.umd.edu  (Lowell G. Wilson)
To:        tcp-ip@nic.ddn.mil
Subject:   Scorecard

About a year or so ago I remember seeing some "scorecards" floating
around the net that I thought would be useful so I saved them.  Well,
now that I have a use for the things I can't find them anywhere!  These
scorecards were in the form of a matrix and they listed certain TCP/IP
functions across the top and various PC TCP implimentations across the
side.  I could really use those matrices now so if someone could mail me
a copy, I'd appreciate it.  Thanks in advance...
-- 
Lowell Wilson : Sinecure III        University of Maryland at Baltimore    
                                    Information Resources Mgt Division     
                                    UUCP: ...cvl!umabco!lwilson            
                                    Internet: umabco!lwilson@cvl.umd.edu
-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 90 20:49:09 GMT
From:      cscnj!paul@rutgers.edu  (Paul Moody)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP under MS-Windows
In article <972@ssp18.idca.tds.philips.nl>, michiel@idca.tds.PHILIPS.nl (Michiel Fierst van Wijnandsbergen) writes:
> Is there any one who has a TCP communication program working under MS-Windows?
...deleted...

After several frustating months we managed to get our app running 
using  Excelans Lan Workplace for DOS and windows, including 
Windows/386.

The problem is that most TCP/IP implementations for DOS rely on
'post back' routines. They expect that if you have passed a 
function/buffer pair during a connection api call(OPEN), those
pointers remain valid for the life of the app. This is known as 
asychronous non blocking api. In general this api is always used, its
effects are masked by blocking until the post back takes place. Blocking
until a response is recieved is unacceptable in a windows environment.

Windows, especially windows/386, wants to move things around with
abandon. Windows/386 will even move(swap out) fixed segments. Our 
solution was two fold.  

First we divided the application into a tcp/ip interface and the main 
app.  The tcp/ip window is small model with fixed data and code segments.
It communicates with the main app via DDE. Next we used a synchronous 
non-blocking api and poll the socket. This means using up a timer but 
this way tcp/ip wont try to put something into a buffer that windows 
has moved to the hinterlands of extended memory.

We have been told that with care, dll's can be used under windows/286
with the more effcient asynchronous-non blocking interface. This 
would not help us very much since we want to use windows/386.

The ultimate solution is for the various vendors of DOS tcp/ip
products to provide a windows device driver for their socket
interface. The device driver would live as part of dos space
and would never be moved by windows. It could use the asychronous
non-blocking interface to the actual tcp/ip drivers while doing
SendMessage calls to give you data.

Lets hope.
-- 
Paul Moody			UUCP: rutgers!cscnj!paul 
Computer Sciences Corporation
# the opinions expressed are entirely imaginary			#
-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 90 20:53:01 GMT
From:      ogicse!uwm.edu!bionet!turbo.bio.net!phakt.usc.edu@decwrl.dec.com  (Tony Li)
To:        tcp-ip@nic.ddn.mil
Subject:   comp.dcom.sys.cisco -- Final call for votes

A vote is currently under way for the creation of the newsgroup
comp.dcom.sys.cisco.  This is the final call for votes.  A second mass
acknowledgement has been posted to news.groups.  Attached is the
original call for votes:
----------------------------------------------------------------------

Group: 		comp.dcom.sys.cisco 

Charter: 	Vendor specific discussion about data communications
		products from cisco Systems Inc. 

Management: 	The group will be unmoderated.

Gateway:	The Internet cisco mailing list will have a one-way
		gateway into this group.  At some future time, the
		newsgroup may gateway into the mailing list.  This
		will be the topic of a separate vote, and should not
		be considered part of this newsgroup proposal.

Voting:		Votes should be sent to "tli@usc.edu" or "usc!tli".
		Per the USEnet newsgroup creation rules, votes must be
		explicit.  They should be of the form "I vote for the
		group comp.dcom.sys.cisco as proposed" or "I vote
		against the group comp.dcom.sys.cisco as proposed."
		Ambiguous votes will not count and will be returned to
		the sender.

Deadline:	Votes must be received by 11:59pm PST, Wed. Feb 28,
		1990 in my mailbox. 

Tony Li - USC Computer Science Department
Internet: tli@usc.edu Uucp: usc!tli
Thus spake the master programmer: "A well written program is its own
heaven; a poorly-written program its own hell."
-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 90 21:26:11 GMT
From:      andrew@dgbt.uucp (Andrew Patrick DGBT/DBR)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for PC Telnet with printer port support

In article <9002131739.AA19969@mvax.CC.CONNCOLL.EDU> sbbur@CONNCOLL.BITNET writes:
>Does anyone know of a PC Telnet implementation with vt100 terminal emulation
>that supports printing to a local printer via auto-print mode?
>
>We're currently running NCSA Telnet 2.2.  Although it does support a
>"capture file", it doesn't seem to support a local printer.

Try setting your capture file to PRN.  This works fine with the 2.2D
version that uses the Clarkson Packet Drivers.

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 90 22:17:52 GMT
From:      uwm.edu!cs.utexas.edu!jarvis.csri.toronto.edu!csri.toronto.edu!leemc@lll-winken.llnl.gov  (Matthew Lee)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP under MS-Windows
In article <972@ssp18.idca.tds.philips.nl>, michiel@idca.tds.PHILIPS.nl (Michiel Fierst van Wijnandsbergen) writes:
> Is there any one who has a TCP communication program working under MS-Windows?
...deleted...

I missed the original post and perhaps followups so I hope this is not redundant
information.

We haven't used it but Wollongong's most recent version (4.1) of 
"WIN/TCP for DOS" claims Windows compatibility and comes complete with PIF 
files. For more info:

		     Wollongong Canada
		     30 Dupont Street East.
		     Waterloo, Ontario
		     N2J 2G7
		     (519) 747-9900

This is by no means an endorsement of their product.

Matthew Lee      leemc@csri.toronto.edu
-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 90 00:38:04 GMT
From:      rrj@hpctdjl.HP.COM (Roger Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Trying to get email address Colorado State Univ.


  You might try postmaster@ccncsu.colostate.edu

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 90 01:09:13 GMT
From:      drilex!dricejb@bbn.com  (Craig Jackson drilex1)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use
In article <EMV.90Feb19161732@duby.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes:
>In article <UZs3N1200ioEM8f4Ma@andrew.cmu.edu> ms6b+@ANDREW.CMU.EDU (Marvin Sirbu) writes:

>> [That billing for use encourages conservation of 'scarce' resources.]

>One of the problems associated with billing for use is that is
>provides incentives to circumvent billing procedures, thus generating
>possible non-optimal behavior.  Consider a tax on anonymous FTP
>transactions; users will either find a way to make their anonymous
>FTPs look like something else (run an FTP daemon on the SUPDUP port,
>or hide it up in some un-numbered port) or turn to heavier use of
>mail-based servers and clog up already jammed mail queues.  Similarly,
>a tax on TCP services will induce people to use UDP even when it might
>be sub-optimal for use on their particular network.

Any billing system will lead to efforts to circumvent it.  However, if
the billing system is fair and reasonably secure, *most people* will
work with it, instead of against.  In your TCP vs UDP case, it wouldn't
make sense to bill for data bytes transmitted over TCP differently than
data bytes transmitted over UDP.  However, attaching a cost penalty would
certainly discourage bad TCP implementations.

>When you start to bill for use on a per-packet or per-connection
>basis, the Law of Unintended Consequences is bound to strike.  
>If you have naive or uneducated users, solve their inefficient
>use of the network through education, not a tax on their foolishness.

The Law of Unintended Consequences will occur in any situation.  But
no amount of education will work if the incentives are all against it.
(Face it.  Everybody's had at least one subject that they studied only
because it was required.  When I say required, that means that there
was some penalty attached to not doing so.)

I think that the idea that 'It is immoral to bill for use on networks'
is an idea which keeps large-scale networks in the research/sugar-daddy
world.  I've been formulating some ideas on this--I'll try to post
something concrete soon.
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 90 01:30:11 GMT
From:      zaphod.mps.ohio-state.edu!uwm.edu!bionet!hayes!wisner@tut.cis.ohio-state.edu  (Bill Wisner)
To:        tcp-ip@nic.ddn.mil
Subject:   gathering network statistics
I want to collect statistics about the packets passing through my
ethernet and summarize them by protocol and host involved. Is there
such a beast out there?

Bill Wisner <wisner@hayes.fai.alaska.edu> Gryphon Gang Fairbanks AK 99775
-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 90 02:29:19 GMT
From:      jarvis.csri.toronto.edu!torsqnt!hybrid!scifi!acheron!archet!larouch!yozzo@rutgers.edu  (Ralph Yozzo)
To:        tcp-ip@nic.ddn.mil
Subject:   Differences between SunOS NFS server and BSD 4.3
I am wondering how BSD 4.3 NFS differs from SunOS Unix
I know that the BSD 4.3 that I am using is using 
Program 100003 version 2  port 2049 protocol udp
(I got this information from a  rcpinfo -p <hostname>)



When I look at the rpcinfo -p <hostname> output
on SunOS Unix it shows the exact same thing.

10003 2 udp 2049 nfs

for program, version, protocol, port, binary


Yet the Sun's can restrict access to mounted file
systems to read only and the BSD NFS cannot.

I was wondering why BSD NFS cannot restrict access to read/only.

Is SunOS and BSD 4.3 really running the same server
and the only thing that is different is that the SunOS client
is smarter?


==Ralph E. Yozzo == 
==Arpanet: yozzo@ibm.com==
==Bitnet: yozzo@yktvmx.bitnet==
==Home: ..!uunet!bywater!acheron!larouch!yozzo ===Ph:(914)945-3634 or 564-4731
-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 90 10:52:00 PST
From:      Leo J McLaughlin <ljm@TWG.COM>
To:        tcp-ip <tcp-ip@nic.ddn.mil>
Subject:   Re: splitting tcpip

Craig,

>    It seems to me that increasingly the TCP-IP list is being filled with
>messages of the form "anyone know anything about product X?"...
>
>    Does anyone else out there think it might be useful to create
>a separate list for such requests and their answers?  (If you are afraid
>that by splitting off the product side, the questions won't get answered,
>I assure you that the vendors have a large interest in seeing product
>related questions answered, and given a vendor and its competitors are
>both on the list, an answer is likely to be accurate).
>

I'd much rather not, I'm much more afraid that by splitting this group I'll
have to sift through yet more double (triple?) postings.  The slope from
"How do you implement Van's..." to "Where can I get Van's..." to "Where
can I get X with Van's..." is annoyingly slippery.  It's enough that
tcpip, pc-ip, and NOVELL all exist.

Then again, just asking that all desktop TCP/IP productish questions be
posted only in pc-ip would probably please both of us.

enjoy,
leo j mclaughlin iii
ljm@twg.com



-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Feb 90 16:47:31 -0800
From:      mag%WLBR@WLV.IMSD.CONTEL.COM (Margaret Wahl)
To:        tcp-ip@NIC.DDN.MIL
Subject:   IP routers
Subject: IP routers

We are interested in adding an IP router to our existing network.  Currently,
we have a Class C (255 addresses) network, but will have to add another Class C
subnet shortly.  We will be running the new Class C network on the same cable
as the old Class C network, thus no need for a bridge/router today.  We are
investigating various methods.   Does anyone have any experience with the
following methods?  Comments/Suggestions?

1.  Use our gateway machine (Vax 11/750, Berkeley 4.3) as the router.  Add
    more memory to handle the load.

2.  Use a 286 or 386 PC with PCROUTE (a public domain program) - An IP routing
    program for the IBM PC.  (available from Vance Morrison, Northwestern U.)

3.  Use a Cisco, Proteon or Wellfleet router.


Thanks in advance.  Please send email replies to mag%wlbr@wlv.imsd.contel.com.

Maggie Wahl
mag%wlbr@wlv.imsd.contel.com
-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 90 04:00:30 GMT
From:      charyb!dan@uunet.uu.net  (Dan Mick)
To:        tcp-ip@nic.ddn.mil
Subject:   tcpdump
I've got a program called tcpdump, written by Van Jacobsen at Lawrence
Berkeley Laboratory, (mailadds supposedly van@lbl-csam.arpa or 
van@lbl-rtsg.arpa), that was distributed as compiled code for Sun-3 
workstations.  It's a really useful tcp packet-listener and dumper.

However:  I need a Sun-4 version pretty badly.  Does anyone know if
Van's still out there, how to reach those addresses from uunet,
if there's a Sun-4 version of tcpdump, if there's a tool like tcpdump
for the Sun-4, or any of that?

What I'm really trying to do is track down some problems using tcp on
a PC connected to the Sun-3, but apparently Sun's NIT won't track 
packets destined for the host upon which the program is running,
so I can only see half the story, as there's only one Sun-3 on this
net.  However, there's a Sun-4, so if I could run tcpdump on the
Sun-4, I could see traffic between Sun-3 and PC with no problem...

If anyone's got any better ideas than tracking down Van and tcpdump0,
I'm willing to listen, of course.

Oh, also, we're a SunOS licensee, so if anyone has diffs for tcpdump
(I understand it's derived from Sun's own etherfind), I could possibly
apply them to the source we have and generate my own tcpdump.

Any help much appreciated!
-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Feb 90 12:23:14 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   Correct SIGCOMM Dates

Hi folks:

    Due to a goof on my part, IEEE COMPUTER lists SIGCOMM '90 as being
in August -- that's not correct.  The proper dates are 24-27
September.  The conference is in Philly.

Craig

PS: Final reminder -- papers due March 2nd (that's a week from this
Friday).  Phil Karn (karn@thumper.bellcore) is the program chair.
-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Feb 90 19:34:37 -0800
From:      art@salt.acc.com (Art Berggreen)
To:        tcp-ip@nic.ddn.mil
Cc:        eckert@informatik.uni-erlangen.de
Subject:   Re: IP queuing for X.25 SVC's: congestion and performance problems.

In article <2452@medusa.informatik.uni-erlangen.de> eckert@medusa.informatik.uni-erlangen.de (Toerless Eckert) writes:
>Hi.
>
>I am experiencing some Problems with running IP on top of X.25 (RFC877).
>We are currently running IP over 64kpbs X.25 trunks, with a
>paket size of 128 byte, window size of 2( ;-() and a MTU of 576 byte.
>When unloaded the performance is around 3kbyte/sec and turnaround
>time is between 100msec and 200msec depending on the number of
>X.25 switches between the two sites.
>
>Now there are two problems:
>
>1. Why is the maximum throughput so low ? I understand that increasing the
>   paket size and especially window size on X.25 will increase it, and indeed
>   that happens, but tests showed that it will not go beyond 3.5kbyte/sec.
>   Has anyone observed better figures for this type of link ?
>   I have not been able to trace this problem down.

First, does the X.25 net enforce the packet window end-to-end?  If so, this
would explain a lot.  By fragmenting to 576 and using a 128 byte packet, the
IP datagram is sent as a 5 packet M-bit sequence.  All five pieces of this
sequence must reach the other end of the X.25 net and be reassembled before
the IP datagram can go on.  With a packet window of 2, less than 1/2 of one
IP datagram is in transit across the X.25 net at one time.  Since the
X.25 packet has to be received and resent by every X.25 switch along the
path, as soon as more than 2 X.25 links are traversed, you start losing.
Also, as soon as your TCP window piles up waiting to get across the X.25
link, it has to stop and wait for a packet to finally get to the other end,
generate an ACK and the ack get back across the X.25 net.  If there is
much data queued in front of the ack, it is also delayed, compounding the
problem.

>
>2. If the network geets more loaded, the paket turnaround times go up
>   to 30, 60 or even more seconds. This times are surely not reasonable.
>   From what i heve seen, this problems happens, because of a combination
>   of the following:
>   - the throughput on the SVC used for IP goes down, possible because
>     other SVC's use part of the bandwidth.
>   - The queues on the IP level and on the SVC level become very long.
>     
>   Now i really don't understand why one has to build up a long queue
>   on a link that is possible very slow. If one would use a much shorter
>   queue (possible down to 1 paket), the throughput could be still the
>   same, but the turnaround times (for those pakets who get through)
>   would be in a normal range.

Due to the window effects mentioned above, any extra delay in the X.25
packet switches just makes the problem worse.  Also, if the TCP does
not have the newer RTT estimation and slow-start logic, you can get into
congestion collapse behavior.

>   The special problem if a X.25 SVC as a provider for the IP link
>   is that the throughput on those SVCs may vary in a wide range,
>   from unloaded to nearly 0. In this case it could be advantageous to
>   measure the SVC throughput and change the queue length according
>   to throughput.
>
>   Am i wrong with my ideas - then what is the advantage of having
>   a long queue, when this only causes the turnaround times to
>   increase, but has not any effect on throughput.

Since IP is a datagram protocol, there is no natural backpressure
mechanism to tightly control queue depths in the IP switches. You
need intelligent transport protocols (e.g. slow-start TCP) to fix
the problem.

>   Any ideas about this ? What is the best way to handle those type of
>   links ? 
>-- 

The best way is to negotiate large X.25 packet sizes and windows
(1024/7 or bigger).  One thing that can help somewhat is to fragment
the IP packet to 128.  This causes a significant amount of more overhead
for IP header duplication, but allows the packets to keep on moving
once they get across the X.25 net.  One last possiblity is to have
multiple VCs open to the same destination and load balance.  This has
the side effect of potenially causing massive fragment reordering
which some machines have problems with.

>Toerless Eckert     Internet: eckert@informatik.uni-erlangen.de
> 		    X.400: /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=eckert/

+	Art Berggreen		Advanced Computer Communications	+
|	<art@salt.acc.com>	Santa Barbara Street			|
+	(805)963-9431		Santa Barbara, CA 93101			+
-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 90 09:52:16 GMT
From:      mcsun!sunic!sics.se!uplog.se!uplog.uplog.se!thomas@uunet.uu.net  (Thomas Tornblom)
To:        tcp-ip@nic.ddn.mil
Subject:   Minimum required datagram length
What is the minimum datagram length a router is required to handle without
fragmenting the datagram? I know there is a recommendation of 576 bytes
but how strict is it? I have a media that can't handle more than 512 byte
in one datagram, what is the canonical way to deal with it?

Znks,
Thomas
-- 
Real life:	Thomas Tornblom		Email:	thomas@uplog.se
Snail mail:	TeleLOGIC Uppsala AB		Phone:	+46 18 189406
		Box 1218			Fax:	+46 18 132039
		S - 751 42 Uppsala, Sweden
-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 90 13:06:18 GMT
From:      mcsun!unido!fauern!fauern!eckert@uunet.uu.net  (Toerless Eckert)
To:        tcp-ip@nic.ddn.mil
Subject:   IP queuing for X.25 SVC's: conqestion and performance problems.
Hi.

I am experiencing some Problems with running IP on top of X.25 (RFC877).
We are currently running IP over 64kpbs X.25 trunks, with a
paket size of 128 byte, window size of 2( ;-() and a MTU of 576 byte.
When unloaded the performance is around 3kbyte/sec and turnaround
time is between 100msec and 200msec depending on the number of
X.25 switches between the two sites.

Now there are two problems:

1. Why is the maximum throughput so low ? I understand that increasing the
   paket size and especially window size on X.25 will increase it, and indeed
   that happens, but tests showed that it will not go beyond 3.5kbyte/sec.
   Has anyone observed better figures for this type of link ?
   I have not been able to trace this problem down.

2. If the network geets more loaded, the paket turnaround times go up
   to 30, 60 or even more seconds. This times are surely not reasonable.
   From what i heve seen, this problems happens, because of a combination
   of the following:
   - the throughput on the SVC used for IP goes down, possible because
     other SVC's use part of the bandwidth.
   - The queues on the IP level and on the SVC level become very long.
     
   Now i really don't understand why one has to build up a long queue
   on a link that is possible very slow. If one would use a much shorter
   queue (possible down to 1 paket), the throughput could be still the
   same, but the turnaround times (for those pakets who get through)
   would be in a normal range.

   The special problem if a X.25 SVC as a provider for the IP link
   is that the throughput on those SVCs may vary in a wide range,
   from unloaded to nearly 0. In this case it could be advantageous to
   measure the SVC throughput and change the queue length according
   to throughput.

   Am i wrong with my ideas - then what is the advantage of having
   a long queue, when this only causes the turnaround times to
   increase, but has not any effect on throughput.

   Any ideas about this ? What is the best way to handle those type of
   links ? 
-- 

Toerless Eckert     Internet: eckert@informatik.uni-erlangen.de
 		    X.400: /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=eckert/
-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Feb 90 14:37:34 GMT
From:      Keith Mitchell <keith@spider.co.uk>
To:        Steve Simmons <scs@itivax.iti.org>
Cc:        tcp-ip@nic.ddn.mil, bind@ucbarpa.berkeley.edu
Subject:   Re: Use Domain In Hostname Or Not?

 scs%itivax%ox.com%umich%mailrus%cs.utexas.edu@tut.cis.ohio-state.edu
 (Steve Simmons) writes:

"... I'm interested in any and all comments on why or why not to set
hostname to FQDN...."    (FQDN = Fully Qualified Domain Name)


This is something I have found a bone of contention for a while.  In
theory it shouldn't make any difference if you are running BIND, as
the "domain" directive in /etc/resolv.conf (or /etc/named.boot ?)
should tack it on to any unqualified hostnames you enter. I think the
principle of always using FQDNs is a good one, provided you can have
this short-cut for user input. Naive users certainly don't want to
know about domains.

In practice, however, the implementations are never quite up to it.
For example:

- rshd does not appear to pick up the default domain as above.  So
you have to put a fully qualified name into your ".rhosts" or
"hosts.equiv" even if you're normally used to just the short name.
Ultrix V3 & SCO TCP/IP do this, but Excelan EXOS software gets it
right, and MIPS RISC/os 4.0 has a work-around.

- Some sendmails use the resolver library so that the "$w" (ie this
host's name) macro gets set to the FQDN, others just the basename.
This can lead to delightful behaviour such as:
"HELO redknee.spider.co.uk.spider.co.uk" if the sendmail.cf isn't
smart to it - I have yet to fix mine to get this right.  Here,
Ultrix gets it right, and RISC/os and SCO get it wrong.

Your comment "The vendor agrees their performance isn't correct.."
intrigues me, as in the face of the above diverse behaviour I'm
confused as to what the correct behaviour IS.  If anyone can throw
light on this, or what resolver calls are involved that produce the
above behaviour, I would be very keen to more. We would like to have
consistency in our sendmail.cf files, too.

Other FQDN problems I can think of would be clashes with Yellow
Pages, and the fact (minor one, this) that the domain qualification
can cause visual clutter in for example, "netstat" output. A output
option of "don't qualify hostnames" might be a nice way round this.
(Or how about "only qualify if it's not the local domain" ?)

Anyone else have experience of these ones ?

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@ukc.ac.uk



-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 90 17:23:14 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Correct SIGCOMM Dates


Hi folks:

    Due to a goof on my part, IEEE COMPUTER lists SIGCOMM '90 as being
in August -- that's not correct.  The proper dates are 24-27
September.  The conference is in Philly.

Craig

PS: Final reminder -- papers due March 2nd (that's a week from this
Friday).  Phil Karn (karn@thumper.bellcore) is the program chair.

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 90 18:00:10 GMT
From:      peter@orfeo.radig.de (Peter Radig)
To:        comp.unix.xenix,comp.protocols.tcp-ip
Subject:   Problems with TCP/IP and Xenix using a ix386 with 33 MHz

Does someone knows how to use TCP/IP under Xenix using a ix386 with
33 MHz???

I had the following configuration:

	Tandon AT386/33
	WD 8003 EtherCard Plus
	5 MB

	XENIX 2.3.2
	TCP/IP 1.0.0

When I try to boot from the kernel with TCP/IP linked the system
`autoboots' (i.e. it resets the system *before* any copyright or init
message is displayed).

When I set the HW setup to use only 8 MHz there is no problem any more...

Any hints?

Thanks a lot.
Peter
-- 
Peter Radig
Voice: +49 69 746972
USENET: peter@radig.de  or:  uunet!unido!radig!peter

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 90 21:12:09 GMT
From:      wuarchive!swbatl!uucigj@decwrl.dec.com  (3531)
To:        tcp-ip@nic.ddn.mil
Subject:   Location of slipware.tar?
I read the following in a README that came with a tar package for
slip-4.0.tar.Z (slip for sun 4.0):

- tip w/ slip.
	This is a new version of the BSD tip that supports SLIP dialout, login
	scripts, and new dialers (incl. TrailBlazer). This version will likely
	find its way into a future BSD release.

There were several other packages mentioned and this statement followed:

To save you running around to find these, a collective tar file will be
available at some archive locations under the name of slipware.tar.Z.
                                                      ^^^^^^^^^^^^^^
Does this (tip w/ slip) exist?  If so, could I get a archive site address?

      Gregg Jensen
   ---------------------------------------------------------------------- 
    These opinions are my own and do not necessarily reflect my companies.
      Southwestern Bell Telephone
      Send E-MAIL to the following address...
               ...!uunet!swbatl!uucigj
   ---------------------------------------------------------------------- 
-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 90 21:51:40 GMT
From:      lll-crg.llnl.gov!booloo@lll-winken.llnl.gov  (Mark Boolootian)
To:        tcp-ip@nic.ddn.mil
Subject:   background ftp source
Can some kind person please email the site from which I can obtain the
latest background ftp source.  As always, thanks in advance.
mb

booloo@lll-crg.llnl.gov
-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      WEDNESDAY, FEBRUARY 21, 1990      20:59  CET
From:      Ksoll%DB0TUZ01.BITNET@CUNYVM.CUNY.EDU
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Problem with Interactive's telnet

Hi,
we want to push a lovely application on top of telnet(1c) (maybe
ISO-OSI layer 8 ;-). Therefore we grab telnet's stdin and stdout
with pipe(2), fork(2), dup(2) and exec(2). This works fine on
Unicos, IRIX, DomainOS 10.1 and HP-UX 6.5. But it does not work
with Interactive's 386/ix-telnet 1.1.2. If I try to run telnet under
sdb, then telnet prompts in an endless loop. Is this a known bug?
Can I avoid it with a workaround? Is there source code available
so that we can fix it?
(I guess it smells like a nonblocking read(2) problem).
Thank you for your help.
Wolfgang Ksoll   Computer Center, Tech. Univ. Berlin(West), Germany
                 Ksoll@db0tuz01.bitnet

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Feb 90 11:23:54 -0800
From:      wrs!yuba!hwajin@uunet.UU.NET (Hwa Jin Bae)
To:        uunet!salt.acc.com!gaw%saturn.ACC.COM@uunet.UU.NET
Cc:        sun!decwrl!dcrocker@uunet.UU.NET, tcp-ip@nic.ddn.mil
Subject:   Re: UDP bind question
I'm not sure if AT&T publishes this spec for everyone.  My copy
is from the set that comes with Unix V.3.* source distribution 
documentation.  It's primarily intended for the Unix systems developers
and porting houses.  You should call up AT&T and ask them about it.

The title is _System V Porting Rules_.  I don't work with Unix anymore
so I can't give you the most up-to-date info on this.

hwajin
Wind River Systems
-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Feb 90 09:10:33 -0500
From:      James M Galvin <galvin@TIS.COM>
To:        Leo J McLaughlin <ljm@twg.com>
Cc:        tcp-ip <tcp-ip@nic.ddn.mil>
Subject:   Re: splitting tcpip
	Then again, just asking that all desktop TCP/IP productish questions be
	posted only in pc-ip would probably please both of us.

As the maintainer of the PCIP mailing list, I would like to be a bit more
precise about the use of the list.

The primary purpose of PCIP is not for discussing "low-end" TCP/IP products,
any more than the primary purpose of TCP-IP is for discussing "high-end"
TCP/IP products.  It is for the discussion of "low-end" TCP/IP, with specific
product discussions being allowed only in the context of a reply to a request
for information.

I am sure this is what Leo meant, but I wanted to make sure everyone else
understood it.  I am compelled to compliment Leo and James Van Bokkelen for
their fairness in responding to information queries on PCIP.  They both
habitually identify products in addition to their own that satisfy queries.

Jim

PS.  The list is "pcip@udel.edu", with the usual administrivia address of
"pcip-request@udel.edu".  It is also gatewayed to BITNET and USENET, as
"pcip-l@vm.byu.edu" and "comp.protocols.tcp-ip.ibmpc (??)", respectively.
-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Feb 90 09:34:51 PST
From:      Sol Lederman <SOL@NIC.DDN.MIL>
To:        eru!luth!sunic!mcsun!ukc!acorn!tenset!colin@bloom-beacon.mit.edu
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Anyone know an online source of IEN documents
Colin,

The IEN documents are available on the NIC.DDN.MIL host in the IEN: directory.
To get an IEN by e-mail, send a message to SERVICE@NIC.DDN.MIL and in the
subject line put the string    IEN x    where x is the number of the IEN you
want. You can only request one IEN per message.

To get an IEN index put the string    IEN INDEX    in the subject line.

-Sol/NIC
-------
-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 90 01:56:49 GMT
From:      bigbroth@babcock.cerc.wvu.wvnet.edu (James M. Coleman)
To:        comp.protocols.tcp-ip
Subject:   Re: tcpdump

From article <370@charyb.COM>, by dan@charyb.COM (Dan Mick):
> I've got a program called tcpdump, written by Van Jacobsen at Lawrence
> Berkeley Laboratory, (mailadds supposedly van@lbl-csam.arpa or 
> van@lbl-rtsg.arpa), that was distributed as compiled code for Sun-3 
> workstations.  It's a really useful tcp packet-listener and dumper.
> 
> However:  I need a Sun-4 version pretty badly.  Does anyone know if
> Van's still out there, how to reach those addresses from uunet,
> if there's a Sun-4 version of tcpdump, if there's a tool like tcpdump
> for the Sun-4, or any of that?

 There is a fix for the SunOS 4 at the same site the main program is stored.
If you need the internet address email and I'll send it. SunOS version 4
uses a new version of the Network Interface Tap (NIT) and this is why
you are having problems. There is example code in the Sun manuals, I believe
it is under nit or etherfind. By the way, you have to have root privledge
to open the nit.

                                            Jim Coleman
                                     bigbroth@cerc.wvu.wvnet.edu

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 90 02:35:01 GMT
From:      GMoretti@massey.ac.nz (Giovanni Moretti)
To:        comp.protocols.tcp-ip
Subject:   Re: background ftp source

> Re background FTP source

I'm interested in this also.  I remember seeing an someone offering to supply
it, but at the time, it was not of interest. Now that it is ...  :-(

The one I'm thinking of does repeated retries if it can't get in.  Does
anyone recognise this?

Thanks
Giovanni

-- 
-------------------------------------------------------------------------------
|   GIOVANNI MORETTI, Consultant     | EMail: G.Moretti@massey.ac.nz          |
|Computer Centre,  Massey University | Ph 64 63 69099 x8398, FAX 64 63 505607 |
|   Palmerston North, New Zealand    | QUITTERS NEVER WIN, WINNERS NEVER QUIT |
-------------------------------------------------------------------------------

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Feb 90 16:09:10 -0800
From:      simpson%saturn@ind.TRW.COM (Scott Simpson)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for SNA<->TCP/IP gateway
The subject line says it all.  Does anybody know of such a beast?
-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 90 02:50:04 GMT
From:      davison@uhnix2.uh.edu (Daniel B. Davison)
To:        comp.protocols.tcp-ip
Subject:   CMU Telnet doesn't...in, but does going out.  ???

I recently installed CMU TCP/IP on a Microvax II, running VMS
4.7, CMU version 6.3 (I think-anyway, it was the last version that
didn't require VMS 5.0).

Most everything works fine, except for telnet, going INTO the machine.
Telnet working going out and FTP works, etc.  So the problem appears
to be in the pty driver.  The PTY driver has been installed, device
PYA0: is present, although SYSGEN (I think) comments that the device
is a "template only".  AUTOGEN and SYSGEN both work and say they find
everything they are supposed to find.

So, can anyone shed some light on what is wrong here?

Thanks in advance,
dan
---
dr. dan davison/dept. of biochemical and biophysical sciences/univ. of
Houston/4800 Calhoun/Houston,TX 77054-5500/davison@uh.edu/DAVISON@UHOU

Disclaimer: As always, I speak only for myself, and, usually, only to
myself.

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Feb 90 10:38:59 EST
From:      munnari!toshiba.tic.oz.au!safdar@uunet.UU.NET (Safdar Faghani)
To:        TCP-IP@NIC.DDN.MIL
Subject:   TCP/IP SOURCE CODE

   Dear sir
 I was advised by somebody from NIC that it is possible to get TCP/IP source code from you.
We are developing our own hardware(intel80186 cpu),this ethernet board will be inserted to Multi Bus II chase,and must communicate with Sun 386i.
Please let us know, the requirments for getting full implementation of TCP/IP source code.

Regards, Safdar Faghani


=========================================================
= Safdar Faghani	ACSnet:	safdar@toshiba.tic.oz	=
= Toshiba International Cop.  Phone:	61-2-428-2077	=
= Sydney, Australia	Fax:	61-2-427-7405		=
=========================================================
-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Feb 90 13:41:48 EST
From:      gaw%saturn.ACC.COM@salt.acc.com (...Glen............)
To:        sun!decwrl!dcrocker@uunet.uu.net, wrs!yuba!hwajin@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP bind question
Where could I find a specification on TPI?

Thanks,
Glen Warholic
Advanced Computer Communications
gaw@mercury.acc.com
-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Feb 90 12:58:19 EDT
From:      Steve Simmons <scs@vax3.iti.org>
To:        keith@spider.co.uk (Keith Mitchell)
Cc:        scs@itivax.iti.org, tcp-ip@nic.ddn.mil, bind@ucbarpa.berkeley.edu
Subject:   Re: Use Domain In Hostname Or Not?
> scs%itivax%ox.com%umich%mailrus%cs.utexas.edu@tut.cis.ohio-state.edu
> (Steve Simmons) writes:
>
>"... I'm interested in any and all comments on why or why not to set
>hostname to FQDN...."    (FQDN = Fully Qualified Domain Name)
 . . .
>In practice, however, the implementations are never quite up to it.
>For example: . . .

>Your comment "The vendor agrees their performance isn't correct.."
>intrigues me, as in the face of the above diverse behaviour I'm
>confused as to what the correct behaviour IS.  If anyone can throw
>light on this, or what resolver calls are involved that produce the
>above behaviour, I would be very keen to more.

In this vendors case, we can make the system hang 100% reliably by
using unqualified names in the right circumstances.  The workarounds
(which do work, thank god!) require going 180 degrees to the vendors
and UCBs bind documentation on some points.  The vendor agrees the
documentation is correct, the performance incorrect.

To summarize the responses to my original item:

Almost everyone said we should go to FQDNs even though they were not
strictly required; the remainder claimed they were strictly required.
This requires rebuilding our sendmail.cfs :-( our news files :-( our
hosts files :-( our host.equiv files :-( . . . well, you get the idea.

In addition, there is one *major* problem with this: many
implementations allow a very limited size for the host name -- twelve
and sixteen characters are the sizes most often cited.  We have some of
these systems in-house, mercifully we also have short fqdns on almost
all systems (foo.iti.org).

The problems we have with unqualified host names seem to be surfacing
because so few sites use them in a true DNS enviroment.  As such, the
software for lots of packages has never been as thoroughly exercised in
this area and we are the 'first discoverers' of bugs (remember the
early days of intermixing YP and DNS?  That uncovered a lot of
previously unknown bugs).  Since many of our systems are from
proprietary vendors, we've decided to bite the bullet, make the changes
to all the things above, and get in step with the rest of the world.
Many thanks to all for the advice.

Steve
-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 90 09:04:30 GMT
From:      eru!luth!sunic!mcsun!ukc!acorn!tenset!colin@bloom-beacon.mit.edu  (Colin Manning)
To:        tcp-ip@nic.ddn.mil
Subject:   Anyone know an online source of IEN documents

Does anyone know where I can obtain on-line copies of IEN specs.

Or failing that, a postal address.

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.          |
-----------------------------------------------------------------------
-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 90 19:11:36 GMT
From:      lll-crg.llnl.gov!booloo@lll-winken.llnl.gov  (Mark Boolootian)
To:        tcp-ip@nic.ddn.mil
Subject:   ftp source

    Thanks to those who pointed me at the source for background ftp (available
on venera.isi.edu).  I also am in need of source for the ftp daemon.  I would
like either the BSD4.3 or Tahoe version (these are different, aren't they?).
Thanks again and sorry for not asking for this with my bftp request.
mb

booloo@lll-crg.llnl.gov			 "Careful with that ack, Eugene"
-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Feb 90 00:39:37 est
From:      Karl Owen <owen@DG-RTP.DG.COM>
To:        scs@VAX3.ITI.ORG
Cc:        keith%spider.co.uk@RELAY.CS.NET, tcp-ip@NIC.DDN.MIL, bind@UCBARPA.BERKELEY.EDU
Subject:   Re: Use Domain In Hostname Or Not?
> From: Steve Simmons <scs@vax3.iti.org>
> Subject: Re: Use Domain In Hostname Or Not?
> To: keith@spider.co.uk (Keith Mitchell)
> Date: Thu, 22 Feb 90 12:58:19 EDT
> Cc: scs@itivax.iti.org, tcp-ip@nic.ddn.mil, bind@ucbarpa.Berkeley.EDU
> 
> > scs%itivax%ox.com%umich%mailrus%cs.utexas.edu@tut.cis.ohio-state.edu
> > (Steve Simmons) writes:
> >
> >"... I'm interested in any and all comments on why or why not to set
> >hostname to FQDN...."    (FQDN = Fully Qualified Domain Name)
>  . . .
> 
> To summarize the responses to my original item:
> 
> Almost everyone said we should go to FQDNs even though they were not
> strictly required; the remainder claimed they were strictly required.
> This requires rebuilding our sendmail.cfs :-( our news files :-( our
> hosts files :-( our host.equiv files :-( . . . well, you get the idea.

I'm not sure that I agree with this.  We should be able to live with
unqualified names as shortcuts.  The burden belongs on the systems
implementors, not on the users.

For example, a simple library routine can be used to strip most of the
clutter from netstat and to allow rshd and rlogind to recognize local
parts of domain names.  The routine looks up the domain part of the FQDN
by doing a gethostbyname() on the result of gethostname().  It can then
compare the domain part to the domain part of any FQDN and strip the
domain part if appropriate.

Karl

--

	Karl M. Owen			owen@dg-rtp.dg.com
	Data General, RTP, NC		...!mcnc!rti!xyzzy!owen

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 90 20:45:30 GMT
From:      charyb!dan@uunet.uu.net  (Dan Mick)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcpdump
In article <370@charyb.COM> I (uunet!charyb!dan) wrote:

>I've got a program called tcpdump, written by Van Jacobsen at Lawrence
>Berkeley Laboratory, (mailadds supposedly van@lbl-csam.arpa or 
>van@lbl-rtsg.arpa), that was distributed as compiled code for Sun-3 
>workstations.  It's a really useful tcp packet-listener and dumper.
>
>However:  I need a Sun-4 version pretty badly.  Does anyone know if
>Van's still out there, how to reach those addresses from uunet,
>if there's a Sun-4 version of tcpdump, if there's a tool like tcpdump
>for the Sun-4, or any of that?

Greg Earle has kindly informed me that SunOS 4.x's etherfind has most
of the tcpdump stuff incorporated under its -v(erbose) option.  It 
certainly does.  THANKS, Greg!  

	The way it reached me:  
	uunet!poseur.jpl.nasa.gov!earle

	From Greg's .sig:
	earle@poseur.JPL.NASA.GOV	(direct)
	earle@Sun.COM			(indirect)
-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 90 22:42:57 GMT
From:      snorkelwacker!spdcc!ima!haddock!news@tut.cis.ohio-state.edu  (overhead)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP queuing for X.25 SVC's: conqestion and performance problems.
In article <2452@medusa.informatik.uni-erlangen.de> eckert@medusa.informatik.uni-erlangen.de (Toerless Eckert) writes:
>I am experiencing some Problems with running IP on top of X.25 (RFC877).
It sounds as though you are running with the D-bit (delivery
confirmation bit) set.  If so, you might consider if you really need
end-to-end confirmation.  Let the DCE do your buffering for you.

Just because you have a 64kb line to the first DCE doesn't necessarily
mean that that all links to the destination DTE are running at that
speed.  Is the Throughput Class facility meaningfully implemented by
your PDN?

A packet size of 1024 should be the optimal size for an MTU of
576.  A window size of two should be OK if you run without The D-bit
set, otherwise run with a window of seven (or larger if extended
packet sequence numbering is supported).

If your IP and SVC queues are getting very long, it appears that your
implementation has a flow control problem.  You haven't said anything
about your environment, so I can't comment any more on this area.

Jim
-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Feb 90 08:33:37 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        Toerless Eckert <eckert@faui43.informatik.uni-erlangen.de>
Cc:        tcp-ip@nic.ddn.mil
Subject:   re: IP queuing for X.25 SVC's: conqestion and performance problems.

Running IP over X.25 is a notoriously tricky business.  Here are the
two pieces of wisdom I can offer from my limited experience with the
CSNET IP over X.25 driver.

One question is why the queue size ever gets so large.  Are the TCPs
not doing slow-start?  Does the queue never ever drop packets?  Something
sounds odd about the dynamics here.

The other item is a suggestion.  There are cases where there's simply
more traffic that wants to be sent that there is bandwidth over one
X.25 connection to send it.  The CSNET driver had a feature where it
would open additional connections when the queue got large (up to,
I think 6 parallel connections).  There was some simple code to
estimate cost-benefit so connections would close down later if there
wasn't enough bandwidth to justify keeping them open.

Craig
-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 90 01:08:19 GMT
From:      mcsun!sunic!kth.se!draken!perand@uunet.uu.net  (Per Andersson)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP on unix-systems
Hello.

I'm trying to figure out how to make a ethernet to SLIP gateway out of a
Sparcstation. I've done it with a MS-DOS PC and KA9Q, which just requires
defining the network interfaces, and saying 'that IP-adress is behind me,
i'll take the packet'. Thist is called arp publish. Although I have been
reading documentation on gated ( newest possible ), and proxyarpd I haven't
found out exactly how to do it. I'm hoping someone on the net already has 
done this ?
Oh yes, I must mention that I do not want to allocate a subnet for this single 
SLIP-system. And until now I haven't had a reason to run either routed or
gated.

Please respond either by news or by mail, in which case I will make a 
summary, if interest is shown by anyone.

Per
-- 
---
Per Andersson
Royal Institute of Technology, Stockholm, Sweden
perand@admin.kth.se, @nada.kth.se 
-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 90 03:12:06 GMT
From:      imagen!atari!portal!portal!cup.portal.com!John_Robert_Breeden@ucbvax.Berkeley.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   Re: DOS & UNIX ethernet board wish list (was Re: TCP/IP over St
>    a) under UNIX Sys V/386 Rel 3.2.2 on a 6386:
>       *  uucp
>       *  tcp/ip
>       *  NFS or RFS
>       *  etc.
 
>    b) under MS-DOS 3.30 or 4.01, also on a 6386:
>       *  PC-NFS   (or, FTP Software's PC/TCP will do in a pinch)
>       *  Novell NetWare  (I can live without this, but it'd be nice)
 
>A couple of 3Com cards come close - they are supported for PC-NFS and
>for UNIX use under 386/ix or SCO (but not AT&T).  The AT&T Micom/
>Interlan hardware for UNIX won't work with the DOS needs, nor will
>the EN100/Wollongong combo, as far as I know.  (Plus, the Informix
>I-NET products are only ported to the Micom combo so far).
 
Back to the AT&T EN100 board, it is EXACTLY the same interface as the
TP board (NAU). FTP writes a driver for their PC/TCP (you want FTP
Release 2.04 - I don't know if AT&T is shipping it, but you can get
it direct from FTP, the driver that supports the NAU also supports
the EN100 - that takes care of the DOS side.
 
As far as Unix goes, the WIN/386 DOES run on the EN100. Quoting AT&T
document "Announcement odf AT&T's Enhanced TCP/IP WINN/386 Release 3.0
for 6386WGS Computers" is the following:
 
"Specifications
 
The software requires AT&T UNIX System V Release 3.1 or 3.2 along with
WIN/386 TCP/IP software and 386 NI software on a 6386 computer, you must
have one of the following StarLAN 10 Network NAU hardware:
 
1. EN100 NAU
 
2. PC NAU 
 
The 386 NI software provides the software interface between TCP/IP WIN/386
software and the StarLAN 10 Network NAU hardware on the 6386 computer. This
interface is included in the WIN/386 TCP/IP package. "
 
The PEC CODE (Order Code) for the product is 1274-TH1. Comcode 106019185
for 3.5" disks and Comcode 106019177 for 5.25" disks. Th price is $495.00.
 
I suspect the difference is Woolongong supplies "WIN/386" while AT&T 
supplies "Enhanced WIN/386", the "Enhanced" may be the streams drivers
for the EN100 - but don't quote me on it.
 
NFS for the Enhanced WIN/386 V.3 is a seperate product. It's called
"NFS Release 1.1 for the 6386, it requires either an EN100 NAU or 
PC NAU and Enhanced WIN/386 V.3. The PEC Code is 1274-NA1 and has a 
price of $395.00
 
Hope this helps.
 
john_robert_breeden@cup.portal.com
-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 90 05:29:40 GMT
From:      mcdchg!laidbak!stevea@rutgers.edu  (Steve Alexander)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP bind question
In article <9002201904.AA04950@yuba.WRS.COM> hwajin@yuba.UUCP (Hwa Jin Bae) writes:
>Pretty much the only difference, if any, that exists between various
>implementations has to do with the name of the STREAMS device you 
>open via TLI to get a TCP STREAM or any other protocol STREAM.  One
>other prevalent and possible difference seems to be the address
>binding semantics.  Beyond these, there are *NOT* that many differences.

You missed the worst one of all.  Options management.  Most vendors use
sockaddr_in for TCP & UDP addresses, but everybody has a different option
format.  Still, I agree that it's probably easier to port TLI applications 
between systems than socket applications, if for no other reason than that 
no two vendors can agree on where the header files go.

The bottom line is that AT&T should have defined protocol bindings for TLI,
or at least put pressure on vendors of UNIX System V add-on packages to be
more compatible with each other.

It'll probably be even worse when OSI implementations start proliferating, 
since there isn't even a reference standard like there was for UNIX TCP/IP
implementations (at least not until 4.nBSD comes out, if then).

--
Steve Alexander, Software Technologies Group    | stevea@i88.isc.com
INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea
-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 90 13:33:37 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: IP queuing for X.25 SVC's: conqestion and performance problems.


Running IP over X.25 is a notoriously tricky business.  Here are the
two pieces of wisdom I can offer from my limited experience with the
CSNET IP over X.25 driver.

One question is why the queue size ever gets so large.  Are the TCPs
not doing slow-start?  Does the queue never ever drop packets?  Something
sounds odd about the dynamics here.

The other item is a suggestion.  There are cases where there's simply
more traffic that wants to be sent that there is bandwidth over one
X.25 connection to send it.  The CSNET driver had a feature where it
would open additional connections when the queue got large (up to,
I think 6 parallel connections).  There was some simple code to
estimate cost-benefit so connections would close down later if there
wasn't enough bandwidth to justify keeping them open.

Craig

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 90 15:16:37 GMT
From:      snorkelwacker!spdcc!ima!haddock!news@tut.cis.ohio-state.edu  (overhead)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Anyone know an online source of IEN documents
In article <294@tenset.UUCP> colin@tenset.UUCP (Colin Manning) writes:
>
>Does anyone know where I can obtain on-line copies of IEN specs.
>
They are available via anonymous FTP from nic.ddn.mil, in the same way
as RFCs.  They may also be available from service@nic.ddn.mil via
email.  Use IEN INDEX as your subject.

Jim
-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 90 16:37:17 GMT
From:      daffy!rt4.cs.wisc.edu!horn@speedy.wisc.edu  (Mark Horn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Scorecard
In article <873@umabco.UUCP> lwilson@umabco.UUCP (Lowell G. Wilson) writes:
>now that I have a use for the things I can't find them anywhere!  These
>scorecards were in the form of a matrix and they listed certain TCP/IP
>functions across the top and various PC TCP implimentations across the
>side.  I could really use those matrices now so if someone could mail me
>a copy, I'd appreciate it.  Thanks in advance...

I'm interested in this, too.  Perhaps whoever has these could mail me a copy
too.  Either that or a re-post is in order . . .

- sparkie
--
 ___  ___  ___  ___  _  _  _  ___
/ __\| . \/ . \| . \| |/ /|_|| _ |	harier!sparkie@cs.wisc.edu
\___\| __/|   || _ /|   < | || _[	sparkie@uhura.cs.wisc.edu
\___/|_|  |_|_||_|\\|_|\_\|_||___|	mark.horn@mail.admin.wisc.edu
-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 90 21:46:34 GMT
From:      wang!fitz@uunet.uu.net  (Tom Fitzgerald)
To:        tcp-ip@nic.ddn.mil
Subject:   Many logical nets on a single physical net
Is it possible to have a single Ethernet with multiple IP network addresses
on it, and get the separate IP nets talking to each other?  Especially, is
it possible to do this cheaply?

We've got a number of separate Ethernets, with separate IP addresses, that
we want to connect together.  In the long run, as traffic rises (and
equipment becomes available) we'll be putting in proper gateways where
they look necessary.  But we want to get the machines on the various nets
talking to each other ASAP.

We don't want to renumber all the IP addresses, since we'd just have to
change them back when we started isolating the various nets with gateways.
And it may be some time before we can get all the gateways in place.

The ideal solution from our point of view would be a "gateway" with a single
interface and many IP addresses for it.  It would accept all inter-net
packets from all logical nets, and send them back out again, as-is, on the
same wire, to the right final destination.  Are there any gateways or
routers that are capable of this?  All the ones I have specs on assume that
interfaces map one-to-one with logical nets.

If there aren't any machines like this, what's the least we could do to get
this working?  Any and all info appreciated.

---
Tom Fitzgerald   fitz@wang.com
Wang Labs        ...!uunet!wang!fitz
Lowell MA, USA   1-508-967-5278
-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 90 21:48:07 GMT
From:      zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!csource!david@tut.cis.ohio-state.edu  (David Nugent)
To:        tcp-ip@nic.ddn.mil
Subject:   Ethernet driver needed

 
Does anyone have a good, working ethernet driver for SCO Xenix/386 
ICS or AT&T Unix/386 for which source is available, PD or otherwise?

 
david

--  
_________________________
 Unique Computing Pty Ltd
     UUCP: ...!munnari!csource!david
  FidoNet: 3:632/348
 Internet: david@csource.oz.au
-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 90 22:59:26 GMT
From:      pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari!uflorida!haven!ncifcrf!nlm-mcs!usenet@tut.cis.ohio-state.edu  (usenet news poster)
To:        tcp-ip@nic.ddn.mil
Subject:   Directed broadcasts??
Would someone please outline how to perform a directed broadcast--
that is, a broadcast to a net located one or more hops away?
Are there severe limitations or restrictions on the use of directed
broadcasts, such that directed broadcasts are impractical?  e.g.,
are routers usually configured to block off-site broadcast packets?

Any source code examples would be greatly appreciated.

BTW: the reason for asking this question (aside from my naivety) is
that I am investigating providing network services on machines whose
network identities may change (although the subnet probably wouldn't);
and I'd like to avoid having to update potentially thousands of
distributed copies of client applications when these changes do occur.
I'd be very interested if perhaps y'all have some better suggestions
than directed broadcasts.

Warren Gish
National Center for Biotechnology Information
National Library of Medicine
gish@ncbi.nlm.nih.gov
-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 90 23:27:47 GMT
From:      brutus.cs.uiuc.edu!wuarchive!swbatl!uucigj@lll-winken.llnl.gov  (3531)
To:        tcp-ip@nic.ddn.mil
Subject:   A login shell called sliplogin?
Once again while reading a readme file that accompanied the tip with slip
program, I found a paragraph that mentioned :

related to this enhanced tip is the program "sliplogi" which will act as 
a login shell for an incoming dialup slip connection.
It provides a level of authentication and control of address
assignment.  It can also be used to configure an arbitrary port
if invoked by the superuser.  Sliplogin is not in this directory
(tip) but is expected to be released in parallel.

Has this been released? does anyone know of the wherabouts?  This sounds
like it would fit my needs to a tee and any help would be appreciated.


      Gregg Jensen
   ---------------------------------------------------------------------- 
    These opinions are my own and do not necessarily reflect my companies.
      Southwestern Bell Telephone
      Send E-MAIL to the following address...
               ...!uunet!swbatl!uucigj
   ---------------------------------------------------------------------- 
-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 90 06:24:33 GMT
From:      barmar@think.com  (Barry Margolin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcpdump
In article <372@charyb.COM> dan@charyb.UUCP (Dan Mick) writes:
>Greg Earle has kindly informed me that SunOS 4.x's etherfind has most
>of the tcpdump stuff incorporated under its -v(erbose) option.  It 
>certainly does.  THANKS, Greg!  

Etherfind is certainly better than nothing, and I use it quite a bit these
days because so many of our systems are Sun-4's, but it's nowhere near as
good as tcpdump.  It doesn't do any decoding of NFS or Appletalk packets,
for instance, and it doesn't translate port numbers to service names.  It
doesn't have as good a filter-specification language; for instance, tcpdump
allows you to specify "port 2049" as an abbreviation for "(srcport 2049 or
dstport 2049)".
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 90 10:06:14 GMT
From:      mcsun!ukc!axion!planet!mpw@uunet.uu.net  (Michael Wood)
To:        tcp-ip@nic.ddn.mil
Subject:   PC X server ( over SLIP )

I have a 386 PC with an 3 Com card in for use when networked but when the
machine is remote is there any way of using a X server ( X-sight, X-view ) with
SLIP drivers rather than the 3 Com card ?

Mike.

+--------Email---------+-------Snail mail----------+-------voice--------+
|                      |  M.P.Wood (RT5112)        |                    |
| mpw@planet.bt.co.uk  |  BTRL (Martlesham Heath)  |  Tel.0473-642949   |
|                      |  Ipswich,                 |                    |
|                      |  Suffolk.  IP5 7RE        |                    |
+----------------------+---------------------------+--------------------+
-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 90 13:59:24 GMT
From:      mcsun!unido!orfeo!peter@uunet.uu.net  (Peter Radig)
To:        tcp-ip@nic.ddn.mil
Subject:   Why does `syslog - openlog' not work with Sendmail and 386/ix
Recently I got Sendmail 5.61 together with IDA 1.2.8. Now I'm porting
this to Interactive 386/ix.

Now the problem is: The call of `openlog' in `main.c' blocks the
process for a reason I do not know.

`logger' and all other programs that call 'syslog', etc. work quite well.
A short program (calls openlog with the same parameters as sendmail does)
also works.

The backtrace is:
	getmsg()
	sockack()
	socket()
	openlog()
	main()

Can you help me?

Thanks
Peter
-- 
Peter Radig
Voice: +49 69 746972
USENET: peter@radig.de  or:  uunet!unido!radig!peter
-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 90 01:30:34 GMT
From:      shelby!ack.Stanford.EDU!pst@rutgers.edu  (Paul Traina)
To:        tcp-ip@nic.ddn.mil
Subject:   How to SLIP without subnets (was SLIP on unix-systems)
perand@nada.kth.se (Per Andersson) writes:
>I'm trying to figure out how to make a ethernet to SLIP gateway out of a
>Sparcstation. ...

>Oh yes, I must mention that I do not want to allocate a subnet for this single 
>SLIP-system. And until now I haven't had a reason to run either routed or
>gated.

1.	there is a file called slipware.tar.Z on neat.cs.toronto.edu which
	provides slip support for SunOS 4 and its horrible streams.
1a.	Van Jacobson's header compression software (including mods)
	is out in beta test.  You may FTP that from rtsg.ee.lbl.gov
	(the file is called cslipbeta.tar.Z).

Now for the fun part.  You want to run SLIP to a machine without taking
up an entire subnet.  I can't think of a reasonable way to do that, _but_
you can still cheat.

If you just wanted to hook up one host, you can do it by allocating 4 IP
addresses in succession (the first IP address should be on a multiple of 4
boundary).

Here is an example that will be real sometime next week.  At work, I have
ack which is a sparcstation running sunos4.  At home, I have another machine
called nak.  Since I only want to gateway to one host, I allocate a 2-bit
subnet (4 network addresses).

Example:
	36.21.0.158	ack.Stanford.EDU	  (IP address of gateway enet)

	36.21.0.244	ack-nak-network		  (this is the "0" address)
	36.21.0.245	ack-slip		  (slip port on gateway)
	36.21.0.246	nak.Stanford.EDU nak-slip (slip port on home machine)
	36.21.0.247	ack-nak-broadcast	  (this is the "255" address)

I then ifconfig ack's slip line with a tiny netmask:

	ifconfig sl0 ack-slip nak-slip netmask 0xfffffffc

Now for the kicker: since we don't run RIP, just proxy-arp for the addresses
that the gateway deals with directly:

	# find out ethernet address -- a kludge but I was being lazy...
	#
	etheraddr=`dmesg | grep "Ethernet address" | awk '{ print $4 }'`
	#
	# proxy-arp for all addresses we're really taking ourselves.
	#
	for host in [ ack-nak-network ack-slip nak-slip ack-nak-broadcast ]
	do
	    arp -s $host $etheraddr pub
	done

(you may have to use ip addresses if your arp was broken like mine).

While this isn't the greatest way of doing things (broadcast traffic could
get messy) it works well enough.

The general idea is courtesy of Charles Carvalho of ACC in Santa Barbara.  Any
mistakes made in the presentation are my fault.

				Cheers and let me know how things
					work for you,
						Paul
-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 90 03:18:33 GMT
From:      pacbell!rtech!wrs!yuba!hwajin@ames.arc.nasa.gov  (Hwa Jin Bae)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for SLIP optimization diff's
Can anyone send me the latest diff's of VJ's if_sl.c vs. Tahoe if_sl.c?

Thanks much.
Hwa Jin Bae (hwajin@wrs.com)
Wind River Systems
-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 90 13:03:07 GMT
From:      rzi@sposp1.UUCP (Roman Zielinski)
To:        comp.protocols.tcp-ip,comp.protocols.nfs,comp.protocols.iso
Subject:   Gateway ISO8073 Cl4 <-> IEEE802 TCP

???:	HOW TO CONNECT TP4 AND TCP/IP NETS    :???
	----------------------------------

	I  need  make  our  Unix-V.2-like  680x0-system  network using
	OSI/TP4 (but not TCP/IP) to support such nice things as:  NFS,
	RFS, TELNET, Rlogin,  Remote Proc  Call so  they can cooperate
	with  another  680x0-systems  run  under  V.3(V.4)  supporting
	TCP/IP (but not TP4).

	There is another  system-family (a  386-based) that fortunately
	supports both TP4 and TCP.

	An idea I have, is to add a gateway system  converting TP4 <->
	TCP, and then write a "black  box" leyer  between NFS, Telnet,
	...,  and TP4:


	+-----+   +--------+                                   +--------------+
	! NFS !...! Rlogin !                                   ! NFS...Rlogin !
	+-----+---+--------+       +-------------------+       !              !
	! black box appl   !       ! Gateway +         !       !              !
	! conv TP4/TCP     !       ! conv    TCP/TP4   !       !              !
	+------------------+       +----------+--------+       +--------------+
	! ISO 8073 Cl4     !       ! 8073 Cl4 ! TCP    !       ! TCP          !
	+------------------+       +----------+--------+       +--------------+
	! 'Ethernet'       !-------! Eth.     ! Eth.   !-------! Eth.         !
	+------------------+	   +----------+--------+       +--------------+

	system in						system in
	OSI-network		     Gateway (386)		TCP/IP-network


	Questions:

1.	Is it possible to translate TCP/IP <--> ISO8073 Cl4?

2.	Is it easy to write a "black-box" and Gateway session layer programs?
	Or maybe it exists somewhere????

3.	Will NFS, Rlogin,... be satisfied by such an arrangement?


			Greetings from Sweden having green-house climat!
				
+---------------------------------+-------------------------------------------+
! Roman M. Zielinski		  ! <here should be something wise...>	      !
! Philips Tele & Data System AB   ! <but there is not>			      !
! S-115 84 Stockholm, Sweden	  !					      !
! tel +46 8 782 1373	          !					      !
! uunet!mcsun!sunic!sposp1!rzi    !					      !
+---------------------------------+-------------------------------------------+

Things are always at their best in the beginning. /Pascal

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 90 20:59:56 GMT
From:      hpda!hpcupt1!hpindwa!raj@ucbvax.Berkeley.EDU  (Rick Jones)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for SNA<->TCP/IP gateway

While it might say it all to some ;-)

Could you be a bit more specific - do you want SNA on top of TCP/IP, or
TCP/IP on top of SNA, or perhaps something else entirely?

rick jones
-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 90 23:42:30 GMT
From:      van-bc!sl@ucbvax.Berkeley.EDU  (Stuart Lynne)
To:        tcp-ip@nic.ddn.mil
Subject:   Xenix / NFS

We're looking for NFS under Xenix. Does anyone have this available yet?

-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Feb 90 09:40:15 -0500 (EST)
From:      Walter Lloyd Wimer III <ww0n+@andrew.cmu.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Proteon p4200

Could some kind soul please refresh my memory on the loopback packet
sent by Proteon p4200 gateways?  As I remember, this packet contains an
intentional CRC error.  At what rate are these sent?  Our p4200 is
sending ethernet packets which have *both* the source and destination
ethernet address set to 02:07:01:00:00:00 (notice all the zeros).  Is
this "normal"???  The ethernet address of the associated interface is
supposed to be 02:07:01:01:BF:15.  (Could it be that the interface is. .
. . broken?!?  :-)


Thanks in advance,

Walt Wimer
Networking and Communications
Carnegie Mellon University
-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 90 03:05:22 GMT
From:      helios.ee.lbl.gov!ace.ee.lbl.gov!leres@ucsd.edu  (Craig Leres)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How to SLIP without subnets (was SLIP on unix-systems)
Followups to comp.protocols.tcp-ip.

Gee, perhaps I'm missing the point but I don't see why you need to use
subnets at all. Let's say the slip gateway machine's address is
126.0.128.30 (using a netmask of 0xffffff00). Pick any free address on
the subnet for the remote host, say 126.0.128.45.

Now on the remote side, ifconfig the slip line (which is a
point-to-point) using the ip address we've chosen for the local end
(126.0.128.45) and the address of the gateway for the far end
(126.0.128.30). Install a static default route via the gateway
(126.0.128.30).

On the slip gateway, ifconfig the slip line using the gateway and
remote addresses (reversed from above). This gives you an interface
route to the remote host. Publish an arp entry for the remote host
(126.0.128.45) using the ethernet address of the gateway. (Make
sure ipforwarding is enabled.)

We've been running two slip hosts this way for months now...

		Craig
-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Feb 90 13:43:37 PST
From:      richardt@Legato.COM
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for PC-based routing software...
That can handle 56k serial.  Please reply to this account.

RichardT
richardt@legato.com
-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Feb 90 15:07:06 CST
From:      "O'Brennan, Gerry" <C0022@UMRVMB.UMR.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: tn3270 for Apollo or RT?
On Mon, 26 Feb 90 14:45:05 CST David W. Dearth, Director said:
>Did we ever find TN3270 for the Apollos? I wonder if this guy did.
>
>----------------------------Original message----------------------------
>Does anyone know of a source for tn3270 for an Apollo Domain 3000 or 3500
>or for an IBM RT running AIX 2.2.1?  I can download via anonymous ftp.
>Please reply by mail to rhh@brownvm.brown.edu.  Thanks.
>                                           --Bob

Richard has the source, but so far has not been able to get it to work on
the Apollos. He has one more trick up his sleeve. We will let you know if
we have success.

Gerry
Acknowledge-To: <C0022@UMRVMB>
-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 90 11:08:15 GMT
From:      mcsun!prlbcom!lln-cs!sunbim!syteke!jim@uunet.uu.net  (Jim Sanchez)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP or PPP support (opinions wanted)
My Company is thinking about trying to support something such as SLIP
on our terminal server ports.  With PPP now becoming defined and SLIP
still kinda implementation specific, what does the net think about the
advisability of moving to PPP.  Of course, the no-brainer answer would
be to do both but that costs time and money :-).  Seriously, if people
have thoughts on this subject, I'd like to hear about it either via
email or posting.  I'll summarize the email traffic if I receive any.
Thanks
-- 
Jim Sanchez  {sun,hplabs}!sytek!syteke!jim OR
Hughes LAN Systems, Brussels  uunet!prlb2!sunbim!syteke!jim
-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 90 14:34:20 GMT
From:      snorkelwacker!spdcc!merk!alliant!linus!nixbur!nixpbe!peun11!capit@tut.cis.ohio-state.edu  (Pit Capitain)
To:        tcp-ip@nic.ddn.mil
Subject:   how to get exit status of rcmd ???
Hi, does anybody know a method to get the exit status of a remote
command, something like "rcmd host command; echo $?" where the
exit status of "command" is returned?

Thanx in advance,	Pit

+-----------------------+---------------------------------------------------+
!  Pit Capitain, DX-PC  !  US:  ...uunet!philabs!linus!nixbur!capitain.pad  !
!  Nixdorf Computer AG  !  not US:    ...{mcvax!}unido!nixpbe!capitain.pad  !
+-----------------------+---------------------------------------------------+
-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 90 17:25:52 GMT
From:      mentor.cc.purdue.edu!dls@purdue.edu  (David L Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: freeing socket on TCP close request

	You can use a shutdown(2), but beware! Shutdown(2) (both ways, anyway)
is equivalent to TCP's ABORT() user request. In particular, if any data is
buffered in the kernel locally waiting to be sent, it will be dropped and
the other side will never see it.
	Some protocols have (essentially) extraneous acknowledgements at the
application level, so you really can tell when you've gotten all the data,
and then shutdown(2)'s ok. In most cases, you really want a close(2).
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 90 17:56:06 GMT
From:      bu.edu!buit13!kwe@bloom-beacon.mit.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Many logical nets on a single physical net
In article <1990Feb23.214634.8645@wang.com> fitz@wang.com
 (Tom Fitzgerald) writes:
>Is it possible to have a single Ethernet with multiple IP network addresses
>on it, and get the separate IP nets talking to each other?  Especially, is
>it possible to do this cheaply?
>

	You need to be able to tell your hosts to ARP for all
addresses.  In other words, you need to make them think that every
other host is reachable directly.  The net part is zero length; the
entire address is "local part".  This gets you what you want without
the extra hop of a single-interface gateway.  If you add a real
gateway somewhere at some future time, and if it supports proxy ARP
correctly, this will work thru a transition from bridged/repeatered
LANs to properly internetted LANs, until such time as you can come
back to all your hosts and set a new subnet/net mask and stop using
proxy ARP if you choose.

	However, since there is a "built-in" net mask defining
net/local for class A, B, C, etc, this "zero-length" network mask may
not work in specific products, depending on how subnet masks were
implemented.  In fact, it might not be RFC legal.  (Must check that
Host Requirements RFC again.)  I don't know of anyone offhand who is
using proxy ARP this aggressively.  Most people just use it to handle
backward compatibility for the subnet problem between 4.2 and 4.3 BSD.
So their hosts are still using the "built-in" class-based mask or are
using subnet masks as an "extension", rather than "replacement" of the
built-in mask.  (Maybe you can set the subnet mask to be a negative
number? :-)

	But this does solve the dynamic gateway discovery problem
rather neatly.  That's it!  Let's do away with net/local altogether
and have hosts ask for pathways to every IP address they want.  Does
that sound like an advanced end-system protocol?  :-)

	Kent England, Boston University
-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 90 18:32:40 GMT
From:      mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu  (Bob Sutterfield)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Many logical nets on a single physical net
You might try cobbling something up with Proxy ARP to fill in the ARP
tables when IP would rather route than ARP.
-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 90 18:40:15 GMT
From:      zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!trn@tut.cis.ohio-state.edu  (Tony Nardo)
To:        tcp-ip@nic.ddn.mil
Subject:   *.jhuapl.edu -- serious gateway thrashing
For the past few weeks, links between the *.jhuapl.edu nodes and the
non-MILNET community have been somewhat unstable.  Today, however, is
the first time that I've seen an extreme case of gateway thrashing:

warper.110% traceroute uunet.uu.net
traceroute to uunet.uu.net (192.48.96.2), 30 hops max, 40 byte packets
 1  apl-b3-gw (128.244.3.1)  0 ms  10 ms  0 ms
 2  apl-gw (128.244.1.1)  0 ms  10 ms  0 ms
 3  RESTON-DCEC-MB.DDN.MIL (26.21.0.104)  290 ms MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  320 ms  330 ms
 4  MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  690 ms CAMBRIDGE-MB.DDN.MIL (10.3.0.5)  430 ms  430 ms
 5  CAMBRIDGE-MB.DDN.MIL (10.3.0.5)  740 ms * MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  1340 ms
 6  MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  1210 ms CAMBRIDGE-MB.DDN.MIL (10.3.0.5)  2060 ms  2080 ms
 7  CAMBRIDGE-MB.DDN.MIL (10.3.0.5)  990 ms MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  1290 ms  1710 ms 
 8  * CAMBRIDGE-MB.DDN.MIL (10.3.0.5)  1640 ms * 
 9  * MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  3010 ms  2490 ms 
10  MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  2240 ms * * 
11  CAMBRIDGE-MB.DDN.MIL (10.3.0.5)  2220 ms * * 
12  * CAMBRIDGE-MB.DDN.MIL (10.3.0.5)  3920 ms * 
13  * * * 
14  * * * 
15  * * *

etc.

Does anyone have any insights as to how this thrashing starts?  How it
may be stopped?
--
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
-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 90 20:00:45 GMT
From:      snorkelwacker!usc!cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!utzoo!sq!news@tut.cis.ohio-state.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: One-shot ftp client

In article <792@winnie.fit.edu>, rcs89301@zach.fit.edu ( Thomas E.
Currey) writes:
> 
> usage :  shftp address loginname password [file1 file2 file3 file4
file5 file6]
> 
> -----------------------CUT HERE Beware no comments read manual--------------
> #! /bin/sh
> cat "machine $1 login $2 password $3" >> $HOME/.netrc
> chmod 600 $HOME/.netrc
> echo "binary
> get $4 
> get $5 
> get $6 
> get $7 
> get $8 
> get $9 
> quit" > $HOME/ftp.tmp
> ftp $1 < $HOME/ftp.tmp > /dev/null       
> rm $HOME/ftp.tmp
> --------------------------------------------------------------------------

Here is a version that has a greater chance of working (it echoes the
arguments into ~/.netrc, instead of trying to cat a non-existant file onto
it :-( ), and that makes the computer do the gruntwork like making the temp
file and remembering what args go where.

#! /bin/sh
# yet another batch ftp client
# usage: shftp address loginname password file1 [file2 file3 file4 file5 file6]

machine=$1
login=$2
passwd=$3
shift; shift; shift;
echo "machine $machine login $login password $passwd" >> $HOME/.netrc
chmod 600 $HOME/.netrc

ftp $machine <<!
binary
get $1
get $2
get $3
get $4
get $5
get $6
quit
!
sort -u -o $HOME/.netrc $HOME/.netrc & # now filter out dups, in background


Ian Darwin
ian@sq.com
-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 90 21:07:06 GMT
From:      C0022@UMRVMB.UMR.EDU ("O'Brennan, Gerry")
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 for Apollo or RT?

On Mon, 26 Feb 90 14:45:05 CST David W. Dearth, Director said:
>Did we ever find TN3270 for the Apollos? I wonder if this guy did.
>
>----------------------------Original message----------------------------
>Does anyone know of a source for tn3270 for an Apollo Domain 3000 or 3500
>or for an IBM RT running AIX 2.2.1?  I can download via anonymous ftp.
>Please reply by mail to rhh@brownvm.brown.edu.  Thanks.
>                                           --Bob

Richard has the source, but so far has not been able to get it to work on
the Apollos. He has one more trick up his sleeve. We will let you know if
we have success.

Gerry
Acknowledge-To: <C0022@UMRVMB>

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 90 00:19:20 GMT
From:      nems!dtix!curt@mimsy.umd.edu  (Welch)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: *.jhuapl.edu -- serious gateway thrashing
In article <4790@aplcen.apl.jhu.edu> trn@aplcen.apl.jhu.edu (Tony Nardo) writes:
>For the past few weeks, links between the *.jhuapl.edu nodes and the
>non-MILNET community have been somewhat unstable.  Today, however, is
>the first time that I've seen an extreme case of gateway thrashing:
>
>warper.110% traceroute uunet.uu.net
>traceroute to uunet.uu.net (192.48.96.2), 30 hops max, 40 byte packets
> 1  apl-b3-gw (128.244.3.1)  0 ms  10 ms  0 ms
> 2  apl-gw (128.244.1.1)  0 ms  10 ms  0 ms
> 3  RESTON-DCEC-MB.DDN.MIL (26.21.0.104)  290 ms MARINA-DEL-REY-MB.DDN.MIL (26.
>6.0.103)  320 ms  330 ms

  [multiple MB hops deleted]

>12  * CAMBRIDGE-MB.DDN.MIL (10.3.0.5)  3920 ms *
>etc.
>
>Does anyone have any insights as to how this thrashing starts?  How it
>may be stopped?

We have been seeing this same problem for weeks.  One minute,
traceroute shows a normal route off of the MILNET through one of the
mail-bridges, and the next minute, we see traceroute output like the
example above.  Our packets are being passed around between the mail
bridges, but they never leave the MILNET/ARPANET.  Whenever this
gateway thrashing starts, it lasts long enough to break TCP
connections.

It has gotten so bad in the last week that it almost stopped our news
feed.  The nntp connections, when they could get started, would only
last for about 3 to 5 minutes before being disconnected.

For weeks, ftp and telnet connections to anywhere off of the MILNET
have been terrible.  They would only last a few minutes before
disconnecting, and even when they were connected they were really to
slow to use.

For the past few months, ftp connections to non MILNET sites have been
getting worse and worse.  I installed traceroute a month ago in an
effort to get a handle on these network problems.

When I first saw this problem, I assumed that some of the mail bridges
must be going down.  Now, I would guess that this problem is being
caused by too much traffic through the mail bridges.

Who runs the mail bridges and who can tell me what's going on?

What has been changing in the past few months that has caused this?

Has the traffic really been increasing or has the number of gateways
been decreasing?  Or is something much more complex causing this problem?

Why do the mail bridges bounce packets around like that?  Do they really
think that the best route is through the other bridge or do they use
a packet routing algorithm that gives the packets to another bridge
when the queue for the outbound link is full?. 

Who do I need to contact to get this problem resolved?

Do we have to get a connection to NSFnet to get away from this problem?

Is there anything we could be doing wrong to cause this?

Is there anything we can change to get around this problem?

Thanks in advance for any help anyone can give us.
(while I can still talk to you...)

Curt Welch
curt@dtix.dt.navy.mil

P.S. Our gateway to the MILNET is through dtrc-b1-gw.dt.navy.mil,
     a cisco router, MILNET address 26.22.0.81.
-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 90 00:57:51 GMT
From:      van-bc!ubc-cs!alberta!mts.ucs.UAlberta.CA!ualtavm!DKRUGER@ucbvax.Berkeley.EDU  (Dwight Kruger)
To:        tcp-ip@nic.ddn.mil
Subject:   Public Domain NFS client for MS-DOS
I am looking for a public domain, or freeware version of a NFS client
for MS-DOS microcomputers.  Is there a anonymous FTP site with either
source code or executable binaries?
 
 
Dwight Kruger
Network Software Development
University Computing Systems
The University of Alberta
-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 90 01:18:19 GMT
From:      rbp@well.sf.ca.us (Bob Pasker)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   do you have a sample VMS/ULTRIX Connection (TCP/IP) program?

If you have a sample program which acts as a TCP/IP server using the
VMS/ULTRIX Connection V1.0 software, please send me a copy.  The
example in the book does not match the documentation.  Any language
will do. It should use the Internet $QIOs, not the C run-time library
calls and use the standard structure declarations from SYS$LIBARY:.



-- 
- bob
;-----------------------------------------------------------------
; Bob Pasker, San Francisco, CA	 	| rbp@well.sf.ca.us
; +1 415-695-8741			| {apple|pacbell}!well!rbp

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Feb 90 11:44:25 PST
From:      braden@venera.isi.edu
To:        ietf@venera.isi.edu, tcp-ip@nic.ddn.mil
Subject:   IAB Meeting Minutes available
At its most recent meeting, the Internet Activities Board decided to
publish the minutes of its meetings.  Accordingly, the minutes
of the most recent meeting are now available for anonymous FTP from host
venera.isi.edu with pathname in-notes/iab.minutes.jan90.  The minutes
will be included in the next Internet Monthly Report as well.

Bob Braden, for the IAB
-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 90 09:07:10 GMT
From:      Ksoll@DB0TUZ01.BITNET
To:        comp.protocols.tcp-ip
Subject:   Problem with Interactive's telnet


Hi,
we want to push a lovely application on top of telnet(1c) (maybe
ISO-OSI layer 8 ;-). Therefore we grab telnet's stdin and stdout
with pipe(2), fork(2), dup(2) and exec(2). This works fine on
Unicos, IRIX, DomainOS 10.1 and HP-UX 6.5. But it does not work
with Interactive's 386/ix-telnet 1.1.2. If I try to run telnet under
sdb, then telnet prompts in an endless loop. Is this a known bug?
Can I avoid it with a workaround? Is there source code available
so that we can fix it?
(I guess it smells like a nonblocking read(2) problem).
Thank you for your help.
Wolfgang Ksoll   Computer Center, Tech. Univ. Berlin(West), Germany
                 Ksoll@db0tuz01.bitnet

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Feb 90 11:16:18 MET
From:      baux@sm14.ec.bull.fr (Andre Baux)
To:        tcp-ip@nic.ddn.mil
Subject:   Is there a TCPIP group list ?
Is there a list for TCPIP discussion besides the tcp-group
If so, can you add me to the list
Thanks,
Andre

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=++=+=+=+	Andre Baux
Email   : baux@ec.bull.fr		Bull S.A.
Fax     : 011-33-76397600		1, Rue de Provence / B.P. 208
Phone   : +33 76 39 76 02		38432 Echirolles CEDEX / FRANCE
Bulltex : A.BAUX
-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 90 12:31:15 GMT
From:      zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!kjh@tut.cis.ohio-state.edu  (Ken Heeres x8004)
To:        tcp-ip@nic.ddn.mil
Subject:   Problem with FTP's TCP/IP
I am experimenting with socket programming using the PC/TCP
development kit.  I am using the example of a simple TCP
application in the book UNIX Network Programming by
W. Richard Stevens.  I have two problems
 
 1. When I try to compile the example client on page 286 I get
    an incompatible types error on  the line:
 
    serv_addr.sin_addr.s_addr = inet_addr(SERV_HOST_ADDR);
 
 
    serv_addr is declared to be of type struct sockaddr_in.  I looked
    in the header files and inet_addr is declared to be of type
    function returning in_addr.  I tryed casting the return value to
    u_long which made the compiler choke.  I then droped the s_addr
    off of the left hand side and the compiler(MSC5.1) took it.
 
 2. The code that was produced does not work.  I ran the same code
    with out the changes on a vax under ultrix and it works, so I
    figured my change was not benign.  The client fails when it
    trys to write to the socket using write().  The error that I
    get back is:
 
        bad file number
 
Can you shed some light on what I might be doing wrong?
 
 
                      ken Heeres
 
-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 90 13:48:27 GMT
From:      mcsun!ukc!slxsys!qtlon!uel!tehm@uunet.uu.net  (Tris Mabbs)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PC X server ( over SLIP )

Sorry, no information, but if anyone has any, could they post it or mail it
to me too please?

----
	Until I pull by .signature, this will have to do:

	Tris Mabbs.

Opinions etc. expressed here are mine and do not necessarily reflect those of
my employer!
-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 90 20:46:10 GMT
From:      att!hriso!devildog!jrallen@ucbvax.Berkeley.EDU  (Jon Allen)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP Protocol Question: reusing connections

I am having trouble understanding how the TCP protocol works when a 
connection is closed and the same connection is reused soon after 
closing (same end port numbers).  [I am certainly no TCP protocol
guru!]

The sequence of events is a connection is established from machine A
to machine B.  This connection is closed and the same connection is
opened a short time later, however a RST occurs.  I have been told
that this happens because the next SYN sequence number is within
the 'window'.  The following is an actual trace:

	.
	.
	.

Packet #: 20
ether: IP    machineA          -> machineB              64    1007.728    14.233
   ip: TCP   8201.0064 -> 8201.003c
  tcp: 1023    -> CMDSRV   FIN ACK 
  tcp: seq:  29252636  ack:   9361313  win: 4096  len:    0  

Packet #: 21
ether: IP    machineB            -> machineA            64    1009.939     2.211
   ip: TCP   8201.003c -> 8201.0064
  tcp: CMDSRV  -> 1023     ACK 
  tcp: seq:   9361313  ack:  29252637  win: 8192  len:    0  
#
# Connection is closed at this point.  The next SYN is an attempt
# to open the same connection (same address and port numbers).
#
	.
	.
	.

Packet #: 24
ether: IP    machineA          -> machineB              64    2615.763  1588.359
   ip: TCP   8201.0064 -> 8201.003c
  tcp: 1023    -> CMDSRV   SYN 
  tcp: seq:  29254401  ack:         0  win: 4096  len:    0  

Packet #: 25
ether: IP    machineB            -> machineA            64    2618.096     2.334
   ip: TCP   8201.003c -> 8201.0064
  tcp: CMDSRV  -> 1023     RST ACK 
  tcp: seq:   9361313  ack:  29252637  win: 8192  len:    0  

Packet #: 26
ether: IP    machineB            -> machineA            64    2619.358     1.262
   ip: TCP   8201.003c -> 8201.0064
  tcp: CMDSRV  -> 1023     RST ACK 
  tcp: seq:         0  ack:  29254402  win:    0  len:    0  

	.
	.
	.

The above trace was edited for brevity and only the last part of the
connection shutdown sequence is shown.  However, it seems to conform
to the TCP spec.  After reading the TCP RFC several times, I cannot
seem to understand how the sequence numbers should come into play
on a reused connection.  This trace brings up several questions:

	1) Why is the RST generated by machineB?  I have been told
	   it is because the SYN sequence number is within the 
	   ack# plus the window size.

	2) But if this is true then wouldn't some flakiness occur?
	   For example, if the window size was small enough that the 
	   SYN flagged packet would be outside the window and work,
	   wouldn't raising the window size then cause it to fail (can't
	   window size be adjustable on some machines?)?
	   This doesn't seem right to me.

If someone could provide me with some enlightenment, I would 
appreciate it.

-Jon

...!att!acpy01!jrallen
attmail!jrallen
-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 90 22:47:53 GMT
From:      karl!davis@handies.ucar.edu  (Glenn P. Davis)
To:        tcp-ip@nic.ddn.mil
Subject:   New Protocols
We are experimenting with TCP/IP based weather information services.
(Try 'finger weather@unidata.ucar.edu' ; Not much use if you live in
the Bay Area, but hey ...)

We were wondering what the process is for registering a protocol and service.
I have some info but seems pretty out of date...

Thanks

Glenn P. Davis		davis@unidata.ucar.edu
UCAR / Unidata
PO Box 3000                   1685 38th St.
Boulder, CO 80307-3000        Boulder, CO  80301

(303) 497 8643
-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 90 00:51:27 GMT
From:      mogul@decwrl.dec.com  (Jeffrey Mogul)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Directed broadcasts??
In article <11545@nlm-mcs.arpa> gish@host.UUCP () writes:
    Would someone please outline how to perform a directed broadcast--
    that is, a broadcast to a net located one or more hops away?
    Are there severe limitations or restrictions on the use of directed
    broadcasts, such that directed broadcasts are impractical?  e.g.,
    are routers usually configured to block off-site broadcast packets?
    
Well, you might look at RFC922:
      Mogul, J.C.  Broadcasting Internet datagrams in the presence of subnets.
      1984 October; 12 p. (24832 bytes)
On the other hand, I think it is nearly universally agreed that if
broadcasting is evil, then directed broadcasting is evil compounded.
I.e., I wouldn't suggest using them (and as far as I know, few
routers implement directed broadcasting).
    
    BTW: the reason for asking this question (aside from my naivety) is
    that I am investigating providing network services on machines whose
    network identities may change (although the subnet probably wouldn't);
    and I'd like to avoid having to update potentially thousands of
    distributed copies of client applications when these changes do occur.
    I'd be very interested if perhaps y'all have some better suggestions
    than directed broadcasts.

Sounds like you want to use multicasting (see RFC1112 and RFC1075).
But you might have to wait a while for that to be widely implemented.

Or maybe you should just use the Domain Name System (DNS) to provide some
late binding (i.e., assign a nickname to the host that is currently
providing the service, and require the clients to look up that nickname
whenever they want to use the service).  You can do it today if your
software uses DNS (and if it doesn't, fix that first).

-Jeff
-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Feb 90 12:00:57 PST
From:      richardt@Legato.COM
To:        dlj@proteon.com (Daniel L. Jones)
Cc:        mag%WLBR@wlv.imsd.contel.com, tcp-ip@nic.ddn.mil, richardt@Legato.COM
Subject:   Re: IP routers
Was this blatant advertisement really appropriate for this forum?

RichardT
-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Feb 90 13:13:02 -0500
From:      powles_dm%ncsd.dnet@gte.com (DREW M. POWLES)
To:        tcp-ip@gte.com, powles_dm@gte.com
Subject:   3270 terminal access
If I had an existing application running on an IBM mainframe which was accessed
by 3270 terminals, how could I go about integrating that into a new application
running on some SUN workstations on a LAN?  I don't need anything fancy,
so I considered just bringing up a 3270 emulation window and talking to
the application that way.  The question is then, is there software for a
SUN, and software for an IBM controller (or perhaps an add-on box from
someplace like ACC) that would allow me to attach my IBM mainframe to the
LAN, then connect to it from a 3270 emulation process in the SUN over TCP/IP
or just IP?

thanks for the help, answers to me directly or the world,
Drew M. Powles
GTE Government Systems
1700 Research Boulevard
Rockville, Maryland 20850-3181
(310) 738-8907
powles_dm%ncsd@gte.com

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 90 04:59:57 GMT
From:      sdcc6!CERF.NET!pushp@ucsd.edu
To:        tcp-ip@nic.ddn.mil
Subject:   VAX MultiNet / SLIP
Hi

I would like to hear from people who have succesfully
run SLIP using cisco / Xylogics Terminal servers,
VAX-VMS MULTINET, and Telebit Modems.

Email replies please.

Pushpendra
-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Feb 90 11:30:27 EST
From:      dlj@proteon.com (Daniel L. Jones)
To:        mag%WLBR@wlv.imsd.contel.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   IP routers

   Instead of overloading a host with the communciations
processing of an ever expanding network, dedicate a network device
to handle the job.   
   All three router companies that were mentioned, make good products.
But Proteon has specific advantages:  Support for OSPF, a
dynamic (IGP) routing protocol, which is standardized. Support for a high
speed backbone, Pronet-80, which will migrate to FDDI. BTW, Proteon's FDDI
board just passed AMD interoperability testing. 

    In addition, Proteon Routers can interconnect Token Ring, Ethernet,
X.25 (PDN & DDN) and Serial Communications (up to T1). Proteon's
software can forward multiple protocols, which include: IP, IPX (Netware),
DECnet, XNS & Appletalk. Proteon's OverVIEW SNMP Network Manager can
monitor the Routers and Hosts on the network from a central location.

    For more information, contact our sales office at (508) 898-2800.  

Dan Jones
Proteon Customer Service
-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 90 08:02:08 GMT
From:      agate!shelby!csli!carl@ucbvax.Berkeley.EDU  (Carl Schaefer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: One-shot ftp client
In article <1990Feb26.200045.24761@sq.sq.com> ian@SQ.Com (ian) writes:
] #! /bin/sh
] # yet another batch ftp client
] # usage: shftp address loginname password file1 [file2 file3 file4 file5]
] 
] machine=$1
] login=$2
] passwd=$3
] shift; shift; shift;
] echo "machine $machine login $login password $passwd" >> $HOME/.netrc
] chmod 600 $HOME/.netrc
] 
] ftp $machine <<!
] binary
] get $1
] get $2
] get $3
] get $4
] get $5
] get $6
] quit
] !
] sort -u -o $HOME/.netrc $HOME/.netrc & # now filter out dups, in background
] 
] 
] Ian Darwin
] ian@sq.com


urk.  how crufty.  How about:

    #!/bin/sh
    # usage: shftp address loginname password file

    ftp -n << +
      open $1
      quote USER $2
      quote PASS $3
      get $4
    +
    exit
-- 
Carl Schaefer
carl@csli.stanford.edu
-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Feb 90 14:17 CST
From:      "Steve Huff, U. of Kansas, Lawrence" <HUFF@kuhub.cc.ukans.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Please add to the mailing list
Please add HUFF@kuhub.cc.ukans.edu to TCP-IP.  Thanks!
-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Feb 90 16:13:15 EST
From:      mep@aqua.whoi.edu (Michael E. Pare)
To:        dlj@proteon.com, mag%WLBR@wlv.imsd.contel.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  IP routers
The key to all this is how much!!  The routers (item 3) are good but are
expensive.  If your traffic will be light and you only have the one network
this may be overkill.  A PC running router software may be a better cost
implementation.

You'll have to make the cost justification.  Bon chance!!
-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 90 13:36:54 GMT
From:      amdahl!fai!ljb@ames.arc.nasa.gov  (Larry Boggis FAI N.C.)
To:        tcp-ip@nic.ddn.mil
Subject:   3COM CS200 Terminal Servers
Can anyone tell me if 3COMs CS200s support sockets?  I am trying to nail
up a socket between a Unix box and a port on a CS200 terminal server.
Thanks.
-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 90 15:34:20 GMT
From:      mcsun!hp4nl!philapd!ssp18!aruit@uunet.uu.net  (A. de Ruiter)
To:        tcp-ip@nic.ddn.mil
Subject:   FTP-TCP/IP conflict with MSWindows
At first thanks to everyone who replied to my question for help:

- What is the problem when our MSWindow Dynamic Link Library program is crashing
  in the first socket() call to TCP/IP?

With help of James vanBokkelen of FTP Software we discovered the reason of this
problem:

- The FTP TCP/IP libraries are not compatible with MSWindows, because there are
  MSC-5.1 functions used which are not possible under MSWindows and also the
  DS!=SS issue of MSWindows is here a problem.

- As bypass we have adapted three c functions of the netlib library, cleanup.c,
  find_vec.c and vec_srch.c, which are delivered in the Development Kit.
  We have made some variables static and changed the puts() in a MessageBox().
  Then we have recompiled these functions with the necessary flags for MSWindows
  and have replaced them in the library.  We have relinked our DLL program with
  the new library and our problem was solved.

- FTP Software is now busy to generate an official MSWindows compatible
  Development Kit in which all libraries are MSWindows compatible.
  This new release of the Development Kit will be ready on short term.

--------------------------------------------------------------------------------
										|Philips Information Systems            
  _                       __            |Optical Filing Systems, Anton de Ruiter
 /_| __ /_ _  __  __/_   /__)   ./_ _  _|Post Office Box 245, V2-B2          
/  |/ /(_ (_)/ / (_/(-' / \ (_//(_ (-'/ |7300 AE  Apeldoorn, The Netherlands    
      __                 ____  ___      |---------------------------------------
     /__)/_ ./  ._  _     /   /___      |Internet: aruit@idca.tds.philips.nl    
    /   / //(_ //_)/_) __/_   ___/      |UUCP    : ..!mcvax!philapd!aruit       
              /                         |Phone   : +31 55 433514                
                                        |Fax     : +31 55 433488                
--------------------------------------------------------------------------------
-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 90 18:30:09 GMT
From:      zaphod.mps.ohio-state.edu!usc!srhqla!nrcvax!ihm@tut.cis.ohio-state.edu  (Ian H. Merritt)
To:        tcp-ip@nic.ddn.mil
Subject:   High-speed laser point-to-point short distance data link
I'm posting this on behalf of a friend who does not have net access.

Does anybody out there in netland know of a device that uses lasers to
implement a short distance (i.e. 300 yds or so) very high speed (i.e.
100Mbit or 1Gbit) data link?  Can these things be purchased?  If so,
who from?

Thanx in advance.   Responses please to ihm@nrc.com

	-i
-- 
US Snail:	2380 Rose Avenue; Oxnard, CA  93030  U.S.A. tel. 805-485-2700
InterNet:	ihm@NRC.COM
-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 90 19:15:02 GMT
From:      pacbell!rtech!wrs!hwajin@ames.arc.nasa.gov  (Hwa Jin Bae)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP bind question
In article <1990Feb23.052940.5871@i88.isc.com> stevea@i88.isc.com (Steve Alexander) writes:
>You missed the worst one of all.  Options management.  Most vendors use
>sockaddr_in for TCP & UDP addresses, but everybody has a different option
>format.  Still, I agree that it's probably easier to port TLI applications 
>between systems than socket applications, if for no other reason than that 
>no two vendors can agree on where the header files go.

Talk about trivial differences.  The options data structure differs in
varying degrees but for all pratical purposes the differences can be
resolved with simple mods since in most cases the options data include
fields for the option name and the value settings.  Agreed, different
vendors may choose to use different formats, etc. but that's what 
option means: optional.  For example, options available for the
sockets SO_DEBUG, SO_REUSEADDR, SO_KEEPALIVE, SO_LINGER, etc. in 4.3 BSD
are just options.  While some of these options are for a particular
protocol -- as in TCP and SO_KEEPALIVE, SO_LINGER, etc. -- some are purely
implementation dependent -- as in SO_DEBUG, SO_USELOOPBACK, etc.  A TCP
implementation is *not* required to implement all these options or
provide interfaces to these options.  The interface definitions for the
options *should* be left undefined since vendors may choose to implement
different options, etc.  If you were to design a TLI interface would you
design in every possible option data structure format that can be ever
used?  Aside from being an impossible task, it is a highly unwise thing
to do as one cannot possibly plan for every possible vendor specific
"enhancements", etc.  If an application write chooses to use a given
option provided by a given vendor it is his responsibility to support
such software.  Besides, how many TLI applications you know actually
make heavy use of the options any way?  Even the socket applications
have "#ifdef"s everywhere for options like SO_OOBINLINE and SO_LINGER
because not all implementation support these.

>The bottom line is that AT&T should have defined protocol bindings for TLI,
>or at least put pressure on vendors of UNIX System V add-on packages to be
>more compatible with each other.

I don't like Fascism.

-- 
Hwa Jin Bae (hwajin@wrs.com)
Wind River Systems
-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 90 20:17:00 GMT
From:      HUFF@kuhub.cc.ukans.edu ("Steve Huff, U. of Kansas, Lawrence")
To:        comp.protocols.tcp-ip
Subject:   Please add to the mailing list

Please add HUFF@kuhub.cc.ukans.edu to TCP-IP.  Thanks!

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 90 20:24:15 GMT
From:      mcsun!sunic!kth.se!draken!perand@uunet.uu.net  (Per Andersson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A login shell called sliplogin?
In article <1196@swbatl.UUCP> uucigj@swbatl.UUCP (3531) writes:
>Once again while reading a readme file that accompanied the tip with slip
>program, I found a paragraph that mentioned :
>
>related to this enhanced tip is the program "sliplogi" which will act as 
>a login shell for an incoming dialup slip connection.

In my slip distribution, which I got of some.toronto.host the sliplogin 
program is the part that does for me what slattach did in BSD4.3. It can
also do what you are asking for. But this part of the distribution is for
SunOs 4.0 and greater, which is sad, because this Sun can't keep up with
a 9600 bps slip connection. Well, there doesn't seem to be a sliplogin
program for anything but sunos, so you'll probably have to modify it if
you don't have a Sun. This distribution is called 'slipware' anyway.
Good luck !

Per
-- 
---
Per Andersson
Royal Institute of Technology, Stockholm, Sweden
perand@admin.kth.se, @nada.kth.se 
-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 90 21:04:13 GMT
From:      nisca.ircc.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!kuhub.cc.ukans.edu!jian@tut.cis.ohio-state.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Trivial Transport Services on Ultrix
Is anyone out there know the trivial transport services on the Utrix system?
Does it has the same kind of functions that the trivial file transfer protocol
has. I would appreciate the help.                
                                      -- Jian
-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 90 22:26:58 GMT
From:      news@ncsuvx.ncsu.edu  (Kevin D. Bond)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tn3270 for Apollo or RT?

I have a version of tn3270 that runs on the Apollo.

Anyone that is interested can send me mail.  If there is enough interest
I can probably make it available by anonymous ftp.

-kevin
--
kdb@cscrazcsu.edu
kdb%sas.uucp@mcnc.org

END OF DOCUMENT