# The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Aug 88 09:40:57 PDT
From:      lars@ACC-SB-UNIX.ARPA (Lars J Poulsen)
To:        lars@ACC-SB-UNIX.ARPA, tcp-ip@sri-nic.arpa
To: tcp-ip@sri-nic.arpa
Date: Mon, 1 Aug 88 08:44:14 PDT
From: lars (Lars J Poulsen)
Message-Id: <8808011544.AA13705@ACC-SB-UNIX.ARPA>
Subject: Re:  TCP/IP over X.25 under Unix ? (really: those damn cc-lines)

Sorry; along with Keith McCloughrie I confess to problems with editing
cc-lines, thus letting you all read a personal reply (Though the damage
may have been limited since it was in a furreign tongue).

/ Lars Poulsen

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Mon, 01 Aug 88 15:44:50 EDT
From:      Doug Greenwald <R1ECGF%AKRONVM.BITNET@CUNYVM.CUNY.EDU>
To:        TCP/IP List <TCP-IP@SRI-NIC.ARPA>
Subject:   HP TCP/IP Conformance

Hi,

A few weeks ago, i saw something mentioned concerning problems with
HP systems with TCP/IP.  Something about problems getting HP's to work
with various gateways.  I would appreciate seeing this info again.  We
are currently looking at various vendors for networkable workstations,
an HP is one of the contenders, if you or they can show us that thier
workstations support TCP/IP and/or Ethernet networking with minimal

Please respond directly to me and I will sumarize to the net if there is
sufficient interest.

Doug Greenwald
Engineering Computer Graphics Facility
University of Akron

Bitnet:  R1ECGF@AKRONVM

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 11:53:33 GMT
From:      gregb@dowjone.UUCP (Greg_Baber)
To:        comp.protocols.tcp-ip
Subject:   Re: Instrumenting a TCP Implementation

In article <8807291003.AA24101@ucbvax.berkeley.edu> kzm@TWG.COM (Keith McCloghrie) writes:
[stuff eaten]
>> We, at the Department of Computer Science, University of Maryland, have
>> done an instrumentation of TCP/IP. Here is the abstract from the
>> Technical Report describing our work:
>> "We ....
>>                ... code)."
>> Interested persons can get a copy of the Report by sending mail to
>> 	tcplog@chakra.cs.umd.edu
>> CS-TR 2063 and UMIACS-TR 88-50
Interested! Please send me the reports too.

>Thank-you,
>Keith.

--
Reply to: Gregory S. Baber		Voice:	(609) 520-5077
Dow Jones & Co., Inc.		E-mail:	..princeton!dowjone!gregb
Box 300
Princeton, New Jersey 08543-0300


-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 18:07:00 EDT
From:      <enger@gburg.scc.com>
To:        "geoff" <geoff@usafa.arpa>
Cc:        <tcp-ip@sri-nic.arpa>
Subject:   VMS TCP/IP software
Geoff:

I will have to concur that Wollongong is expensive, but to some extent
you get what you pay for.  Those guys send engineers to all the networking
conferences.  TWG seems to be incorporating some of the more important
protocol enhancements into their products in a timely fashion.  Their version
3.2 software incorporates the Van Jacobson window adjustment scheme.

We use version 3.2 and are pretty happy with it.  When all I can find to
complain about is CC: fields in the mailer (and thats a VMSmail problem really)
it can't be too bad a product, right?

The capability to keep up the with latest developments may become increasingly
important.  The ability to respond to Usage Sensitive Charging by incorporating
a more efficient telnet may be a big win to your budget.  If you use the TWG
package to connect to the wide area subnet you may appreciate their support
when BBN womps PSN 7.0 on you :-) .

Although I am not a user of the product, I have heard generally good reports
on the Multinet product.  This product was (maybe still is) available from
SRI.  I believe two of its developers have left SRI to persue the further
developement and enhancement of the product.  You may wish to review the
recent TCP/IP archives to locate them.

Bob Enger
Contel Federal Systems


-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 15:37:43 GMT
From:      eckert@faui10.uucp (Toerless Eckert)
To:        comp.sources.wanted,comp.unix.wizards,comp.unix.questions,comp.protocols.tcp-ip
Subject:   Again: looking for gated

I looking for the sources of gated.

As i do not have access to the internet, i cannot get them through ftp.
I only have access to bitnet and uucp. I also could get files
using anonymous ftam over the PSN.

Is there any bitnet listserver that has gated, or can someone send me the
sources by mail ?

Toerless Eckert	(tte@derrze0.bitnet)


-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 18:41:35 GMT
From:      geoff@USAFA.ARPA (Capt Geoff Mulligan)
To:        comp.protocols.tcp-ip
Subject:   VMS TCP/IP software news

We have a number of VAXen connected via an ethernet and would like to
get them talking to our tcp/ip systems  Do you have any pricing
information yet and what about government or educational discounts?
We presently have Wollongong's software running on one of our systems
and I am not satisfied with it; plus it is so expensive.

geoff


-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 19:29:01 GMT
From:      bobn@ism780c.isc.com (Robert Noh)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   TCP/IP on VMS 5.0

Is there any implementation of TCP/IP that is ready to go
on VMS 5.0?  Or, is there an implementation that is
due to be released "real soon, now?"

(Rumor has it that SRI's Multinet runs on 5.0.  Can anyone
confirm this?)

On a related note, does anyone have a list of TCP/IP implementations
that run on a multiprocessor machine?  This is more for a reference
than anything else, but I still would like the information.

mail responses will be summarized to the net.

Robert Noh              {sdcrdcf|attunix|microsoft|sfmin}!ism780c!bobn


-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 19:44:50 GMT
From:      R1ECGF@AKRONVM.BITNET (Doug Greenwald)
To:        comp.protocols.tcp-ip
Subject:   HP TCP/IP Conformance


Hi,

A few weeks ago, i saw something mentioned concerning problems with
HP systems with TCP/IP.  Something about problems getting HP's to work
with various gateways.  I would appreciate seeing this info again.  We
are currently looking at various vendors for networkable workstations,
an HP is one of the contenders, if you or they can show us that thier
workstations support TCP/IP and/or Ethernet networking with minimal

Please respond directly to me and I will sumarize to the net if there is
sufficient interest.

Doug Greenwald
Engineering Computer Graphics Facility
University of Akron

Bitnet:  R1ECGF@AKRONVM


-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 20:14:11 GMT
From:      Crispin@SUMEX-AIM.STANFORD.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Can anyone help this guy?

Hi, I got this note from a friend of mine in Tokyo (edited to remove
unnecessary text).  Can anyone help him out?  Thanks, -- Mark

Date: Mon 1 Aug 88 21:42:37
From: ken-ichiro murakami <MURAKAMI@NTT-20.NTT.JP>
Subject: Proxy ARP on SUN

Mark,

I have a question about Proxy ARP. My colligue in Tohoku University
wants to use Proxy ARP on SUN. As far as I know, there are two Proxy
ARP software. One is developed in U-texas and the other is developed
by Barry Shein(bzs@bu-cs.bu.edut). I've alreay seni, I got this note from a friend of mine in Tokyo (edited to remove
unnecessary text).  Can anyone help him out?  Thanks, -- Mark

Date: Mon 1 Aug 88 21:42:37
From: ken-ichiro murakami <MURAKAMI@NTT-20.NTT.JP>
Subject: Proxy ARP on SUN

Mark,

I have a question about Proxy ARP. My colligue in Tohoku University
wants to use Proxy ARP on SUN. As far as I know, there are two Proxy
ARP software


-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 21:05:55 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Furreign tongue

Lars:

Dansk is not necessarily a furreign tonque--my basic problem was the
communications software for my PC at home does not provide immediate
interpretation of the european character sets.  The most made out of
your discussion was that support for the ACP6250 was provided and
available from some vendor in Stockholm.

Merton


-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 21:16:57 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP over X.25 under Unix ?

Lars:

My CIT224 seems to be brain-damaged.  Is the "}" the "a" with the "o" on top
and the "|" a "o" with a "/"?  These were the only characters that wouldn't
translate correctly.

Merton


-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 22:07:00 GMT
From:      enger@BLUTO.SCC.COM
To:        comp.protocols.tcp-ip
Subject:   VMS TCP/IP software

Geoff:

I will have to concur that Wollongong is expensive, but to some extent
you get what you pay for.  Those guys send engineers to all the networking
conferences.  TWG seems to be incorporating some of the more important
protocol enhancements into their products in a timely fashion.  Their version
3.2 software incorporates the Van Jacobson window adjustment scheme.

We use version 3.2 and are pretty happy with it.  When all I can find to
complain about is CC: fields in the mailer (and thats a VMSmail problem really)
it can't be too bad a product, right?

The capability to keep up the with latest developments may become increasingly
important.  The ability to respond to Usage Sensitive Charging by incorporating
a more efficient telnet may be a big win to your budget.  If you use the TWG
package to connect to the wide area subnet you may appreciate their support
when BBN womps PSN 7.0 on you :-) .

Although I am not a user of the product, I have heard generally good reports
on the Multinet product.  This product was (maybe still is) available from
SRI.  I believe two of its developers have left SRI to persue the further
developement and enhancement of the product.  You may wish to review the
recent TCP/IP archives to locate them.

Bob Enger
Contel Federal Systems


-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 23:25:49 GMT
From:      microsoft!jonsm@beaver.cs.washington.edu  (Jon Smirl)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Microsoft MAC/Vector interface

|  1. You do all of your binding (setting up handlers for incoming packets)
|  at CONFIG.SYS time, so you can't use many DOS (or OS/2) services while

At OS/2 config.sys time a driver can actually do an awful lot *more* than
it can after config.sys time.  This is because it is running at ring 3 at
that time and can do file i/o for example.  After init, all driver code is
ring 0 and can't do any os services except devhlps.  If the above
remark is really about wanting to write protocol code to live at ring
3, this can actually be done within the present structure--see the
response to point 2 below.

Note that we will in the future be extending the protocol manager to add
dynamic binding and unbinding.    The current bind command logically can do
that today; all that is missing is the unbind command and a way to ask the
protocol manager to issue a binds and unbinds at run time.

In fact, the version 2 protocol manager spec will allow for several
run time functions, including dynamic binding, unbinding, and query/change
module config settings.  Ring 3 APIs to the protocol manager will let
applications invoke these services.

|
|  2. You cannot un-bind, ever.  No transient network protocols built into
|  programs, no un-loadable protocol TSRs.  Instead, you have to edit a file
|  & reboot if you need more memory to run your CAD program or whatever....

See note about our planned bind/unbind extensions above.

Regarding transient protocols--on OS/2 you can do this by writing a stub
protocol module that interfaces to a ring 3 protocol daemon.  The daemon
would ioctl threads down to the stub to get requests and pass back
responses--or better, ioctl down the address of a shared memory area where
request queues could be managed between ring 0 and 3.  A similar thing
could be done on DOS 3.

could bring in the actual protocol code as an EXE which certainly
could terminate and free its memory.

Regarding "editing a file" to reconfig:  there is no requirement for a
module to take its config from protocol.ini, or to do it only at boot
time.  Modules can use private means to get config, including doing it
dynamically at run time via ioctls to the driver or whatever.  Modules can
be written to even resize themselves when run time reconfig happens--ie, if
they dynamically allocate their buffer space, or have an app-level daemon
do this for them.  (All this is saying is that if you are creative you
can even get the effect of dynamic reconfig sooner than when we provide
a standardized way for doing it).

|
|  3. Rather than telling MAC/Vector what kind of packets you want, instead
|  it goes down its list of handlers, asking them one after another "do you
|  want this packet".  This means that there is no possibility of
arbitration
|  (or even error detection) when two applications want the same type, and
|  opens the door for "badly behaved applications" to screw things up for
|  the rest of us.
|

We considered providing a way to provide packet dispatch info to the
vector, but providing adequate flexibility here was far more complexity
and overhead than seemed justified by the need.  What does it mean to tell
it "what kind of packet you want"--do you specify what the source address
should be, or destination SAP, or both, or some bit masked address compare,
or do you also want to include specific packet command codes, or protocol
type bytes, or other compare conditions, or what?  Cases can be made for all
these and more, and that just leads to absurd complexity for a
little-needed function.  In general it is a "configuration error" to have
two drivers installed that would conflict over what packets they want;
indeed, all that a complex descriptor mechanism would do is let you detect
this configuration error.  That would be nicer than not detecting it, but
again, the amount of overhead to detect this rather unusual error
condition did not appear justified.  The current polling scheme works just
fine for what we believe the 99% case to be--protocols sharing a mac where
the conflicts don't arise.  We are interested in any concrete suggestions
on what a better solution would be, or why there is some important need
not addressed by the current solution.

microsoft!jonsm

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 88 00:07:46 GMT
From:      Crispin@SUMEX-AIM.STANFORD.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Proxy ARP question

It appears that my message got damaged on the way out.  Anyway,
MURAKAMI@NTT-20.NTT.JP (or %NTT-20.NTT.JP@RELAY.CS.NET) is trying to
get ahold of software that supports Proxy ARP and is having problems.
He isn't directly on the Internet.  Can anyone help him?
-------


-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 88 13:36:48 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: How many people receive TCP-IP

enger@GBURG.SCC.COM writes:
> An easy way to get a start at the determination is to look at the main
> distribution list at the NIC. [...] some of those direct recipients are
> mail exploders. [...] perform the above process iteratively to get some
> idea of the ultimate number of recipients.

And then, don't forget to add in all the people who read TCP-IP as
its usenet alter ego, comp.protocols.tc-ip.  The most recent stats from
Brian Reid (which somehow I missed the first time around, for no reason
that I can explain) estimate that something like 9800 people see this
material in that forum.  My guess is that that far outweighs the count of
people who are on the mailing list, either directly or via mail exploders.
--
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"


-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 88 14:08:48 GMT
From:      root@sbcs.sunysb.edu (root)
To:        comp.protocols.tcp-ip
Subject:   BOOTP vendor support

I am in the midst of implementing network bootstrap code for
our Amiga NFS product.  I have the new Sun bootparams bootstrapper
stuff going, but it seems to fall short of what is really needed.
In particular we're a bit worried that Sun requires use of RARP
in bootstrapping and that casual perusal of vendor glossies shows
not much support for RARP by vendors other than Sun (and NFS licensees).

BOOTP seems to be a whole notch better in the sense that it is
a simpler protocol, it supplies HDW -> Internet address translation
without using RARP, and using the vendor specific field (RFC-1048)
seems to provide everything a booting machine needs eg subnet mask,
UTC time offset, name server locn, etc.  Since BOOTP doesn't use
RARP we can provide portable source to our customers who do not
have it.  Now, the question: who else is/will support BOOTP?  The
only other vendor I've seen supporting BOOTP is SGI.  Is BOOTP
a dead end in light of Sun ASI, etc?

While I've got your attention, is anyone aware of any efforts towards
automating IP address generation?  It would seem a natural extentsion
to either RARP or BOOTP, modulo the usual database consistency
problems.

Rick Spanbauer
Ameristar


-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 88 15:48:30 GMT
From:      rochester!srs!dan@bbn.com  (Dan Kegel)
To:        tcp-ip@sri-nic.arpa
Subject:   TCP/IP and NFS for MacOS?
I'm asking this on behalf of a friend at a large defense contractor, who
doesn't have internet access (but does have lots of pretty missiles and guns).
He'd like to use his Unix boxes as file and CPU servers, and use a mix
of Mac SE and Mac 2 boxes as clients; Ethernet would be use to connect
everything.

We think there is an Ethernet card for the SE, so that's not a problem.

The question is software.  We know about TOPS; however, it hasn't yet been
ported to his particular Unix box.
Can anybody suggest TCP/IP and (oh, please) NFS (that's Sun's Network File
System) packages that run under the Mac OS?  Or any other networking
alternatives?

Thanks...
--
Dan Kegel   "We had to get it passed before the columnists attacked!"
srs!dan@cs.rochester.edu  rochester!srs!dan dan%srs.uucp@harvard.harvard.edu

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 88 18:56:03 GMT
From:      jch@CHUMLEY.TN.CORNELL.EDU (Jeffrey C Honig)
To:        comp.protocols.tcp-ip
Subject:   Re: Again: looking for gated

Gated is available for annonymous FTP from devvax.tn.cornell.edu as
pub/gated/gated.tar.Z.

Gated is available via electronic mail by sending mail to
gated-people-archive@devvax.tn.cornell.edu with a subject line of

get gated.tar.*

Several pieces of mail will be sent to you which comprise a split,
uuencoded, compressed tar file.

Questions and experiences relating to gated may be sent to the gated
mailing list, gated-people@devvax.tn.cornell.edu.  Requests for addition
to the list should be sent to gated-people-request@devvax.tn.cornell.edu.

Jeff


-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Aug 88 21:59:26 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: a proposed modification to ARP

In article <19880727152537.7.DCP@SWAN.SCRC.Symbolics.COM> DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) writes:
>... Networks
>are a LOT LOT bigger and broadcasts are on people's mind, whether it's a
>real problem or not.

Actually, it has always seemed to me that ARP -- the mapping between physical
addresses and logical ones, so to speak -- was the one place where use of
local broadcast was proper and defensible.  I personally would put ARP last
on the list of broadcast problems to be fixed, and a number of other things
much higher.  I have trouble believing that ARP by itself, if it were the
only use of broadcast, would be a real problem.  Is it really so?
--
MSDOS is not dead, it just     |     Henry Spencer at U of Toronto Zoology
smells that way.               | uunet!mnetor!utzoo!henry henry@zoo.toronto.edu


-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 00:43:25 GMT
From:      bdale@hpcsrc.HP.COM (Bdale Garbee)
To:        comp.protocols.tcp-ip
Subject:   Re: a proposed modification to ARP

>Let's also remember that ARP runs on 5 networks other than Ethernet
>(Experimental Ethernet, AX.25, ProNET, Chaosnet, and ARCNET)

Not to mention Amateur Radio AX.25 ala the KA9Q package.


-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 10:57:40 GMT
From:      DEDOUREK%UNB.CA@CORNELLC.CCS.CORNELL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Re: How many people receive TCP-IP

> enger@GBURG.SCC.COM writes:
> > An easy way to get a start at the determination is to look at the
> main > distribution list at the NIC. [...] some of those direct
>
>    And then, don't forget to add in all the people who read TCP-IP as
> its usenet alter ego, comp.protocols.tc-ip.  The most recent stats

Ditto the BITNET LISTSERV service.

John DeDourek, University of New Brunswick, Fredericton, N.B. Canada
dedourek@unb.ca  (dedourek@unb.bitnet)


-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 13:44:39 GMT
From:      dd@sei.cmu.edu (Dennis Doubleday)
To:        comp.protocols.tcp-ip
Subject:   Question about TCP/IP on VMS


I currently have an application running on Ultrix which uses TCP/IP.
Each machine in the network has a server running on it.  The server is
opened in passive mode and listens at a known port for traffic.  Under
Ultrix this "known port" is defined by adding an entry for my server
into the file /etc/services.  How is this done under VMS?  How are the
well-known ports defined?  Or does this depend on the TCP/IP software
you have?


-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 15:22:51 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Microsoft MAC/Vector interface

The message from microsoft!jonsm was presumably a mis-posting, since it
replied to something I had said on pcip@udel.edu (comp.protocols.tcp-ip.ibmpc).
Unless people are interested, I won't debate DOS & OS/2 arcana here.

James VanBokkelen
FTP Software Inc.


-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 16:25:54 GMT
From:      mark@cbnews.ATT.COM (Mark Horton)
To:        comp.protocols.tcp-ip
Subject:   Re: ACSNET Access

In article <644@stcns3.stc.oz> dave@stcns3.stc.oz (Dave Horsfall) writes:
>Dave Horsfall (VK2KFU), Alcatel-STC Australia, dave@stcns3.stc.oz

as dave@stcns3.stc.oz, as shown in the From: line and the signature of
the referenced article.  .oz is NOT an official domain, while .oz.au IS.

The UUCP map does list .oz and knows how to get to it.  This puts .oz up
there with the other "semi-official" domains like .uucp, .bitnet, .cdn,
and the like.  People routing via UUCP can get to them, but people using
some other incarnation of the domain system, especially TCP/IP, cannot.

Posting to a worldwide computer network with an incomplete domain name
is like giving your phone number and forgetting the country code.  It
might work locally, but it doesn't necessarily work in some other country.

Please encourage other Australians to use the full name .oz.au on their
domain style addresses, unless they are really sure that the context is
specific to ACSNET.

>dave%stcns3.stc.OZ.AU@uunet.UU.NET, ...munnari!stcns3.stc.OZ.AU!dave

This stuff looks fine, although both are kludges to get around various
limitations when you're trying to say dave@stcns3.stc.OZ.AU .  If this
form doesn't work, then something is broken somewhere (or maybe the
person you're sending to just doesn't answer their mail.)

Mark


-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 16:44:35 GMT
From:      dennis@rlgvax.UUCP (Dennis.Bednar)
To:        comp.protocols.tcp-ip
Subject:   subnet IP mask stored in route or interface struct?

Does 4.3BSD store the IP subnet mask in the route structure
(struct rtentry) or the interface structure (struct ifnet)?
The reason I ask, is that RFC 950 suggests that it be stored
on a per interface basis.  However, I have found a particular
case (described below), in which it is better to store the mask
on a per route basis.  Perhaps the example I have contrived
violates an unmentioned assumption that subnets in the same

In the figure below, the ---- lines represent a single physical
ethernet cable. Gw1, and gw2 stand for gateway 1 and gateway 2.
Both gw1 and gw2 below have multi-homed IP addresses (that is two
separate home addresses, one for each network connection).
In the figure below, subnet1 and subnet2 (in the same network)
are separated apart by a different network, consisting of just
a single subnet. Subnet 1 and 2 below are class C network addresses
containing 3 bytes of <network-number>, and 4 bits for the <subnet-number>.
The network in the middle is a class B network composed of 2 bytes
of <network-number>, and 4 bits for the <subnet-number>.

gw1		    gw2
--------------------	------------	------------------
Name	subnet1			network		subnet2
Number	192.7.8.0x10		128.5.0x10	192.7.8.0x20

The problem with using the IP mask for an interface is that
gw2 above will have trouble forwarding packets destined for hosts
in subnet1.  Suppose there is packet destined for host
192.7.8.0x11.  I will show the problem after giving some
background information.

------ Begin of some background information:

There is presumed to be 3 tables of routing table structures
containing
<destination,	gateway,	flags, interface-ptr>.
These 3 tables are the host routing table, the subnet routing
table, and the network routing table.  Destination is the
IP address of a host (if in host routing table), of a subnet
(if in subnet routing table), or of a network (if in netowrk
routing table). The flag indicates if the route is direct (ie
through a local gateway or the home machine) or indirect thru
a remote gateway (ie the flag is used instead of the
recommended algorithm described in RFC950 to decide if the
packet should be sent directly or thru a gateway).  The interface
pointed to by interface-ptr is presumed to contain (at a minimum):

The 3 tables are searched in this order: host, subnet, network, using
the dg.ip_dest as a key into the route.destination field.  For a
host table search, all 4-bytes are compared.  The subnet table search
is described separately below.  The network table search compares
ip_network_of(dg.ip_dest) with route.destination. The search stops
when a route has been found. The subnet table search is this:

for each subnet routing table entry
if (route.dest == (dg.ip_dest & route.interface.my_ip_mask))
{
found = routing table entry;
break;	/* stop table search */
}

Once the route has been found, the route.flag tells whether to send
directly or through a gateway, as opposed to the recommended algorithm
described in RFC950.

---- end of background information

Now here is the problem: the subnet table search on gw2 above will
fail to locate the route entry in its subnet table, because the ip_mask
will strip off too many bits (2.5 bytes) causing the compare of
route.destination in the subnet table to fail:
if (192.7.8.0x10 == (192.7.8.0x11 & 255.255.0xf0.0))
if (192.7.8.0x10 == (192.7.0.0))

I would like to point out that by storing an IP mask on a per route
basis, this problem would go away, since the IP mask would be correct
for the destination subnet, which is remote to this particular network.

I would appreciate any comments on this matter.
--
FullName:	Dennis Bednar
UUCP:		{uunet|sundc}!rlgvax!dennis
USMail:		CCI; 11490 Commerce Park Dr.; Reston VA 22091
Telephone:	+1 703 648 3300


-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 16:58:07 GMT
From:      sow@eru.mt.luth.se (Sven-Ove Westberg)
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Whois sources.


I would be very pleased to know where I could get programs
to Unix for the tcp/whois protocol and database?

Regards,

Sven-Ove Westberg, CAD, University of Lulea, S-951 87 Lulea, Sweden.
Tel:     +46-920-91677  (work)                 +46-920-48390  (home)
ARPA:    sow%cad.luth.se@ucbvax.berkeley.edu  (only dumb ARPA mailers)


-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 17:25:32 GMT
From:      wunder@SDE.HP.COM (Walter Underwood)
To:        comp.protocols.tcp-ip
Subject:   Re: HP TCP/IP Conformance


A few weeks ago, i saw something mentioned concerning problems with
HP systems with TCP/IP.  ...

We are currently looking at various vendors for networkable
workstations, an HP is one of the contenders, if you or they can
show us that their workstations support TCP/IP and/or Ethernet

I think this is worth answering to the whole list.  HP's Unix
machines do implement a full TCP/IP, and do work with other systems.
The networking is based on 4.2 BSD, and will be upgraded to use the
Van Jacobson algorithms at the earliest possible time.

[The Unix boxes are the HP9000 Series 300 (68000-based) and HP9000
Series 800 (RISC-based).  HP's name for their Unix OS is HP-UX.]

The HP3000 minicomputers (runnning MPE) use a limited version of the
TCP/IP protocols.  They do not support UDP, use real 802.3 instead
of Ethernet, and use HP Probe instead of ARP.  HP is working on
Ethernet and ARP for the HP3000.

The HP3000 uses proprietary login and file transfer protocols.
Regular ARPA services (Telnet, FTP, and SMTP) are available from The
Wollongong Group.

The HP1000 runs a TCP/IP which is similar to the HP3000, but the
1000 already support Ethernet, I believe.

If you have MPE systems, you need a gateway that talks 802.3 and
Probe.  The only gateways that do that are the HP9000 series 300 and
series 800 machines (HP-UX), and boxes from cisco Systems, Inc.

Walter Underwood
HP Software Engineering Systems
Palo Alto, CA

PS: HP-UX can set Precedence and Security on TCP connections.
Anybody wanna try it?


-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 17:29:04 GMT
From:      deke@valhalla.ee.rochester.edu
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Status of NTP?


What is the status of NTP?  I have rfc958, is this the most (and
only) relevant document?

I would like to keep 35 or so machines on my networks time-synched
*with eachother*..... having that common time be "correct" is
icing on the cake.  Up till now I have tried using 4.[23]BSD timed
and /usr/ucb/rdate on UN*X machines, and they work fine, but I
certainly wouldn't mind using a more elegant method.

- Deke Kassabian
-------------------------------------------------------------------------------
\ deke@ee.rochester.edu                  "Experience is something you don't   /
\   or ...!rochester!ur-valhalla!deke     get until just after you need it."  /
\-----------------------------------------------------------------------------/


-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 17:47:27 GMT
From:      ted@ultra.UUCP (Ted Schroeder)
To:        comp.protocols.tcp-ip
Subject:   Re: How many people receive TCP-IP

enger@GBURG.SCC.COM writes:
> An easy way to get a start at the determination is to look at the main
> distribution list at the NIC. [...] some of those direct recipients are
> mail exploders. [...] perform the above process iteratively to get some
> idea of the ultimate number of recipients.

ames!nyu.edu!phri!roy  (Roy Smith) writes:
>	And then, don't forget to add in all the people who read TCP-IP as
> its usenet alter ego, comp.protocols.tc-ip.

Ted Schroeder                   ultra!ted@Ames.arc.nasa.GOV
Ultra Network Technologies
2140 Bering drive               with a domain server:
San Jose, CA 95131                 ted@Ultra.COM
408-922-0100


-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 21:34:22 GMT
From:      kwang@bud.UUCP (Kwang Sung)
To:        comp.protocols.tcp-ip
Subject:   Re: Van Jacobson's Algorithm for AT&T Stream Implementations

I hope someone on the net can answer to my question.
I am curious that whether we can apply Van Jacobson's Algorithm to
AT&T Stream TCP/IP implementations easily.
I would like to know more detail about Van Jacobson's Algorithm clearly.


-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 22:13:09 GMT
From:      kwang@bud.UUCP (Kwang Sung)
To:        comp.protocols.tcp-ip
Subject:   Re: Difference between 4.3 BSD and 4.4 BSD, and between V.3 and V.4

I hope someone can answer to my question.
I would like to know difference between 4.3 BSD and 4.4 BSD, and
between AT&T V.3 and AT&T V.4, in terms of networking implementations.


-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 00:02:30 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re: HP TCP/IP Conformance


From: Walter Underwood <wunder@sde.hp.com>

I think this is worth answering to the whole list.  HP's Unix
machines do implement a full TCP/IP, and do work with other systems.
The networking is based on 4.2 BSD, and will be upgraded to use the
Van Jacobson algorithms at the earliest possible time. ...

I am not sure that anything based on 4.2BSD is full TCP/IP' (unless it
has had all the 4.3BSD fixes added), but in any case, 4.3BSD is
available for the HP9000 Series 300, from the University of Utah.

Chris


-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 00:14:22 GMT
From:      amdahl!bungia!datapg!questar!bthpyd!wiebe@ames.arc.nasa.gov  (Glen Wiebe)
To:        tcp-ip@sri-nic.arpa
Subject:   Micom-Interlan NP100 ethernet woes

We are in the process of installing a couple of Micom-Interlan
NP100 ethernet boards in two VAX 750s.  One I can get working and the
other I cannot.

The VAX 750 on which it works has disks connected to an Emulex
massbus disk controller.  The VAX 750 on which I have trouble has one
RA81 disk on a DEC UDA50 disk controller. (I suspect this may be the
problem).  We are running the original 4.3bsd release.

When powering up the system the NP100 goes through a series
of internal self diagnostics.  It never completes these successfully
and the driver (ix0) for the NP100 cannot reset it (it times out
waiting for a response).  The NP100 board is ok since it works fine
in the other VAX.

Does anyone have ideas on what the problem might be?
Thanks.

--------
Glen J. Wiebe				UUCP	rutgers!bungia!bthpyd!wiebe
Bethel College, St. Paul, MN		ATT	(612) 638-6106

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 00:52:00 GMT
From:      mogul@DECWRL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: subnet IP mask stored in route or interface struct?

Does 4.3BSD store the IP subnet mask in the route structure
(struct rtentry) or the interface structure (struct ifnet)?
The reason I ask, is that RFC 950 suggests that it be stored
on a per interface basis.  However, I have found a particular
case (described below), in which it is better to store the mask
on a per route basis.  Perhaps the example I have contrived
violates an unmentioned assumption that subnets in the same

Yes, but this is not so much an "unmentioned assumption" as it is
a rule that is not stated in the most obvious place.  As an author
of RFC950, I suppose I must take the blame for not repeating in
RFC950 this statement from the first page of RFC940:

The use of subnets is an optional local decision.  The fact that a
network has subnets is invisible outside that network, and the change
is local and can be instituted at a site without any global Internet
perturbations.  A complex of links is assigned a single IP network
number, and outside that complex it appears as a single network with
that number.  Only inside does local structure appear.

[Note that the first paragraph of RFC950 says, in effect, "read RFC940."]

Following this rule, the "particular case" is in violation:

--------------------gw1----------------gw2------------------
Name	subnet1			network		subnet2
Number	192.7.8.0x10		128.5.0x10	192.7.8.0x20

because the distinction between subnet1 and subnet2 would have to be
visible outside network 192.7.8.0 in order for things to work.

Solutions: Use different Class C numbers for the two isolated pieces,
or tie them together with a gateway connected to both subnets.  The latter
solution is less likely to fill up other people's routing tables.


-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 02:29:56 GMT
From:      wunder@SDE.HP.COM (Walter Underwood)
To:        comp.protocols.tcp-ip
Subject:   HP TCP/IP Conformance


I am not sure that anything based on 4.2BSD is full TCP/IP' (unless it

I agree, and the people that work on our TCP agree.  We have fixed the
behavior, but it is still a 4.2 programming interface.  That is why I
pointed out the 4.2 heritage.  Geez, I'd almost forgotten how bad 4.2
was ...

wunder


-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1988 06:50-EDT
From:      CERF@A.ISI.EDU
To:        rochester!srs!dan@BBN.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: TCP/IP and NFS for MacOS?
I have been given to understand that there is a Unix for the MAC.
If that is true, NFS should be available as well. The MAC Unix
is called AUX, I believe. I don't have a point of contact, but
the product is supported by Apple, I believe.

Vint Cerf

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 03:09:56 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Status of NTP?

Deke,

See RFC-1059. Then, you might want to talk to Mike Petry, who has a 4.3bsd
daemon which is now chiming at a few dozen systems just now. Also, a bunch
of new radio clocks have come up, making the total at least seven going
on nine. Depending on your confidence and precision required, you might
want to run NTP on only a few of your machines and timed on the rest; however,
NTP depends for robustness on having a number of peers and using a weighted
selection algorithm to cast out the falsetickers.

Dave


-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1988 07:19-EDT
From:      CERF@A.ISI.EDU
To:        rochester!ur-tut!ur-valhalla!deke@CU-ARPA.CS.CORNELL.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Status of NTP?
Deke,

NTP RFC 1059 dated July 88 just released. RFC 1059 is an elective
protocol and the RFC is in DRAFT STANDARD status.

Vint Cerf

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Aug 88 12:02 EST
From:      <JFISHER%USGSRESV.BITNET@CUNYVM.CUNY.EDU> (James R. Fisher)
To:        tcp-ip@sri-nic.arpa
Subject:   tcp/ip for Amdahl UTS
Hello:

We will soon be running Amdahl's UTS (Unix) version 1.2 under VM/HPO
on an Amdahl 5890.
We want a tcp/ip implementation for it; I'd be happy to hear from
anyone out there who knows any vendors of tcp/ip for such an environment.

Thanks much.
Jim Fisher
jfisher@usgsresv.bitnet

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 10:50:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and NFS for MacOS?

I have been given to understand that there is a Unix for the MAC.
If that is true, NFS should be available as well. The MAC Unix
is called AUX, I believe. I don't have a point of contact, but
the product is supported by Apple, I believe.

Vint Cerf


-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 11:19:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Status of NTP?

Deke,

NTP RFC 1059 dated July 88 just released. RFC 1059 is an elective
protocol and the RFC is in DRAFT STANDARD status.

Vint Cerf


-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 13:11:48 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and NFS for MacOS?

This month's BYTE has a rather scathing set of articles on A/UX - Unix
for the MAC.  A/UX appears to be closest to system V than any of the
other UNIXs.

But hold on to your wallet - it costs either $5000 or$10,000
depending on your system configuration - this is *without* source code
(which does not appear to be available at this time)

Mike


-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 13:25:00 GMT
From:      LENTZ@NUACC.ACNS.NWU.EDU ("Beat the system, pull the plug.")
To:        comp.protocols.tcp-ip
Subject:   TCP-IP for AT&T UNIX-PC 7300's

Subject: TCP-IP for AT&T UNIX_PC 7300's

I hope someone can help me.  I am a student in the Integrated
Science Program at Northwestern University and we would like to hook our
7300's to the local campus network.  This requires TCP/IP software, which
we do not know where to obtain.  Can anyone make any recommendations?  Also
can the 7300 handle a 19200bps line for the connection?  I seem to remem-
ber some discussion regarding this problem a couple of weeks ago but
skipped over it at that point as it was not relevent then.  Will modifications
to the daemons help reduce the overhead so that the 7300 will be able to
keep up with the traffic it must handle?  Please excuse any ignorance on my
part as I am still new to  UNIX and the 7300's.  Thanks.

Robert Lentz
Bitnet: Lentz@Nuacc
Internet: Lentz@Nuacc.Acns.Nwu.Edu

P.S.   If anybody can recommend a good source for MMDF or another good mail
program this would also be appreciated.


-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 13:52:09 GMT
From:      ooblick@lts.UUCP (Mikki Barry)
To:        comp.newprod,comp.protocols.tcp-ip,comp.sys.mac
Subject:   TCP/Connect - NCSA Telnet Plus Support

Learning Tree Software, Inc. would like to announce the formation of
a new company:  InterNet Systems Corporation.  ISC is modifying the
existing NCSA Telnet for the Macintosh to produce new and nifty features,
and is offering telephone support.  We will begin shipping this new product
Sept. 1.

The price of $495 (with substantial discounts for multiple copies) includes an updated manual, the software, and one year of telephone support. Current NCSA Telnet users can contact us for special pricing. (703) 435-8170. Until InterNet Systems Corp. gets on the net, LTS will forward mail sent to uunet!lts!comment. InterNet Systems Corp. will be at MacWorld sharing the Kinetics booth. We will have a special show discount for this product, as well as RealTalk, a new and nifty product similar to "talk" on Unix systems. It also includes a file transfer program, and window servers. Current pricing is$79.95 for one, or $219.95 for a three pak (in a peachy keen binder that will light up your bookshelf). It has so many neato features that you really should come see it at MacWorld. Mikki Barry Grand Poohbah  -----------[000044][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 14:02:16 GMT From: jqj@HOGG.CC.UOREGON.EDU To: comp.protocols.tcp-ip Subject: Ken Olsen on TCP/IP  Quoted without permission from Digital News, August 1, 1988: "Our attitude with TCP/IP is, 'Hey, we'll do it, but don't make a big system, because we can't fix it if it breaks.'" Does this reflect a lack of confidence in the Ultrix group?  -----------[000045][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 14:18:57 GMT From: jas@proteon.COM (John A. Shriver) To: comp.protocols.tcp-ip Subject: subnet IP mask stored in route or interface struct?  Your configuration is illegal per RFC 1009. To quote: The interconnected LANs of an organization will be given the same network number but different subnet numbers. The distinction between the subnets of such a subnetted network must not be visible outside that network. Thus, wide-area routing in the rest of the Internet will be based only upon the <Network-number> part of the IP destination address; gateways outside the network will lump <Subnet-number> and <Host-number> together to form an uninterpreted "rest" part of the 32-bit IP address. The whole point of subnets is to provide a LAYERED, HEIRARCHICAL approach to routing. Anyone outside the subnetted network must be able to route solely on the basis of network number. Hosts on your network 128.5 cannot do this. Your configuration does not work because it is illegal. It is surely possible to envision all sorts of ways of "solving" this supposed problem. But then you will fail to solve the problem that subnetting was intended to solve. That problem was that routing at the upper (network) layer was overloading from too many networks. Subnets, by hiding a layer of the network topology, solved this. The restrctions of subnets are readily dealt with by proper (sub)network design. [The same approach was applied to DECnet in Phase IV, with areas. What you are asking for is the equivalent of allowing node 7.33 in DECnet to plopped down in the middle of area 5 and have it work.]  -----------[000046][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 14:40:03 GMT From: jbvb@VAX.FTP.COM (James Van Bokkelen) To: comp.protocols.tcp-ip Subject: Precedence & IP Options (was: HP TCP/IP Conformance)  I can testify that HP UX doesn't have the 4.2 "crash on unknown IP option" bug (which at least a couple of other 4.2-derived Unices still have). If you (or anyone else) have Internet hosts which you would like to check out with TCP using Precedence and the IP Basic & Extended Security options, send me mail, giving the name & IP address, and any other constraints you would like to impose (I will not be able to deliver on 'a phone call before you try it'). Commercial IP routers from Proteon, and the MIT C-gateway, are known to forward packets containing these options. 4.3 Unix and cisco terminal concentrators handle them correctly at the application layer, so I have hopes that 4.3 & cisco routers will forward them as well. If you are connected to the Internet via a 4.2-based router, it may fail to forward the packets, or even crash. I will reply with e-mail declaring a time when I will do the testing (which can interrupt operations on some hosts, e.g. SunOS 3.4 and Ultrix 2.0). I will use ICMP Echo Request and TCP (usually finger, Telnet or SMTP if finger isn't supported) to test behaviour. Symptoms I have observed while testing the Basic & Extended security options include: Go deaf to the net for 5 minutes on either Ping or TCP (but not crash) Ignore Ping, crash on TCP or UDP. Ignore Ping and TCP. Ignore Ping, Reset attempted TCP connections. Ignore Ping, open TCP connections ok. Reply w/o option to Ping, open TCP connections ok. Reply w/option to Ping, ignore TCP connection attempts. Reply w/option to Ping, Reset attempted TCP connections. Reply w/option to Ping, open TCP connections ok. The current list of implementations that I have observed correctly supporting TCP with IP Precedence is: Wiscnet on IBM VM systems. KA9Q on IBM PCs. PC/TCP v2.03 (in beta test). The list of implementations which I have observed as unable to handle the RFC-1038 IP Security options will appear later this month. James VanBokkelen FTP Software Inc. (617) 868-4878 jbvb@vax.ftp.com  -----------[000047][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 15:52:28 GMT From: don@SRI-LEWIS.ARPA (Donald Holman) To: comp.protocols.tcp-ip Subject: Re: TCP/IP and NFS for MacOS?  > Mike St. Johns writes: > > But hold on to your wallet - it costs either$5000 or $10,000 > depending on your system configuration - this is *without* source code > (which does not appear to be available at this time) If this is indeed the cost, it might be less expensive to get source code from another place, and then pay a team of developers to adapt it for the new machine. Not necessarily a joke, but perhaps a semi scathing commentary on the price. these are my comments and are probably not the views of my employer. Don  -----------[000048][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 16:49:56 GMT From: tjb@Apple.COM (Tom Barrett) To: comp.protocols.tcp-ip Subject: Re: TCP/IP and NFS for MacOS?  In article <8808041311.AA03609@beast.DDN.MIL> stjohns@BEAST.DDN.MIL (Mike St. Johns) writes: >This month's BYTE has a rather scathing set of articles on A/UX Scathing...hmmm...in my humble interpretation, I would say perhaps lukewarm. The summary in the review says "...[A/UX is] a good first step toward the MacII into a Unix workstation." Anyway, lest I be accused of out-of-context quoting, it's best to judge for one's self. A recent issue of UNIX World had a fairly positive review (not sure which issue, sorry), as did the June 27 issue of UNIX Today (BTW, I am a contractor, not an Apple employee). >But hold on to your wallet - it costs either$5000 or $10,000 >depending on your system configuration - this is *without* source code I'm not sure if it's clear from this posting that these prices include the fully configured MacII (monitor, floppies, 80Mb hard drive, etc.). Those interested in details about A/UX can read or post requests to comp.unix.aux.  -----------[000049][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 17:02:00 GMT From: JFISHER@USGSRESV.BITNET (James R. Fisher) To: comp.protocols.tcp-ip Subject: tcp/ip for Amdahl UTS  Hello: We will soon be running Amdahl's UTS (Unix) version 1.2 under VM/HPO on an Amdahl 5890. We want a tcp/ip implementation for it; I'd be happy to hear from anyone out there who knows any vendors of tcp/ip for such an environment. Thanks much. Jim Fisher jfisher@usgsresv.bitnet  -----------[000050][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 17:17:27 GMT From: adelman@WARBUCKS.AI.SRI.COM (Kenneth Adelman) To: comp.protocols.tcp-ip Subject: Re: Question about TCP/IP on VMS  > I currently have an application running on Ultrix which uses TCP/IP. > Each machine in the network has a server running on it. The server is > opened in passive mode and listens at a known port for traffic. Under > Ultrix this "known port" is defined by adding an entry for my server > into the file /etc/services. How is this done under VMS? How are the > well-known ports defined? Or does this depend on the TCP/IP software > you have? Depends on the TCP/IP software you have. On MultiNet you add an entry to a text file which gets compiled into a binary database and loaded into a global section for fast access. On WINS/TCP I believe that you add an entry to the etc:[000000]services file just like under Unix. Well known ports don't HAVE to be defined in these files, it just makes it convenient because your code can reference the port by name instead of number. Kenneth Adelman TGV  -----------[000051][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 20:08:55 GMT From: timk@NCSA.UIUC.EDU (Tim Krauskopf) To: comp.protocols.tcp-ip Subject: Re: TCP/IP and NFS for MacOS  The misinformation is getting a little thick. AUX for Apple's Macintosh II is a port of System V with BSD networking, (I don't know how many 4.3 enhancements are in 1.0, 1.1 should be full 4.3BSD TCP/IP) other BSD enhancements and full NFS support. It works. Right now it is plain vanilla, X is coming, black and white only for now, Mac ToolBox graphics are available. The auto-config has everyone else's UNIX beat. Running AUX doesn't prevent you from running MacOS, just takes up a whole 80MB drive. AUX does NOT cost more than$1000.
If you buy two Mac II systems with identical hardware, one with AUX and
the other with MacOS (the original Macintosh operating system), then you
will find the cost of AUX is anywhere from $200 to$500 depending on
the hardware you actually buy.  Plus manuals, 6-foot set, isn't real
cheap, order separately.  If you call the extra expense of the hard
disk a part of the UNIX cost, then you haven't been running many Suns.

This is a full product line, dealers and everything, contact your nearest
AUX-certified Apple dealer or a sales office.

Below this line, I am referring to MacOS, NOT AUX.  For you PC users,
think of this as DOS vs. XENIX, one has the applications, the other
is UNIX.
------------------------

There is no commercial NFS for the Mac.  Cayman Systems (Cambridge, MA,
(617)494-1999) is releasing "real soon now" a box which converts NFS to AFP,
the Apple Filing Protocol standard for shared disks under MacOS.
NFS for MacOS in software is doable, primarily for Ethernet-equipped
Macs, no announcements that I know of.

TCP/IP for MacOS has been announced as "in development" at Apple in
Cupertino.  Target for release is before end of 1988.  Demos scheduled
for the TCP/IP Interoperability Conference in September.

There are no commercial releases of TCP/IP or TCP/IP applications for MacOS
shipping that I know of at the time I am writing this.  Before the end of
the year, expect 4 or more vendors to ship.

University products are available from Cornell, Brown, Illinois (NCSA),
Michigan, and Stanford, but some are restricted use.

I am biased, Anonymous FTP to 128.174.20.50 for release package and source
to NCSA Telnet for the Macintosh.  What can you lose, it's public domain?

I tried to stick to facts, but if there are any opinions above, they are
my own.

Tim Krauskopf                timk@ncsa.uiuc.edu (ARPA)

National Center for Supercomputing Applications (NCSA)
University of Illinois, Urbana-Champaign


-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 20:17:27 GMT
From:      john@twg-ap.UUCP (John Caughy)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Re: TCP/IP on VMS 5.0

From article <12515@ism780c.isc.com>, by bobn@ism780c.isc.com (Robert Noh):
>
> On a related note, does anyone have a list of TCP/IP implementations
> that run on a multiprocessor machine?  This is more for a reference
> than anything else, but I still would like the information.
>
The implementation for the HP 9000 500 series from Wollongong operates
in a multiprocessor environment.  The TCP/IP provides a single thread
for all users of the system and appears to be quite responsive.


-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 08:16:00 PDT
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   RE:  Van's algorithm's in Streams
This is in response to Kwang Sung's query:

Our newest version of Streams TCP contains Van's and Nagles algorithms
for congestion control, etc.  The header-predection performance code is
scheduled for addition, shortly, although we are still trying to understand
its impact under mixed traffic conditions.

Dave Crocker
VP, Engineering
The Wollongong Group


-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 09:37:00 PDT
From:      Leo J McLaughlin <ljm@twg.com>
To:        tcp-ip <tcp-ip@louie.udel.edu>
Subject:   802.3 routing
>>   A few weeks ago, i saw something mentioned concerning problems with
>>   HP systems with TCP/IP.  ...

>>   We are currently looking at various vendors for networkable
>>   workstations, an HP is one of the contenders, if you or they can
>>   show us that their workstations support TCP/IP and/or Ethernet

>The HP3000 uses proprietary login and file transfer protocols.
>Regular ARPA services (Telnet, FTP, and SMTP) are available from The
>Wollongong Group.

>If you have MPE systems, you need a gateway that talks 802.3 and
>Probe.  The only gateways that do that are the HP9000 series 300 and
>series 800 machines (HP-UX), and boxes from cisco Systems, Inc.

>Walter Underwood
>HP Software Engineering Systems
>Palo Alto, CA

The Wollongong Group also provides a product that allows a PC to function
as a gateway for MPE systems, WIN/ROUTE2.

leo j mclaughlin iii
The Wollongong Group


-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 06:09:43 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re: Difference between 4.3 BSD and 4.4 BSD, and between V.3 and V.4

4.4BSD does not exist.  There is a post-4.3-BSD release of TCP; it
is available via anonymous FTP from Berkeley.edu.  It implements
the Jacobsen/Karels' algorithms.

(The new TCP code is included in 4.3BSD-tahoe.)

Chris


-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 08:28:00 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip, root@sbcs.sunysb.edu
Subject:   Re: BOOTP vendor support

The only vendor that I know uses bootp is cisco.  Their gateways can
use it to get IP addresses.  (They can also use RARP - they send both
types of request, and believe whichever response they hear.)  They
also have the code needed to pass bootp requests across gateways.
I've never understood why other vendors don't use it, since it's
clearly easier to install than RARP, and more general.  I've not had
any trouble bringing up bootp on Unix systems, and it should also be
possible on Unix-based stuff like TWG's IP for VMS.  I'd be inclined
to use bootp anyway for any new products.


-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 1988 13:43-EDT
From:      CERF@A.ISI.EDU
To:        LENTZ@NUACC.ACNS.NWU.EDU
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: TCP-IP for AT&T UNIX-PC 7300's

FTP Software can supply PC-based TCP/IP if you are running MS/DOS.
FTP Software is in Cambridge, MA. There are undoubtedly other sources
of supply including freeware say from MIT/LCS.

The DDN Network Information center at SRI International is another
good place to check - they have a lengthy catalog of software
which they have compiled as "DDN Protocol Implementations and
Vendors Guide" NIC 50002. It is also available on-line at
SRI-NIC.ARPA.

MMDF is available from Prof. David Farber, University of Pennsylvania,
Computer and Information Systems: farber@cis.upenn.edu

Vint Cerf

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 16:51:00 PDT
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re:  Accidentally including the CC line
This is in reply to Bob <enger@gburg.scc.com> note:

Some people may have missed the trailing smile at the end of your comment
myself to use our VMS product, mostly out of masochism but partly so issues
such as the one you raise are familiar.  Keith McCloghrie works on a number
of our products, but not the VMS one, so he can affort the luxury of
using a Unix interface (MH, when last I checked).

Why should I burden everyone with this clarification?  Well, the problem
is that the VMS user interface to mail, with our TCP product, is standard
DEC issue, called VAXmail.  While we have integrated into it as best
possible, through their foreign service interface, we do not touch the basic
vaxmail product.

We are thinking of offering a richer mail system for a number of platforms,
but that is mostly my way of trying to find an excuse to use some old
but fondly rememebered experiences.

Another alternative, shortly, will be All-In-One.

Dave Crocker
The Wollongong Group


-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 10:36:55 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re:  Micom-Interlan NP100 ethernet woes

The NP100 driver included in 4.3BSD (presumably written by or for
Interlan; at any rate, it was not done at Berkeley) is egregiously
buggy.  A later revision of the driver (done after Berkeley got an
NP100) is available from Berkeley, either as part of 4.3BSD-tahoe or
separately.  Contact Keith Bostic <bostic@okeeffe.berkeley.edu> if you
need just the driver.

Chris


-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Aug 88 17:01 EST
From:      "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)", <LEICHTER@Venus.YCC.Yale.Edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Moderated Newsgroup Posting
Path: venus!leichter
From: leichter@venus.ycc.yale.edu
Newsgroups: mail.tcp-ip
Subject: Re: Ken Olsen on TCP/IP
Message-ID: <34@venus.ycc.yale.edu>
Date: 5 Aug 88 17:01:31 GMT
References: <venus mail.tcp-ip:1807>
Organisation: VMS NEWS V4.0
Lines: 32

In article <venus mail.tcp-ip:1807>, jqj@hogg.cc.uoregon.EDU writes:
> Quoted without permission from Digital News, August 1, 1988:
>
> "Our attitude with TCP/IP is, 'Hey, we'll do it, but don't make a big
> system, because we can't fix it if it breaks.'"
>
> Does this reflect a lack of confidence in the Ultrix group?

The actual, full quote - from Ken Olsen - is:

"Our attitude with TCP/IP is, 'Hey, we'll do it, but don't make a big
system, because we can't fix it if it breaks - nobody can.'"
-------------

It's generally considered unfair to quote out of context.  To CHANGE the con-
text - to deliberately mark something as a full sentence, with no indication
that you've left out part of the text, a part which changes the mean of what
came before - is bad enough.  To then continue on and ask a question based on
the falsely-imputed meaning is downright dishonest.

Olsen goes on to clarify what he means even further:

"TCP/IP is OK if you've got a little informal club, and it doesn't
make any difference if it takes a while to fix it."

Now, you can disagree with this statement - probably most of the readers of
this list WILL disagree, though perhaps not all.  But there's a world of
difference between disagreeing on the merits, and the intellectual dishonesty
of picking words OUT OF THE MIDDLE OF A SENTENCE and ascribing a new meaning

-- Jerry

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 13:35:04 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and NFS for MacOS?

There were actually two articles - one about Apple in general, and
another about the A/UX stuff.  The one about Apple in general starts
out with "... A/UX is another of Apple's software mistakes."
The other article was kinder.

Mike

(THis is the August 1988 issue of Byte we are discussing /msj/)


-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 14:08:09 GMT
From:      alan@cunixc.columbia.edu (Alan Crosswell)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP vendor support

Cisco's bootp also works on the terminal server in SLIP mode.  I've
used the CMU PCIP distribution with it and it worked first time.  No
more custom netdev on 8 million PC's.
/a


-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 14:13:30 GMT
From:      dnwcv@dcatla.UUCP (William C. VerSteeg)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP vendor support

I agree with the opinion that BOOTP is a good way to initialize a dumb
device. We at Digital Communication Associates are designing new products
that use BOOTP and TFTP to downline load code and configurations. A
manufacturer of communications equipment has a great deal of impetous
to support these protocols. He requires them to boot. We will support
BOOTP on both our large, disk based systems and our small diskless units.
In a typical configuration, the dumb devices will boot from the disk-based
units. When a customer wants only the smaller, cheaper units, they will have
to boot from another vendor's device.

I am curious whether the minicomputer-oriented vendors will include support
for BOOTP in their standard distributions. TWG, SRI, NRC, etc would be
well served by including as much functionality as possible. However,
I wonder if the minicomputer manufacturers will be as likely to support
a protocol to load generic hardware. Would they fear selling fewer units
of there own diskless stations and terminal servers ? I also would like to
know of other BOOTP implementations to test against.

Bill VerSteeg
DCA


-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 15:16:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   RE:  Van's algorithm's in Streams

This is in response to Kwang Sung's query:

Our newest version of Streams TCP contains Van's and Nagles algorithms
for congestion control, etc.  The header-predection performance code is
scheduled for addition, shortly, although we are still trying to understand
its impact under mixed traffic conditions.

Dave Crocker
VP, Engineering
The Wollongong Group


-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 16:18:01 GMT
From:      spl1!laidbak!stevea@elroy.jpl.nasa.gov  (Steve Alexander)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Van Jacobson's Algorithm for AT&T Stream Implementations
In article <160@bud.UUCP> kwang@bud.UUCP (Kwang Sung) writes:
>I am curious that whether we can apply Van Jacobson's Algorithm to
>AT&T Stream TCP/IP implementations easily.

Lachman's System V STREAMS TCP has been shipping with Van's TCP (as
well as the latest UCB IP and UDP fixes) since June.  Van's algorithms
were easy to integrate into our code.  The fact that we run over STREAMS

At the performance seminar in May, a great deal of material was handed
out that described these enhancements.  Perhaps ACE has extra copies
that you could obtain from them.

480 San Antonio Rd, Suite 100
Mountain View, CA 94040
415-941-3399

Hope this helps...

Steve Alexander, TCP/IP Development | stevea%laidbak@sun.com
Lachman Associates, Inc.            | ...!{ihnp4,sun}!laidbak!stevea

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 16:37:56 GMT
From:      dab@ALLSPICE.LCS.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP vendor support

Not exactly a vendor, but the MIT uVAX C-Gateway also uses bootp, not only
to find out its IP address but also to invoke TFTP to boot the gateway
code.  The gateway code also has the ability to forward bootp requests
through to appropriate bootp servers if necessary.  With the one exception
that the boot code had to be specific to a subnet (because the 4.2 servers
has worked very well.

Also, CMU has been using bootp to auto-configure IBM PC's for quite a while
using the bootp vendor field to set the various other things the PC's need
to know.  [Now for the vendor support part] We'll be including a bootp
client for configuring PC's using the CMU style vendor field (actually
either CMU style or RFC-1048) with our next release.

David Bridgham
FTP Software


-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 17:15:36 GMT
From:      cam%columbia-pdn@ACC-SB-UNIX.ARPA (Chris Markle acc_gnsc)
To:        comp.protocols.tcp-ip
Subject:   Enet + TCP/IP for Honeywell

Folks,

Does anyone know of a tcp/ip implementation for Honeywell systems and the
associated enet hardware?

Chris Markle - ACC
cam%columbia-pdn@acc-sb-unix.arpa


-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 17:43:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP for AT&T UNIX-PC 7300's


FTP Software can supply PC-based TCP/IP if you are running MS/DOS.
FTP Software is in Cambridge, MA. There are undoubtedly other sources
of supply including freeware say from MIT/LCS.

The DDN Network Information center at SRI International is another
good place to check - they have a lengthy catalog of software
which they have compiled as "DDN Protocol Implementations and
Vendors Guide" NIC 50002. It is also available on-line at
SRI-NIC.ARPA.

MMDF is available from Prof. David Farber, University of Pennsylvania,
Computer and Information Systems: farber@cis.upenn.edu

Vint Cerf


-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 18:55:34 GMT
From:      bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic)
To:        comp.protocols.tcp-ip
Subject:   Re: Micom-Interlan NP100 ethernet woes


Substantial changes have been made to the Interlan np100
driver that was distributed with 4.3BSD.  If anyone is
new copy.

Keith Bostic

bostic@ucbvax.berkeley.edu
uunet!keith


-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 18:59:00 GMT
From:      dan@srs.UUCP (Dan Kegel)
To:        comp.sys.mac,comp.protocols.tcp-ip
Subject:   Summary: TCP/IP and NFS for the Mac

I recently asked the net for info about networking for the Mac SE, and

There seem to be only two systems that let plain old Mac programs transparantly
access files on a remote Unix fileserver:

1. TOPS, a proprietary network file system developed independantly
and later purchased by Sun; this has been available for some time.
The only Unix box that TOPS currently runs on is the Sun-3.
Either LocalTalk or Ethernet may be used to connect the Macs to the Sun.
TOPS phone number is (800) 445-8677 or (415) 769-8700.
System cost:
Software:
TOPS server on Sun ($900 for 1-4 clients,$1600 for 1-16 clients)
TOPS client on Mac ($250 per client) Hardware: using LocalTalk:$50 per client + $2000 for the Kinetics Fastpath bridge using EtherTalk:$600 per client

2. Cayman Systems' Gatorbox, an NFS (Ethernet) to AFP (LocalTalk) bridge;
the box and software sell for $3495, and takes about 6 weeks to get. The Unix box must be running NFS (and most can; many are shipped with it). It links up to 32 Macs running Apple's network (AFP on LocalTalk) to a standard Ethernet network. Cayman Systems' phone number is (617) 494-1999. System cost:$50 per client (for LocalTalk cable) + $3500 for the Gatorbox bridge Other NFS systems, rumored but not currently available, are 3. University of Michgan had a client version of NFS for the Mac at last years Sun Connectathon. Don't think they ever fielded it. 4. Peter Honeyman (one of the authors of HoneyDanBer uucp?) led a project that put tcp/ip and NFS on Macs, under contract to Apple. Apple has the software now; it's unclear when if ever they will release it. LocalTalk is Apple's 200 kilobit/sec serial networking hardware, which is quite slow compared with the 10 Megabit/sec Ethernet; one might therefore expect to be able to connect up only five or ten Macs per LocalTalk bus before seeing degradation, as opposed to fifty or so on an Ethernet bus. (I've never tried it, so I dunno.) There are also systems available that let TCP/IP aware programs communicate with other machines on an Ethernet; this isn't as nice as transparant file access, but it can be pretty darn useful. 1. Kinetics sells Ethernet boards for all versions of the Macintosh; it also sells a TCP/IP (Ethernet) to TCP/IP (Appletalk) bridge. 2. NCSA maintains a professional-looking TELNET package for the PC and the Mac which supports remote login, multiple VT102 emulation, Tek 4014 emulation, subnetting, and dynamic IP address assignment via RARP. I think this is shipped with Kinetics equipment. It is available for anonymous FTP over the Darpanet from ftp.ncsa.uiuc.edu (128.174.20.50). Contacts listed on their blurb: Tim Krauskopf timk@ncsa.uiuc.edu (ARPA) Gaige B. Paulsen gaige@ncsa.uiuc.edu National Center for Supercomputing Applications (NCSA) University of Illinois, Urbana-Champaign 3. Either Stanford or Columbia maintain something called KIP and CAP which seems to be another TCP/IP package; NCSA would know more about it. 4. Phil Karn's KA9Q package is another (public-domain?) TCP/IP implementation. Thanks to everybody who replied. I'm still looking for something that supports NFS over Ethernet right to the Mac... -- Dan Kegel "We had to get it passed before the columnists attacked!" srs!dan@cs.rochester.edu rochester!srs!dan dan%srs.uucp@harvard.harvard.edu  -----------[000071][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 20:29:51 GMT From: ozalp@aya.cs.cornell.edu (Ozalp Babaoglu) To: comp.protocols.tcp-ip Subject: x.25 as an internet backbone  suppose a country (italy, to be precise) currently has a single internet site (in pisa) and has been registered as a top-level domain (domain .IT). there are three class C type IP addresses allocated to the country. what are some reasonable ways to structure subdomains in this country domain and incorporate LANs at other sites (cities) into the internet? the physical transport medium available is x.25 (both private and PDN run by the telephone company). what is the technology of choice for ethernet-x.25 gateway hardware and the software to do the routing and encapsulation (of IP packets over x.25)? any suggestions will be appreciated. ozalp babaoglu  -----------[000072][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 88 02:53:00 EST From: "BARRY NEWTON" <newton@enh.nbs.gov> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Subject: Advertising If everybody on the tcp-ip distribution list were to give the "Grand Poohbah" one telephone call on his thoughtfully provided number, he might come to a more clear understanding of the value and consideration involved in keeping crowded resources clear... But don't do it. It wouldn't be nice:-) Barry  -----------[000073][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 22:01:00 GMT From: LEICHTER@Venus.YCC.Yale.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) To: comp.protocols.tcp-ip Subject: Moderated Newsgroup Posting  Path: venus!leichter From: leichter@venus.ycc.yale.edu Newsgroups: mail.tcp-ip Subject: Re: Ken Olsen on TCP/IP Message-ID: <34@venus.ycc.yale.edu> Date: 5 Aug 88 17:01:31 GMT References: <venus mail.tcp-ip:1807> Organisation: VMS NEWS V4.0 Lines: 32 In article <venus mail.tcp-ip:1807>, jqj@hogg.cc.uoregon.EDU writes: > Quoted without permission from Digital News, August 1, 1988: > > "Our attitude with TCP/IP is, 'Hey, we'll do it, but don't make a big > system, because we can't fix it if it breaks.'" > > Does this reflect a lack of confidence in the Ultrix group? The actual, full quote - from Ken Olsen - is: "Our attitude with TCP/IP is, 'Hey, we'll do it, but don't make a big system, because we can't fix it if it breaks - nobody can.'" ------------- It's generally considered unfair to quote out of context. To CHANGE the con- text - to deliberately mark something as a full sentence, with no indication that you've left out part of the text, a part which changes the mean of what came before - is bad enough. To then continue on and ask a question based on the falsely-imputed meaning is downright dishonest. Olsen goes on to clarify what he means even further: "TCP/IP is OK if you've got a little informal club, and it doesn't make any difference if it takes a while to fix it." Now, you can disagree with this statement - probably most of the readers of this list WILL disagree, though perhaps not all. But there's a world of difference between disagreeing on the merits, and the intellectual dishonesty of picking words OUT OF THE MIDDLE OF A SENTENCE and ascribing a new meaning to them that wasn't there to start with. -- Jerry  -----------[000074][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 23:23:37 GMT From: winter@Apple.COM (Patty Winter) To: comp.sys.mac,comp.protocols.tcp-ip Subject: Re: Summary: TCP/IP and NFS for the Mac  In article <944@srs.UUCP> srs!dan@cs.rochester.edu (Dan Kegel) writes: > >4. Phil Karn's KA9Q package is another (public-domain?) TCP/IP implementation. ^^^^^^^^^^^^^^^^ For amateur radio and university research uses, yes. Otherwise, no. Patty ============================================================================= Patty Winter N6BIS DOMAIN: winter@apple.com AMPR.ORG: [44.4.0.44] UUCP: {decwrl,nsc,sun}!apple!winter =============================================================================  -----------[000075][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 23:51:00 GMT From: dcrocker@TWG.COM (Dave Crocker) To: comp.protocols.tcp-ip Subject: Re: Accidentally including the CC line  This is in reply to Bob <enger@gburg.scc.com> note: Some people may have missed the trailing smile at the end of your comment about wishing you could accidentally replying to CC recipients. I force myself to use our VMS product, mostly out of masochism but partly so issues such as the one you raise are familiar. Keith McCloghrie works on a number of our products, but not the VMS one, so he can affort the luxury of using a Unix interface (MH, when last I checked). Why should I burden everyone with this clarification? Well, the problem is that the VMS user interface to mail, with our TCP product, is standard DEC issue, called VAXmail. While we have integrated into it as best possible, through their foreign service interface, we do not touch the basic vaxmail product. We are thinking of offering a richer mail system for a number of platforms, but that is mostly my way of trying to find an excuse to use some old but fondly rememebered experiences. Another alternative, shortly, will be All-In-One. Dave Crocker The Wollongong Group  -----------[000076][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 88 01:20:32 GMT From: root@sbcs.sunysb.edu (root) To: comp.sys.mac,comp.protocols.tcp-ip Subject: Re: Summary: TCP/IP and NFS for the Mac  This is a bit tangential an answer to the original question "Who has NFS on MacOS?". For small machines there are NFS implementations available for both the IBM PC and Amiga. Sun sells PC-NFS for the IBM PC - package price is ~$900.  Ameristar Technology sells NFS
for the Amiga - package cost also $900. Since part of my time is spent at Ameristar, I'll allow myself the luxury of giving their phone number: (516) 698-0834. You probably already know how to contact Sun anyways :-). Rick Spanbauer Ameristar Technology PS. I would like to hear from anyone who has a Gator Box.  -----------[000077][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 88 01:48:29 GMT From: davidc@TERMINUS.UMD.EDU (David R. Conrad) To: comp.protocols.tcp-ip Subject: Re: BOOTP vendor support  Add the University of Maryland to the list of Universities that use bootp for PCs. Our public workstation labs use it with RFC1048 extensions to provide information for the TCP/IP for the PC that we use here. We currently use a bootp server per subnet so we don't have to worry about gateways forwarding requests although our bootp server (based on CMU's with local additions) does have forwarding capabilities. We'd also be interested in having more vendors (particularly Proteon) support bootp forwarding -drc  -----------[000078][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 88 07:53:00 GMT From: newton@ENH.NBS.GOV ("BARRY NEWTON") To: comp.protocols.tcp-ip Subject: Advertising  If everybody on the tcp-ip distribution list were to give the "Grand Poohbah" one telephone call on his thoughtfully provided number, he might come to a more clear understanding of the value and consideration involved in keeping crowded resources clear... But don't do it. It wouldn't be nice:-) Barry  -----------[000079][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 88 17:23:35 GMT From: lars@ACC-SB-UNIX.ARPA (Lars J Poulsen) To: comp.protocols.tcp-ip Subject: Re: x.25 as an internet backbone  > From lars@acc.arpa Sat Aug 6 09:35:15 1988 > Date: 5 Aug 88 20:29:51 GMT > From: ozalp@cu-arpa.cs.cornell.edu (Ozalp Babaoglu) > Organization: Cornell Univ. CS Dept, Ithaca NY > Subject: x.25 as an internet backbone > To: tcp-ip@sri-nic.arpa > > suppose a country (italy, to be precise) currently has a single > internet site (in pisa) and has been registered as a top-level domain > (domain .IT). there are three class C type IP addresses > allocated to the country. what are some reasonable ways to structure > subdomains in this country domain and incorporate LANs at other > sites (cities) into the internet? the physical transport medium > available is x.25 (both private and PDN run by the telephone company). > > what is the technology of choice for ethernet-x.25 gateway hardware > and the software to do the routing and encapsulation (of IP > packets over x.25)? any suggestions will be appreciated. > > ozalp babaoglu For each campus, assume an ethernet with its own network number. (class C may be adequate for a while). For each of these, nominate a router with an X.25 interface to be the gateway to the outside world. Suitable routers include Ultrix with ACC's ACP5250, SUN with SUNLINK, VMS with Wollongong TCP/IP and ACP5250, and many otehrs as well as standalone router boxes. The router must run EGP, ROUTE-D or similar gateway protocol to advertize reachability. If the private X.25 network has a DNIC and can communicate with the public data network, then you have one X.25 world, and all X.25 should use one network number. If not, get a network number for the X.25 network. Since X.25 has no ARP mechanism, all routers must share knowledge of IP address to X.25 address mappings. This means a centralized management of each X.25 IP network. CSNET does this on a commercial basis in the US, and it would be to your advantage to join them so that your PTT network is joined with the X.25 part of CSNET. However, I don't know if their fee schedule makes this practical. Another possibility is to declare your X.25 network to be its own IP network, and have a single gateway to the outside (via CSNET or AC.UK or via a private arrangement with a US site) but this means you have to have fairly sophisticated traffic analysis in the gateway in order to charge back the international X.25 charges to the member institutions (since they all will be charged to the gateway). I don't know of any router equipped to do this. Let me know how you arfe involved with the evangelism in Italy, and contact me if I can be of more help. / Lars Poulsen ACC Customer Service. P.S.: No slight is intended of any product not mentioned above. I have nothing against CMU TCP/IP or Hewlett-Packard. SRI MultiNet is a fine product, and so is the ACS4020... products mentioned above are for examples only. My employer does not know I'm sending this ... is that enough disclaimers ?  -----------[000080][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 88 04:59:14 GMT From: sm.unisys.com!csun!polyslo!steve@oberon.usc.edu (Steve DeJarnett) To: tcp-ip@sri-nic.arpa Subject: nroff source for recent TCP/IP paper from Rutgers???  I recently read the paper posted by Charles Hedrick from Rutgers, and found it quite informative. I was wondering if the source (nroff or TeX) was available. It would be nice to have a printout that was more suitable for reading than a normal printout. I didn't save the author's email address, so sorry for the posting. Thanks in advance, ------------------------------------------------------------------------------- | Steve DeJarnett | Smart Mailers -> steve@polyslo.CalPoly.EDU | | Computer Systems Lab | Dumb Mailers -> ..!ucbvax!voder!polyslo!steve | | Cal Poly State Univ. |------------------------------------------------| | San Luis Obispo, CA 93407 | BITNET = Because Idiots Type NETwork | -------------------------------------------------------------------------------  -----------[000081][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 88 05:24:30 GMT From: ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) To: comp.protocols.tcp-ip Subject: Re: BOOTP vendor support  > *Excerpts from ext.in.tcp-ip: 5-Aug-88 Re: BOOTP vendor support David R.* > *Conrad@terminus (517)* > We'd also be interested in having more vendors (particularly Proteon) > support bootp forwarding Hear Hear! We find BOOTP very useful. It's biggest problem though is that it requires special support in gateways to forward requests across subnets. Either that or a server for every subnet, which is a real pain since it is often cost prohibitive. As a campus support organization we can't afford to put a server machine (or two for redundancy) on each net. From my experience, it takes less than 150 lines of code or so for a fairly robust gateway forwarder implementation. In case it helps anybody, here is most of the code from our router implementation. Everyone's router is different of course, so I doubt if it will 'just slip in'. Drew /* * Bootstrap Protocol (BOOTP). RFC 951. * * 07-Oct-86 Drew D. Perkins (ddp) at Carnegie-Mellon University * Started history. * ********************************************************************** */ #include "cond/bootp.h" #if C_BOOTP > 0 /* * bp_input - process an incoming BOOTP server packet. * * dv = the device supplying the packet * p = the supplied BOOTP packet (with offset and length adjusted to * remove any encapsulating headers/trailers) * sport = the UDP source port of the sender of the datagram * saddr = the datagram's IP source address * daddr = the datagram's IP destination address * (These will typically be pointers into the encapsulating IP * header preceding the RCP packet - beware!) * * The following consistency checks are performed on the BOOTP packet: * - the physical length of the packet must be large enough to contain a * minimal BOOTP header. * If the packet is a boot request: * - the packet must not have been through too many gateways. * - the requestor must have waited a long enough time for service. * If the packet checks out, the message is counted and processed * according to the protocol. */ void bp_input(dv, p, sport, saddr, daddr) struct device *dv; struct packet *p; short sport; struct socket p_pkt saddr; struct socket p_pkt daddr; { register struct bootp p_pkt bp; register struct device *dvt; /* determined target device of pkt */ register struct ipmap *im; /* IP routing table entry */ register struct addmap *am; /* ARP routing table entry */ struct socket src, dest, tmp; /* src and dest of outgoing IP pkt */ short dport; /* destination UDP port */ int flag = 0; /* Have seen incoming device flag */ if (p->p_len < BOOTHEAD) { /* Packet large enough? */ profile(dv, bp_rmin); errorlog(p, EL_BP_RMIN); goto out; } bp = poff(bootp, p); #ifdef BOOTPDEBUG if (p->p_flag&P_TRACE) { printf("BOOTP (%d):\r\n", p->p_len); bp_prt(bp); } #endif /* BOOTPDEBUG */ switch(bp->bp_op) { /* Check opcode */ case BOOTREQUEST: /* Only forward after some amount time */ if (ntohs(bp->bp_secs) < BOOTMINSECS) { profile(dv, bp_rsecs); goto out; } /* Prevent loops */ if (bp->bp_hops++ > BOOTMAXHOPS) { profile(dv, bp_rhops); errorlog(p, EL_BP_RHOPS); goto out; } for (dvt=dv; flag == 0 || dvt != dv; dvt=dvt->dv_prnext[PR_IP]) { flag = 1; bcopy((char *)&dvt->dv_praddr[PRA_IP],(char *)&tmp, PRL_IP); if (bp->bp_giaddr.s_addr == tmp.s_addr) { profile(dv, bp_rloop); errorlog(p, EL_BP_RLOOP); goto out; } } profile(dv, bp_reqcnt); /* Fill in gateway field if empty */ if (!bp->bp_giaddr.s_addr) { copout(&dv->dv_praddr[PRA_IP], (char p_pkt) &bp->bp_giaddr, PRL_IP); } else { profile(dv, bp_rgway); } src.s_addr = bp->bp_giaddr.s_addr; dest.s_addr = daddr->s_addr; /* Check out destination address */ am = ar_map(PR_IP, (char p_pkt)daddr); if (am == 0 || !(am->am_flag&AM_BCAST)) { dest.s_addr = ipaddr(0xff, 0xff, 0xff, 0xff); profile(dv, bp_rbaddst); } dport = UD_BOOTPS; /* Send to BOOTP Server */ break; case BOOTREPLY: if (!bp->bp_yiaddr.s_addr) { profile(dv, bp_runkaddr); errorlog(p, EL_BP_RUNKADDR); goto out; } profile(dv, bp_repcnt); dest.s_addr = bp->bp_yiaddr.s_addr; /* Set up arp cache */ im = im_map(daddr, IM_ME); /* If it isn't found then we got this by mistake */ if (im == 0) { goto out; } dvt = im->im_dv; ar_remap(PR_IP,(char p_pkt)&dest,(char p_pkt)bp->bp_chaddr, dvt); src.s_addr = saddr->s_addr; dport = UD_BOOTPC; /* Send to BOOTP client */ break; default: profile(dv, bp_rbadop); errorlog(p, EL_BP_ROP); goto out; } ud_output(dv, p, sport, dport, (struct socket p_pkt) &dest, (struct socket p_pkt) &src); return; out: (*(p->p_done))(p); } void bp_prt(bp) register struct bootp p_pkt bp; { char tempa[20],tempb[20],tempc[20],tempd[20]; int i; printf(" op: %d, hops %d, id %ld, secs %d\r\n", bp->bp_op, bp->bp_hops, bp->bp_xid, bp->bp_secs); printf(" htype %d, hlen %d, chaddr ", bp->bp_htype, bp->bp_hlen); for (i = 0; i < bp->bp_hlen; i++) printf("%2x", bp->bp_chaddr[i]); printf("\r\n ciaddr = %s, yiaddr = %s, siaddr = %s, giaddr = %s\r\n", ip_fmt(&bp->bp_ciaddr, tempa), ip_fmt(&bp->bp_yiaddr, tempb), ip_fmt(&bp->bp_siaddr, tempc), ip_fmt(&bp->bp_giaddr, tempd)); } #endif /* C_BOOTP */  -----------[000082][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 1988 21:06-EDT From: URBANIAK@G.BBN.COM To: tcp-ip@SRI-NIC.ARPA Cc: urbaniak@G.BBN.COM Subject: Ether types per Torben Nielson's request. (that host not resolved from here.) Some Known Ethernet and IEEE802.3 "Type" Fields 6/18/88 The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble) consist of the "Type" or "Length" field. These values are managed by XEROX. Some assignments are public, others private. Current information includes: Xerox Public Ethernet Packet Type documentation; IEEE802.3 Std; NIC RFC960; contributions from network managers and vendors. Hex 0000-05DC IEEE802.3 Length Field (0.:1500.) 0200 Xerox PUP (conflicts with IEEE802.3 Length Field range) (see 0A00) 0201 Xerox PUP Address Translation (conflicts ...) (see 0A01) 0600 Xerox NS IDP * 0800 DOD Internet Protocol (IP) * # 0801 X.75 Internet 0802 NBS Internet 0803 ECMA Internet 0804 CHAOSnet 0805 X.25 Level 3 0806 Address Resolution Protocol (ARP) * (for IP and for CHAOS) 0807 XNS Compatibility 081C Symbolics Private 0888 Xyplex 0900 Ungermann-Bass network debugger 0A00 Xerox IEEE802.3 PUP 0A01 Xerox IEEE802.3 PUP Address Translation 0BAD Banyan Systems 1000 Berkeley Trailer negotiation 1001-100F Berkeley Trailer encapsulation 1600 VALID-machine protocol? * 5208 BBN Simnet Private % 6000 DEC unassigned 6001 DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance 6002 DEC Maintenance Operation Protocol (MOP) Remote Console 6003 DECNET Phase IV 6004 DEC Local Area Transport (LAT) 6005 DEC diagnostic protocol (at interface initialization?) 6006 DEC customer protocol 6007 DEC Local Area VAX Cluster (LAVC) 6008 DEC unassigned 6009 DEC unassigned 7000 Ungermann-Bass download 7002 Ungermann-Bass diagnostic/loopback 8003 Cronus VLN 8004 Cronus Direct 8005 HP Probe protocol 8006 Nestar 8010 Excelan 8013 Silicon Graphics diagnostic 8014 Silicon Graphics network games 8015 Silicon Graphics reserved 8016 Silicon Graphics XNS NameServer, bounce server 8019 Apollo DOMAIN 8035 Reverse Address Resolution Protocol (RARP) 8038 DEC LanBridge Management 8039 DEC unassigned 803A DEC unassigned 803B DEC unassigned 803C DEC unassigned 803D DEC Ethernet Encryption Protocol 803E DEC unassigned 803F DEC LAN Traffic Monitor Protocol 8040 DEC unassigned 8041 DEC unassigned 8042 DEC unassigned 805B Stanford V Kernel, experimental 805C Stanford V Kernel, production 807C Merit Internodal 8080 Vitalink TransLAN III Management 809B EtherTalk (AppleTalk over Ethernet) 80DE TRFS (Integrated Solutions Transparent Remote File System) 80F3 AppleTalk Address Resolution Protocol (AARP) 8107 Symbolics Private 8108 Symbolics Private 8109 Symbolics Private 8137 Novell 9000 Loopback (Configuration Test Protocol) 9001 Bridge Communications XNS Systems Management 9002 Bridge Communications TCP/IP Systems Management FF00 BBN VITAL-LanBridge cache wakeups % * These protocols use Ethernet broadcast, where multicast would be preferable. # BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3. % BBN Private Protocols, not registered Some Known Ethernet Vendor Addresses 8/7/88 Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits (0-9, plus A-F, capitalized). These 12 hex digits consist of the first/left 6 digits (which should match the vendor of the Ethernet interface within the station) and the last/right 6 digits which specify the interface serial number for that interface vendor. Ethernet addresses might be written unhyphenated (e.g. 123456789ABC), or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated by octets (e.g. 12-34-56-78-9A-BC). These addresses are physical station addresses, not multicast nor broadcast, so the second hex digit (reading from the left) will be even, not odd. At present, it is not clear how the IEEE assigns Ethernet block addresses. Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned with that block or separately. A portion of the vendor block address is reportedly assigned serially, with the other portion intentionally assigned randomly. If there is a global algorithm for which addresses are designated to be physical (in a chipset) versus logical (assigned in software), or globally-assigned versus locally-assigned addresses, some of the known addresses do not follow the scheme. 00000C Cisco 00002A TRW 00005A S & Koch 000093 Proteon 00009F Ameristar Technology 0000AA Xerox Xerox machines 0000C0 Western Digital 0000DD Gould 000102 BBN BBN internal usage (not registered) 001700 Kabel 00DD00 Ungermann-Bass 00DD01 Ungermann-Bass 020701 Interlan UNIBUS or QBUS machines, Apollo 020406 BBN BBN internal usage (not registered) 02608C 3Com IBM PC; Imagen; Valid 02CF1F CMC Masscomp, Silicon Graphics 080002 Bridge 080005 Symbolics Symbolics LISP machines 080008 BBN 080009 Hewlett-Packard 080010 AT+T 080014 Excelan BBN Butterfly, Masscomp, Silicon Graphics 080017 NSC 08001A Data General 08001B Data General 08001E Apollo 080020 Sun Sun machines 080025 CDC 080028 TI Explorer 08002B DEC UNIBUS or QBUS machines, VAXen, LANBridges (DEUNA, DEQNA, DELUA) 080045 Xylogics??? 080047 Sequent 080049 Univation 08004C Encore 08004E BICC 080068 Ridge 080069 Silicon Graphics 08006E Excelan 08007C Vitalink TransLAN III 080089 Kinetics AppleTalk-Ethernet interface 08008B Pyramid 08008D XyVision XyVision machines AA0003 DEC Global physical address for some DEC machines AA0004 DEC Local logical address for systems running DECNET Some Known Ethernet Multicast Addresses 6/18/88 Ethernet Type Address Field Usage Multicast Addresses: 09-00-09-xx-xx-xx ???? HP multicasts 09-00-2B-01-00-00 8038 DEC LanBridge Copy packets 09-00-2B-01-00-01 8038 DEC LanBridge Hello packets 1 packet per second, sent by the designated LanBridge AB-00-00-01-00-00 6001 DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance AB-00-00-02-00-00 6002 DEC Maintenance Operation Protocol (MOP) Remote Console 1 System ID packet every 8-10 minutes, by every: DEC LanBridge DEC DEUNA interface DEC DELUA interface DEC DEQNA interface (in a certain mode) AB-00-00-03-00-00 6003 DECNET Phase IV end node Hello packets 1 packet every 15 seconds, sent by each DECNET host AB-00-00-04-00-00 6003 DECNET Phase IV Router Hello packets 1 packet every 15 seconds, sent by the DECNET router AB-00-00-05-00-00 ???? Reserved DEC through AB-00-03-FF-FF-FF AB-00-04-00-00-00 ???? Reserved DEC customer private use through AB-00-04-00-FF-FF AB-00-04-01-xx-yy 6007 DEC Local Area VAX Cluster groups CF-00-00-00-00-00 9000 Ethernet Configuration Test protocol (Loopback) Broadcast Address: FF-FF-FF-FF-FF-FF 0600 XNS packets, Hello or gateway search? 6 packets every 15 seconds, per XNS station FF-FF-FF-FF-FF-FF 0800 IP (e.g. RWHOD via UDP) as needed FF-FF-FF-FF-FF-FF 0806 ARP (for IP and CHAOS) as needed FF-FF-FF-FF-FF-FF 1600 VALID packets, Hello or gateway search? 1 packets every 30 seconds, per VALID station  -----------[000083][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 88 21:59:16 GMT From: jqj@HOGG.CC.UOREGON.EDU To: comp.protocols.tcp-ip Subject: Re: Moderated Newsgroup Posting  It was clearly wrong of me to have elided an elision symbol after my quotation. However, I rather resent being called "downright dishonest." Granted that Olsen clearly believes that the problem is TCP/IP, not any incompetence of the Ultrix group, remember that he sells a product -- Ultrix -- that includes support for networking. It would seem to me that the thrust of the quotation remains that Olsen is not serious about delivering the TCP/IP based Ultrix networking that DEC advertises. Phrased differently, I believe it fair to conclude that Olsen in fact has no confidence that his Ultrix group can deliver on DEC's marketing promises. Another quotation out of context from the same source: "VAX is VMS." This discussion is rapidly shifting away from topics of interest to the TCP-IP mailing list, and to ones more appropriate to INFO-VAX.  -----------[000084][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 88 23:02:44 GMT From: torben@DORSAI.ICS.HAWAII.EDU ("Torben N. Nielsen") To: comp.protocols.tcp-ip Subject: Ether types...  Would someone kindly mail me a copy of the current list of valid Ethernet types. I know it's out there somewhere and I've seen it fly by every so often. I'm sitting and looking at a dump of Ethernet packets and I'm seing a couple of strange things. Trying to find out what the packets are. Anyone happen to know if there're legitimate reasons for sending to yourself onan Ethernet? That is, Ethernet packets where the source and the destination address are identical? Seems pointless since as far as I know, you cannot read packets you yourself transmitted off of the wire..... Am I wrong? Torben  -----------[000085][next][prev][last][first]---------------------------------------------------- Date: 8 Aug 88 01:06:00 GMT From: URBANIAK@G.BBN.COM To: comp.protocols.tcp-ip Subject: Ether types  per Torben Nielson's request. (that host not resolved from here.) Some Known Ethernet and IEEE802.3 "Type" Fields 6/18/88 The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble) consist of the "Type" or "Length" field. These values are managed by XEROX. Some assignments are public, others private. Current information includes: Xerox Public Ethernet Packet Type documentation; IEEE802.3 Std; NIC RFC960; contributions from network managers and vendors. Hex 0000-05DC IEEE802.3 Length Field (0.:1500.) 0200 Xerox PUP (conflicts with IEEE802.3 Length Field range) (see 0A00) 0201 Xerox PUP Address Translation (conflicts ...) (see 0A01) 0600 Xerox NS IDP * 0800 DOD Internet Protocol (IP) * # 0801 X.75 Internet 0802 NBS Internet 0803 ECMA Internet 0804 CHAOSnet 0805 X.25 Level 3 0806 Address Resolution Protocol (ARP) * (for IP and for CHAOS) 0807 XNS Compatibility 081C Symbolics Private 0888 Xyplex 0900 Ungermann-Bass network debugger 0A00 Xerox IEEE802.3 PUP 0A01 Xerox IEEE802.3 PUP Address Translation 0BAD Banyan Systems 1000 Berkeley Trailer negotiation 1001-100F Berkeley Trailer encapsulation 1600 VALID-machine protocol? * 5208 BBN Simnet Private % 6000 DEC unassigned 6001 DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance 6002 DEC Maintenance Operation Protocol (MOP) Remote Console 6003 DECNET Phase IV 6004 DEC Local Area Transport (LAT) 6005 DEC diagnostic protocol (at interface initialization?) 6006 DEC customer protocol 6007 DEC Local Area VAX Cluster (LAVC) 6008 DEC unassigned 6009 DEC unassigned 7000 Ungermann-Bass download 7002 Ungermann-Bass diagnostic/loopback 8003 Cronus VLN 8004 Cronus Direct 8005 HP Probe protocol 8006 Nestar 8010 Excelan 8013 Silicon Graphics diagnostic 8014 Silicon Graphics network games 8015 Silicon Graphics reserved 8016 Silicon Graphics XNS NameServer, bounce server 8019 Apollo DOMAIN 8035 Reverse Address Resolution Protocol (RARP) 8038 DEC LanBridge Management 8039 DEC unassigned 803A DEC unassigned 803B DEC unassigned 803C DEC unassigned 803D DEC Ethernet Encryption Protocol 803E DEC unassigned 803F DEC LAN Traffic Monitor Protocol 8040 DEC unassigned 8041 DEC unassigned 8042 DEC unassigned 805B Stanford V Kernel, experimental 805C Stanford V Kernel, production 807C Merit Internodal 8080 Vitalink TransLAN III Management 809B EtherTalk (AppleTalk over Ethernet) 80DE TRFS (Integrated Solutions Transparent Remote File System) 80F3 AppleTalk Address Resolution Protocol (AARP) 8107 Symbolics Private 8108 Symbolics Private 8109 Symbolics Private 8137 Novell 9000 Loopback (Configuration Test Protocol) 9001 Bridge Communications XNS Systems Management 9002 Bridge Communications TCP/IP Systems Management FF00 BBN VITAL-LanBridge cache wakeups % * These protocols use Ethernet broadcast, where multicast would be preferable. # BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3. % BBN Private Protocols, not registered Some Known Ethernet Vendor Addresses 8/7/88 Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits (0-9, plus A-F, capitalized). These 12 hex digits consist of the first/left 6 digits (which should match the vendor of the Ethernet interface within the station) and the last/right 6 digits which specify the interface serial number for that interface vendor. Ethernet addresses might be written unhyphenated (e.g. 123456789ABC), or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated by octets (e.g. 12-34-56-78-9A-BC). These addresses are physical station addresses, not multicast nor broadcast, so the second hex digit (reading from the left) will be even, not odd. At present, it is not clear how the IEEE assigns Ethernet block addresses. Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned with that block or separately. A portion of the vendor block address is reportedly assigned serially, with the other portion intentionally assigned randomly. If there is a global algorithm for which addresses are designated to be physical (in a chipset) versus logical (assigned in software), or globally-assigned versus locally-assigned addresses, some of the known addresses do not follow the scheme. 00000C Cisco 00002A TRW 00005A S & Koch 000093 Proteon 00009F Ameristar Technology 0000AA Xerox Xerox machines 0000C0 Western Digital 0000DD Gould 000102 BBN BBN internal usage (not registered) 001700 Kabel 00DD00 Ungermann-Bass 00DD01 Ungermann-Bass 020701 Interlan UNIBUS or QBUS machines, Apollo 020406 BBN BBN internal usage (not registered) 02608C 3Com IBM PC; Imagen; Valid 02CF1F CMC Masscomp, Silicon Graphics 080002 Bridge 080005 Symbolics Symbolics LISP machines 080008 BBN 080009 Hewlett-Packard 080010 AT+T 080014 Excelan BBN Butterfly, Masscomp, Silicon Graphics 080017 NSC 08001A Data General 08001B Data General 08001E Apollo 080020 Sun Sun machines 080025 CDC 080028 TI Explorer 08002B DEC UNIBUS or QBUS machines, VAXen, LANBridges (DEUNA, DEQNA, DELUA) 080045 Xylogics??? 080047 Sequent 080049 Univation 08004C Encore 08004E BICC 080068 Ridge 080069 Silicon Graphics 08006E Excelan 08007C Vitalink TransLAN III 080089 Kinetics AppleTalk-Ethernet interface 08008B Pyramid 08008D XyVision XyVision machines AA0003 DEC Global physical address for some DEC machines AA0004 DEC Local logical address for systems running DECNET Some Known Ethernet Multicast Addresses 6/18/88 Ethernet Type Address Field Usage Multicast Addresses: 09-00-09-xx-xx-xx ???? HP multicasts 09-00-2B-01-00-00 8038 DEC LanBridge Copy packets 09-00-2B-01-00-01 8038 DEC LanBridge Hello packets 1 packet per second, sent by the designated LanBridge AB-00-00-01-00-00 6001 DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance AB-00-00-02-00-00 6002 DEC Maintenance Operation Protocol (MOP) Remote Console 1 System ID packet every 8-10 minutes, by every: DEC LanBridge DEC DEUNA interface DEC DELUA interface DEC DEQNA interface (in a certain mode) AB-00-00-03-00-00 6003 DECNET Phase IV end node Hello packets 1 packet every 15 seconds, sent by each DECNET host AB-00-00-04-00-00 6003 DECNET Phase IV Router Hello packets 1 packet every 15 seconds, sent by the DECNET router AB-00-00-05-00-00 ???? Reserved DEC through AB-00-03-FF-FF-FF AB-00-04-00-00-00 ???? Reserved DEC customer private use through AB-00-04-00-FF-FF AB-00-04-01-xx-yy 6007 DEC Local Area VAX Cluster groups CF-00-00-00-00-00 9000 Ethernet Configuration Test protocol (Loopback) Broadcast Address: FF-FF-FF-FF-FF-FF 0600 XNS packets, Hello or gateway search? 6 packets every 15 seconds, per XNS station FF-FF-FF-FF-FF-FF 0800 IP (e.g. RWHOD via UDP) as needed FF-FF-FF-FF-FF-FF 0806 ARP (for IP and CHAOS) as needed FF-FF-FF-FF-FF-FF 1600 VALID packets, Hello or gateway search? 1 packets every 30 seconds, per VALID station  -----------[000086][next][prev][last][first]---------------------------------------------------- Date: 8 Aug 88 08:28:00 PDT From: Dave Crocker <dcrocker@TWG.COM> To: tcp-ip <tcp-ip@sri-nic.arpa> Subject: RE: HP TCP/IP Conformance One minor correction to Walter Underwood's note about gatewaying of packets between the 802.3-based TCP for the HP3000 MPE/V and normal Ethernet TCP/IP: In addition to the other solutions available for relaying, Wollongong offers a product called WIN/ROUTE2 for DOS. It runs as a dedication DOS application turning the PC into an IP router between HP3000s and ethernet devices. It does not talk PROBE, so that routes betweeen it and the 3000s need to be manually configured. Performance of the device scales with the speed of the PC box. Dave  -----------[000087][next][prev][last][first]---------------------------------------------------- Date: 8 Aug 88 11:02:00 PDT From: Dave Crocker <dcrocker@TWG.COM> To: tcp-ip <tcp-ip@sri-nic.arpa> Subject: RE: Van's algorithms in Streams To answer Van's query about my previous note: We do not expect Berkeley code to port directly over to our Streams implementation. While it would be delightful if it did, the Streams architecture lends itself to a substantially different implementation style, although many of the routines can translate quite easily. In the good cases, this means that the left window on your screen shows BSD and the right show the streams code, and you do fairly straightforward translations. The other piece of my comment was simply management-speak for saying that we don't have any in-house experience with this software revolution wrought by Van, et cie, so that we ought to gain some familiarity with its dynamics before shipping it to customers (who have a fairly strong expectation that we will support the code we ship.) Given the history of Van's changes to TCP code, I suspect that my m-speak was mostly a formality. Dave  -----------[000088][next][prev][last][first]---------------------------------------------------- Date: Mon 8 Aug 88 15:20:55-PDT From: William Westfield <BILLW@MATHOM.CISCO.COM> To: tcp-ip@SRI-NIC.ARPA Subject: Some ethernet controllers can hear themselves. Some ethernet controllers are capable of hearing packets that they are transmitting as they are being transmitted. If this is true, then sending a packet to yourself is a good way to check whether the ethernet is in good shape - it checks the transceiver and the ethernet cable as well as the controller. Bill Westfield cisco Systems. -------  -----------[000089][next][prev][last][first]---------------------------------------------------- Date: Mon, 8 Aug 88 17:38:36 PDT From: croft@csli.Stanford.EDU (Bill Croft) To: tcp-ip@sri-nic.ARPA Subject: BOOTP 'vendors' Although I havent been keeping close track, here is a partial list of companies and organizations using BOOTP or offering it in their products. This also includes organizations that are evaluating it or running it in-house in their R&D groups. (Let me know if your name isnt on the list). Since client and server implementations are public domain and FTPable from safe.stanford.edu, it is straightforward for a vendor to use it in their products. One of the next issues of ConneXions has an overview article on BOOTP by Jeff Mogul of DEC's Western Research Lab. Companies: Cisco, FTP Software, DEC (server in next Ultrix release), Silicon Graphics, Kinetics (CMU ROMs), DCA, BBN, Data General, HP Labs, Spider Systems Ltd., Ciba-Geigy AG, Bellcore. Universities: Stanford, CMU, MIT, Rutgers, Rice, Boston U., U. Maryland, U. Michigan, Harvard, Penn-State, Purdue, McMaster U., etc.  -----------[000090][next][prev][last][first]---------------------------------------------------- Date: 8 Aug 88 12:42:36 GMT From: rzahavi@GATEWAY.MITRE.ORG (Ron Zahavi) To: comp.protocols.tcp-ip Subject: Re: Enet + TCP/IP for Honeywell  >> >> Folks, >> >> Does anyone know of a tcp/ip implementation for Honeywell systems and the >> associated enet hardware? >> >> Chris Markle - ACC >> cam%columbia-pdn@acc-sb-unix.arpa Honeywell has a tcp/ip implementation (FTP, SMTP, TELNET) for the DPS6 and DPS8 systems (I worked on the SMTP for both). For more complete information on various configurations, etc. you can contact Mr. Dana Crabil at (703) 827-3000. -- Ron --  -----------[000091][next][prev][last][first]---------------------------------------------------- Date: Mon, 8 Aug 88 16:56:17 EDT From: Root Boy Jim <rbj@nav.icst.nbs.gov> To: ico!dougm@handies.ucar.edu Cc: tcp-ip@sri-nic.arpa Subject: TCP/IP _over_ TLI???? (was: TLI transport specific addresses) ? From: ico!dougm@handies.ucar.edu (Doug McCallum) ? You would have thought that AT&T would have understood the need of ? name servers and related tools that become an absolute necessity with ? large networks. Why would you think that? Since when does TPC know anything about networks except the phone system? Their solution would more likely be a special purpose hardware box that dials 411 and communicates directly with the synthesized voice that says the number is...'. ? Doug McCallum ? Interactive Systems Corp. ? dougm@ico.isc.com (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement Careful with that VAX Eugene!  -----------[000092][next][prev][last][first]---------------------------------------------------- Date: Mon 8 Aug 88 17:11:40-EDT From: Jim Stevens <Stevens@A.ISI.EDU> To: tcp-ip@sri-nic.arpa Cc: Stevens@A.ISI.EDU Subject: VAX VMS 5.0 TELNET & FTP?  A colleague of mine who is not currently connected to the Internet asks the following question: We are looking for a commercial version of FTP and TELNET that supports and runs within the auspices of VAX/VMS version 5.0 for our VAX 11/785 cluster. We are getting ready to convert our VAX cluster over to version 5.0, and have been advised that our EXCELAN version of FTP and TELNET are not currently supported under 5.0. EXCELAN is currently working on a 5.0 version, however it is not currently available. If anyone has any data that can help us out, it would certainly be appreciated. Please respond directly to me. Thanks, Jim Stevens (Stevens@A.ISISI.EDU) -------  -----------[000093][next][prev][last][first]---------------------------------------------------- Date: 8 Aug 88 15:28:00 GMT From: dcrocker@TWG.COM (Dave Crocker) To: comp.protocols.tcp-ip Subject: RE: HP TCP/IP Conformance  One minor correction to Walter Underwood's note about gatewaying of packets between the 802.3-based TCP for the HP3000 MPE/V and normal Ethernet TCP/IP: In addition to the other solutions available for relaying, Wollongong offers a product called WIN/ROUTE2 for DOS. It runs as a dedication DOS application turning the PC into an IP router between HP3000s and ethernet devices. It does not talk PROBE, so that routes betweeen it and the 3000s need to be manually configured. Performance of the device scales with the speed of the PC box. Dave  -----------[000094][next][prev][last][first]---------------------------------------------------- Date: Mon, 8 Aug 88 20:35:39 cdt From: german%uxh.cso.uiuc.edu@uxc.cso.uiuc.edu (Gregory German) To: tcp-ip@sri-nic.arpa Subject: Re: Summary: TCP/IP and NFS for the Mac >>>This is a bit tangential an answer to the original question "Who has >>>NFS on MacOS?". For small machines there are NFS implementations >>>available for both the IBM PC and Amiga. Sun sells PC-NFS for the >>>IBM PC - package price is ~$900.  Ameristar Technology sells NFS
>>>for the Amiga - package cost also $900. Since part of my time >>>is spent at Ameristar, I'll allow myself the luxury of giving >>>their phone number: (516) 698-0834. You probably already know >>>how to contact Sun anyways :-). >>> >>>Rick Spanbauer >>>Ameristar Technology Here is a list of PC-NFS prices FYI. I just thought I would point out the$995 price for the PC included an ethernet card.

PC-NFS-56 Media: $325 (1-4 copies) -$175 (250+ copies)

PC-NFS-51 Media and Manual: $395 (1-4 copies) -$220 (250+ copies)

PC-NFS-3C-51 Media, Manual and Board: $995 (1-4 copies) -$645 (250+ copies)

You can get down to about $100/copy of the software with right to copy options if you are heavy (500+) use. I have not checked recently, but the board included was the 3COM 3C501 last time I checked. (Sept. 1987) Greg German (german@uxc.CSO.UIUC.EDU) (217-333-8293) US Mail: Univ of Illinois, CSO, 1304 W Springfield Ave, Urbana, IL 61801 Office: 181 Digital Computer Lab.  -----------[000095][next][prev][last][first]---------------------------------------------------- Date: 8 Aug 88 17:13:04 GMT From: van@HELIOS.EE.LBL.GOV (Van Jacobson) To: comp.protocols.tcp-ip Subject: Re: Van's algorithm's in Streams  > The header-predection performance code is scheduled for > addition, shortly, although we are still trying to understand > its impact under mixed traffic conditions. Dave - Are you working on header prediction in-house or is the above management-speak for "Berkeley hasn't given us the code yet"? (We haven't given it to anybody yet -- but "real soon now".) We've been running the header prediction tcp for 3 months now and the only "impact" I've observed is that things get faster -- under any traffic conditions. That shouldn't be too surprising: The "prediction" code adds about 6us of compares to the tcp input processing. If the prediction loses, you fall through to the old input code (about 220us of processing, on the average). If the prediction wins, you do about 25us of processing, on the average. For bidirectional dataflows (e.g., telnet, smtp, etc.) the prediction wins slightly more than half the time (there are counters in our implementation to measure this -- I was surprised the hit rate was so high). [On unidirectional flows, the prediction wins all the time.] So, the impact for, say, N packets is: old = N * 220; new = N/2 * 226 + N/2 * 31. I.e., you pick up about a factor of two on bidirectional traffic and a factor of seven on unidirectional traffic. (Times will vary -- these were on a Sun-3/60. But the new/old ratios should stay about the same on different architectures.) Of course, I should point out again that the prediction didn't make much difference in overall performance -- it just made a small part of the work smaller. Given halfway reasonable protocols (as opposed to, say, the ISO protocols) and a half decent implementation, protocol processing seems to be a small fraction of the cost of networking. So far, my data makes me suspect that people working on hardware assists for protocol processing are solving the wrong problem. - Van ps- Just to ground the above timings in reality, here's our header prediction code from the 4bsd netinet/tcp_input.c. This code goes shortly after the pcb lookup (which is cached so it usually costs 3 32-bit compares). Other than checksumming the packet & making sure the header length makes sense, this is the complete tcp input processing. /* * Header prediction: check for the two common cases * of a uni-directional data xfer. If the packet has * no control flags, is in-sequence, the window didn't * change and we're not retransmitting, it's a * candidate. If the length is zero and the ack moved * forward, we're the sender side of the xfer. Just * free the data acked & wake any higher level process * that was blocked waiting for space. If the length * is non-zero and the ack didn't move, we're the * receiver side. If we're getting packets in-order * (the reassembly queue is empty), add the data to * the socket buffer and note that we need a delayed ack. */ if (tp->t_state == TCPS_ESTABLISHED && (tiflags & (TH_SYN|TH_FIN|TH_RST|TH_URG|TH_ACK)) == TH_ACK && ti->ti_seq == tp->rcv_nxt && ti->ti_win == tp->snd_wnd && tp->snd_nxt == tp->snd_max) { if (ti->ti_len == 0) { if (SEQ_GT(ti->ti_ack, tp->snd_una) && SEQ_LEQ(ti->ti_ack, tp->snd_max) && tp->snd_cwnd >= tp->snd_wnd) { /* * this is a pure ack for outstanding data * and we're not in the middle of slow-start * or congestion avoidance. */ ++tcppredack; if (tp->t_rtt && SEQ_GT(ti->ti_ack,tp->t_rtseq)) tcp_xmit_timer (tp); sbdrop (&so->so_snd, ti->ti_ack - tp->snd_una); tp->snd_una = ti->ti_ack; m_freem (m); /* * If all outstanding data is acked, stop the * retransmit timer. If there's no one * waiting to output, let tcp_output decide * between more output or persist. Otherwise * give the user a crack at the new space, * assuming he'll call tcp_output when it's * filled. If there is more data to be acked, * restart retransmit timer, using current * (possibly backed-off) value. */ if (tp->snd_una == tp->snd_max) tp->t_timer[TCPT_REXMT] = 0; else if (tp->t_timer[TCPT_PERSIST] == 0) tp->t_timer[TCPT_REXMT] = tp->t_rxtcur; if ((so->so_snd.sb_flags & SB_WAIT) || so->so_snd.sb_sel) sowwakeup(so); else if (so->so_snd.sb_cc) (void) tcp_output (tp); return; } } else if (ti->ti_ack == tp->snd_una && tp->seg_next == (struct tcpiphdr *)tp && ti->ti_len <= sbspace(&so->so_rcv)) { /* * this is a pure, in-sequence data packet * with nothing on the reassembly queue and * we have enough buffer space to take it. */ ++tcppreddat; tp->rcv_nxt += ti->ti_len; /* * Drop TCP and IP headers then add data * to socket buffer */ m->m_off += sizeof(struct tcpiphdr); m->m_len -= sizeof(struct tcpiphdr); sbappend(&so->so_rcv, m); sorwakeup(so); tp->t_flags |= TF_DELACK; return; } } /* * Prediction failed: do things one step at a time. ...  -----------[000096][next][prev][last][first]---------------------------------------------------- Date: 8 Aug 88 18:02:00 GMT From: dcrocker@TWG.COM (Dave Crocker) To: comp.protocols.tcp-ip Subject: RE: Van's algorithms in Streams  To answer Van's query about my previous note: We do not expect Berkeley code to port directly over to our Streams implementation. While it would be delightful if it did, the Streams architecture lends itself to a substantially different implementation style, although many of the routines can translate quite easily. In the good cases, this means that the left window on your screen shows BSD and the right show the streams code, and you do fairly straightforward translations. The other piece of my comment was simply management-speak for saying that we don't have any in-house experience with this software revolution wrought by Van, et cie, so that we ought to gain some familiarity with its dynamics before shipping it to customers (who have a fairly strong expectation that we will support the code we ship.) Given the history of Van's changes to TCP code, I suspect that my m-speak was mostly a formality. Dave  -----------[000097][next][prev][last][first]---------------------------------------------------- Date: 8 Aug 88 20:09:00 GMT From: falken@caen.engin.umich.edu (David R Falkenburg) To: comp.sys.mac,comp.protocols.tcp-ip Subject: Re: Summary: TCP/IP and NFS for the Mac  In article <944@srs.UUCP>, dan@srs.UUCP (Dan Kegel) writes: > 3. University of Michgan had a client version of NFS for the Mac at last > years Sun Connectathon. Don't think they ever fielded it. > > 4. Peter Honeyman (one of the authors of HoneyDanBer uucp?) led a project > that put tcp/ip and NFS on Macs, under contract to Apple. > Apple has the software now; it's unclear when if ever they will release it. Here at university of michigan, we had been using (testing, etc.) the CITI MacNFS. Both 3 & 4 were the same project-- Honeyman was project manager for both MacIP and MacNFS. both products are now in apple's hands. ALSO didn't anybody mention CAP (specifically AUFS)? it allows the unix box to act as an appleshare file server with the advent of System 6.0's inclusion of AppleShare Client this is a mostly free (with the exception of the kbox) alternative to systems like tops. -dave falkenburg university of michigan computer aided engineering network falken@caen.umich.edu umix!caen.engin.umich.edu!falken  -----------[000098][next][prev][last][first]---------------------------------------------------- Date: Tue, 09 Aug 88 01:42:31 EDT From: Peter DiCamillo <CMSMAINT%BROWNVM.BITNET@MITVMA.MIT.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: Release of Brown University's tn3270 for the Macintosh Please forgive the posting of this announcement to several relevant distribution lists. The first release of Brown University's tn3270 for the Macintosh is now available. This program consists of the NCSA TCP/IP kernel by Tim Krauskopf and Gaige B. Paulsen, Telnet 3270 option negotiation code developed by Greg Minshall at Berkeley, and 3270 emulation and Macintosh user interface code developed at Brown. It allows a Macintosh with a TCP/IP connection to access a host as a full-featured 3270 terminal. tn3270 is available via Internet anonymous FTP, over BITNET, or from Brown for a small distribution fee. Details of tn3270's features and availability are provided below. NETWORK FEATURES tn3270 includes all the features of version 2.0 of the NCSA TCP/IP kernel. These include support for both Ethernet connections and LocalTalk connections via a Kinetics gateway, a built-in FTP server, and domain nameserver support. Also, tn3270 supports dynamic IP number assignment when a Kinetics gateway is running KIP code, and allows the user to override the default Telnet terminal type and port number. EMULATION FEATURES On all Macintoshes, tn3270 emulates a 3278 with extended highlighting, APL, and the APL/Text character set. In addition, most graphics capabilities of a 3179 G or PC/GX are emulated. tn3270 also supports several 3270 enhancements, including typeahead and special blank processing. On a Macintosh II (or other Macintosh with color Quickdraw) tn3270 supports 3279 base color, four color, and eight color text, and eight color 3179 graphics. On Macintoshes with large screens, tn3270 supports either 9 or 12-point text for 24 lines, and 32 lines using 9-point text. Although primarily a 3270 emulation program, tn3270 also provides basic line mode Telnet support, and emulates a VT-52 terminal. MACINTOSH FEATURES tn3270 allows the 3270 cursor to be moved with a single mouse click, and allows the user to set the function of a double mouse click. Full MultiFinder support is provided, and on color Macintoshes the standard color picker may be used to set any screen colors. tn3270 utilizes offscreen bitmaps for fast, flicker-free screen refreshing. The speed of tn3270 can approach that of a locally-connected 3270, with updates as fast as two screens per second. SPECIAL FEATURES In addition to FTP server support, special support is provided for VM/CMS file transfer. Easy-to-use CMS RMAC and WMAC commands may be used to upload and download files during a CMS terminal session through the Telnet connection. Data transfer rates can be as high as 10K bytes/second. Brown also distributes an asynchronous terminal program, Term, which provides a user interface nearly the same as tn3270's when used with an IBM 7171. The combination of Term and tn3270 provides users with a consistent terminal interface, whether they have a high-speed network connection or a modem connection. The same CMS RMAC and WMAC commands also work with Term. HOW TO OBTAIN TN3270 Brown encourages tn3270 to be freely distributed, provided the program is not modified and the copyright notices are retained. tn3270 can be obtained in any of the following ways: Anonymous FTP from BROWNVM.BROWN.EDU (128.148.128.40): The distribution files are in the highest level directory. Begin by retrieving the file$READ-ME.FIRST which describes the other
files.

Anonymous FTP from NCSA (128.174.20.50):
The distribution files are the contents of the directory
NCSA_Telnet/tn3270.

BITNET distribution from LISTSERV@BROWNVM.BITNET:
Request the distribution files by sending LISTSERV the command
"get tn3270 package".  This command may be sent as a message
over BITNET, or as the first line of text in standard RFC 822
formatted mail. Other packages available are "tn3270xf" for the CMS
file transfer programs, and "term" for the Term program.  Issue the
command "get local filelist" for a complete list of available
files.

Mail order from Brown:
Starting on September 1, Brown will accept mail orders for copies
of the tn3270 disk and documentation.  To place an order, send a
check payable to Brown University for $20 to: tn3270 Distribution Brown University Computer Store P.O. Box 1885 Providence, RI 02912 (Orders from Rhode Island must include 6% sales tax.) KEEPING UP-TO-DATE The NCSA Telnet Digest will be used for discussing issues related to tn3270, as well as NCSA Telnet. To subscribe to the digest, send a request to telnet-request@ncsa.uiuc.edu. SOURCE AVAILABILITY tn3270 source is written for Manx Aztec C, using the MPW-compatible library and include files. Brown intends to distribute the source in the near future. An announcement of source availability will be made in the NCSA Telnet Digest mentioned above. Peter DiCamillo BITNET: CMSMAINT@BROWNVM Internet: CMSMAINT%BROWNVM.BITNET@MITVMA.MIT.EDU U.S. Mail: Computing and Information Services, Brown University, P.O. Box 1885, Providence, RI 02912 Phone: (401) 863-7582  -----------[000099][next][prev][last][first]---------------------------------------------------- Date: 8 Aug 88 21:49:49 GMT From: nittmann@rusvx1.rus.uni-stuttgart.dbp.de ("Michael F.H. Nittmann ") To: comp.protocols.tcp-ip Subject: modification to arp  of course I am shure many other people thought of it, perhaps I missed it, so I shall dare to speak it out (got my asbestos overall): Why not resolve the problem of a dead hosts's ARP entries at least for orderly downed hosts by a FLUSH function code ARP packet. A host that would receive such a packet ( broadcasted for all or for local subnet) should compare the ARP contents with the originating address, and then flush the corresponding routing table entry or flag it down. This mechanism could be added to avoid timer rundowns. By the way I like that timer concept. An orderly downed host could broadcast that packet prior to it's halt, and I think most operating systems (or, challenge for interface designers, interface software could do that in a blip of last power in case of power off) even could signal their bye from the net in panic state or whatever the operating system has as last code (dump code) running prior to a real crash. Most micros sense the power line for power up and generate a power fail signal. And: if this additional packet is created, it would not rule out present implementations using ARP since they should ignore an invalid packet (which is no REQUEST or other known type). Some call that upwards compatibility. Comments, flames, shootings??? And of course, this is my personal stuff. Michael  -----------[000100][next][prev][last][first]---------------------------------------------------- Date: 9 Aug 88 03:31:36 GMT From: nittmann@rusvx1.rus.uni-stuttgart.dbp.de ("Michael F.H. Nittmann ") To: comp.protocols.tcp-ip Subject: some interim notes on the bsd network speedups  Bravo! This is what I would call REAL speedups; as I understand the result, there is now a Sun 3/60 under SunOS4 with 750kB/s transfer rate and 1.25MB forwarding capacity. I do in no way discredit this work by furnishing some remarks to the mail article and I do not want anybody to do tricky quoting or implying negative contents. A good artist always merits some critics, not only thumb handclapping with the crowd. One remark to the 50% cpu load on forwarding: I guess that is the fact that the ethernet is at it's capacity limit and so the interface imposes cpu idle cycles on the transfer activities. One remark on loop unrolling: a sun is a pipelined processor machine BUT the compiler seems not to provide for memory prefetches nor for optimized loop structures. Only in this context an unrolling of scalar loops on a single processor machine can have results. One remark on "overhead" : if you have a slow scalar performing machine with some simple compiler that does not know about advantageous memory fetch instruction placing, the loop overhead seems to be small with respect to the instruction completion times within the loop. But this is not small loop overhead! A remark to the broken Cray's: it is absolutely true that on a fast machine with sophisticated instruction buffering, with compilers that take full advantage of memory "oddities" and with multiple parallel working functional units per processor the overhead of the return to the first instruction of a loop becomes prohibitive if the next instruction lies out of memory sequences and out of instruction buffers and the like. But the overhead is only big relatively to the instruction time spent within the loop which is already smaller than the sum of the executed instructions which seems not to be true in the case of the Sun. ( I intentionally left vectorization apart since this does not exist on the Sun) So Your school is perfectly right - for Your choosen combination of software (compiler, virtual memory, processor architecture ... ) and hardware. And that's it! The fact that just 1kB segments seem to be the optimum copy size seems to me more a Sun specific sort of resonance effect between memory transfers, virtual memory managing and interface readyness ON THE LOCAL MACHINE. As a physicist I learned to look very critically at experiments and their setups and I like to point out that Your performance test between two I guess equally optimized Suns certainly shows Your great competence on the field and the very true betterments Your code changes brought to the Sun OS4. But the experiment strictly only holds for Your configuration of two machines that operate at their - equal !!! - optimum configuration of packet munching parameters. This is sort of a formula I race. In a network You have to deal with what You call "broken" partners. They also work at least close to their respective optimum parameter configuration - resp. they would like to. Isn't it sort of a racism to declare that broken? And in a network You have to deal with the network medium itself. And no doubt: the bigger the chunks are, the better the network throughput is. Yes, I know that this is true for the monochromatic case of all equal packet lengths, but packet size distribution primarily causes disadvantages for the individual transfer ( small packet waiting for big one to pass). Now, if You operate a machine that's interface can deliver 100MB but the fastest channel You have will only gulp 10MB or 50MB (Ether, NSC Hyper), from the point of writing networking code on such a fast machine You have an interest to flood the net with a big packet and then continue with the honest work of letting users use the CPU until the 4MB Working station eventually may accept another packet. And even under these circumstances the networking software has to be as fast as possible to waste as little resources and cpu cycles as possible since Your CPU does not earn money by servicing 100MB interfaces with a some GB badnwidth CPU nor by pushing around small memory segments but by giving CPU cycles to users' number crunching codes. (this is a hit on the people that think " oh, the link is only xxxkB/s, why bother writing a code that could serve yyMB/s"). So on my opinion there are more viewpoints to observe than the record breaking perspective in clinical and artificial environment. disclaimers as usual (sometimes I have bad conscience because somebody pays NW costs for my private ognions) Michael.  -----------[000101][next][prev][last][first]---------------------------------------------------- Date: Tue, 9 Aug 88 17:23:47 PDT From: lars@ACC-SB-UNIX.ARPA (Lars J Poulsen) To: tcp-ip@sri-nic.arpa Subject: PSERV - a sample TCP/IP client/server pair PSERV - a sample piece of functional TCP/IP Berkeley socket programming. Every so often, programmers new to socket programming ask for working examples. I will give you this small example to play with. This program is a minimal remote spooling package, intended to solve a personal problem: I use every day two VMS systems and a Unix system. In my work area we have a LaserWriter connected to the Unix system, but I have to ride a sloooow elevator two floors to get to a VMS printer. I really wanted to write a small "lpd" client, but found that this would require the cooperation of system managers on both machines, since (1) LPD will only accept commands from known hosts (2) LPD will only accept connections from privileged ports (<1024) and the Wollongong VMS package enforces this also; you need system privileges to get a low-numbered port on WIN/TCP. So I decided to write my own mini protocol. This program illustrates the basic mechanism used by any server/client pair, and is small enough to dink around with fairly safely. [After all, if the system lets an unprivileged user do it, it must be safe :-) ?] The client runs un 4.3BSD or VMS/WIN/TCP; the server runs on 4.3BSD. Enjoy. / Lars Poulsen ACC Customer Service --------------------------------- Cut Here -------------------------------- In order not to clutter up TCP-IP unnecessarily (God knows I've done that enough recently) I've sent the actual source code to UNIX-SOURCES on BRL-SMOKE.ARPA. This is a relay for comp.sources; I don't know if it is two-way, so if anyone on the Usenet side needs it, I guess I can mail it. / Lars Poulsen  -----------[000102][next][prev][last][first]---------------------------------------------------- Date: 9 Aug 88 15:42:24 GMT From: amdahl!ems!quest!cnt!rod@ames.arc.nasa.gov (rod merry) To: tcp-ip@sri-nic.arpa Subject: IBM VM TCP/IP? I am interested in the channel protocol which IBM uses for their VM TCP/IP to 8232 product. If you have experience with the source code or are aware of documentation from IBM please respond via email or phone. Thanks in advance. rod (612-535-8111)  -----------[000103][next][prev][last][first]---------------------------------------------------- Date: 9 Aug 88 17:07:07 GMT From: aeras!bud!kwang@sun.com (Kwang Sung) To: tcp-ip@sri-nic.arpa Subject: Difference between the various STREAM implementations. I hope someone on the net can answer to my interesting question. I would like know "what is the significant difference between the following various products in according to AT&T STREAMS Functional Specification ?". 1. The Wollongong STREAM implementation. 2. The Convergent STREAM implementation. ( ~ Lachman's STREAM product) 3. The Mitre STREAM implementation. ( ~ Unisoft's STREAM product) 4. CMC, EXCELAN STREAM implementation. 5. Or, any other STREAM implementation, if you can think. Kwang Sung Sr. Software Engineer, ARIX Corp. UUCP: ...!sun!aeras!smaug!kwang UUCP: ...!sun!aeras!bud!kwang  -----------[000104][next][prev][last][first]---------------------------------------------------- Date: Tue, 9 Aug 88 17:44:51 GMT From: henry@utzoo.uucp (Henry Spencer) To: comp.protocols.tcp-ip Subject: Re: Ether types...  In article <88Aug7.130257hst.4295@dorsai.ics.hawaii.edu> torben@DORSAI.ICS.HAWAII.EDU ("Torben N. Nielsen") writes: >Anyone happen to know if there're legitimate reasons for sending to yourself >onan Ethernet? That is, Ethernet packets where the source and the destination >address are identical? Seems pointless since as far as I know, you cannot read >packets you yourself transmitted off of the wire..... Am I wrong? Whether you can hear yourself send is very much dependent on your Ethernet controller. Some can, some can't. -- Intel CPUs are not defective, | Henry Spencer at U of Toronto Zoology they just act that way. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu  -----------[000105][next][prev][last][first]---------------------------------------------------- Date: 9 Aug 88 18:12:00 GMT From: necntc!primerd!ENI!S39!E.TATE@ames.arc.nasa.gov To: tcp-ip@sri-nic.arpa Subject: Re: Summary: TCP/IP and NFS for the Mac  /* Written 11:16 pm Aug 8, 1988 by falken@caen.engin.umich.edu in S39:comp.protocols.tcp-ip */ In article <944@srs.UUCP>, dan@srs.UUCP (Dan Kegel) writes: > 3. University of Michgan had a client version of NFS for the Mac at last > years Sun Connectathon. Don't think they ever fielded it. > > 4. Peter Honeyman (one of the authors of HoneyDanBer uucp?) led a project > that put tcp/ip and NFS on Macs, under contract to Apple. > Apple has the software now; it's unclear when if ever they will release it. Here at university of michigan, we had been using (testing, etc.) the CITI MacNFS. Both 3 & 4 were the same project-- Honeyman was project manager for both MacIP and MacNFS. both products are now in apple's hands. ALSO didn't anybody mention CAP (specifically AUFS)? it allows the unix box to act as an appleshare file server with the advent of System 6.0's inclusion of AppleShare Client this is a mostly free (with the exception of the kbox) alternative to systems like tops. -dave falkenburg university of michigan computer aided engineering network falken@caen.umich.edu umix!caen.engin.umich.edu!falken /* End of text from S39:comp.protocols.tcp-ip */  -----------[000106][next][prev][last][first]---------------------------------------------------- Date: 9 Aug 88 23:46:37 GMT From: root@sbcs.sunysb.edu (root) To: tcp-ip@sri-nic.arpa Subject: Re: Summary: TCP/IP and NFS for the Mac In article <8808090135.AA27359@uxh.cso.uiuc.edu>, german@UXH.CSO.UIUC.EDU (Gregory German) writes: > Here is a list of PC-NFS prices FYI. I just thought I would point out the >$995 price for the PC included an ethernet card.
> PC-NFS-3C-51 Media, Manual and Board: $995 (1-4 copies) -$645 (250+ copies)
>
Yes, and $900 buys you NFS client, telnet, ftp and a Lance based shared memory Ethernet card for the Amiga. If you want to buy 250+ copies of AmigaNFS, I'm sure Ameristar will happily beat the$645 price too :-).

> You can get down to about 100/copy of the software with right to copy > options if you are heavy (500+) use. > > I have not checked recently, but the board included was the 3COM 3C501 > last time I checked. (Sept. 1987) > > Greg German (german@uxc.CSO.UIUC.EDU) (217-333-8293) > US Mail: Univ of Illinois, CSO, 1304 W Springfield Ave, Urbana, IL 61801 > Office: 181 Digital Computer Lab. Sorry this turned somewhat commercial. This original posting was meant to be informational. Rick Spanbauer Ameristar Technology  -----------[000107][next][prev][last][first]---------------------------------------------------- Date: 10 Aug 88 00:45:17 GMT From: booloo@lll-lcc.llnl.gov (Mark Boolootian) To: tcp-ip@sri-nic.arpa Subject: info on ftp -- I am in need of some information and am hoping to obtain a few pointers from a few kindly souls. I'm a neophyte in this realm (networking) so please bare with me. We are in the process of trying to gateway a net implemented with TCP/IP to another net that is of our own design. The gateway will be provided by a VAX. I have been given the task of modifying the ftp server to speak our own homegrown protocol, thus creating what seems to me to be an "ftp gateway." I don't want to even begin to fumble around with my ideas of what is involved as my thoughts aren't very clear at this moment (nor at any other, for that matter). What I'm hoping is that some of you might steer me in a direction where I can read about ftp (and the ftp server) and get some practical knowledge about what all is involved here. Sorry if this seems open-ended and vague but that is currently where where my head resides. Please E-Mail replies and don't post to the net. I'm a long ways behind on reading this newgroup and I might never find the reply. Thanks in advance for any help. mb -- -- uucp: {gatech,ihnp4,pyramid,rutgers}!lll-lcc!booloo arpa: booloo@lll-lcc.arpa  -----------[000108][next][prev][last][first]---------------------------------------------------- Date: Wed, 10 Aug 88 09:46:05 -0500 From: Gurudatta Parulkar <guru@flora.wustl.edu> To: tcp-ip@sri-nic.arpa Cc: "Dave Clark"<ddc@xx.lcs.mit.edu>, lixia@flora.wustl.edu, cheriton@pescadero.stanford.edu Subject: Comments on Proposed Transport Protocols  We just completed a DRAFT of a technical report with the abstract enclosed. If you would like a copy to review, please send me a note. I want to mention that this report does not contain any quantitative analysis, and has only qualitative reasoning to support the claims. -guru Dr. Guru Parulkar Asst Professor guru@flora.wustl.edu Dept of Computer Science parulkar@udel.edu Washington University wucs1!guru@uunet.uu.net St. Louis MO 63130 (314) 889-4621 ------------------------------------------------------------------------- Comments on Proposed Transport Protocols Anil Bhatia James Sterbenz Guru Parulkar guru@flora.wustl.edu Computer and Communication Research Center Department of Computer Science Washington University St. Louis MO 63130 Abstract Over the last few years, a number of research groups have made considerable progress on the design of high speed networks -- on the order of a few hundred Mbps to a few Gbps. The emphasis of this work has been on the design of packet switches and on the design of network access protocols. However, this work has not yet addressed the internetworking and transport level issues in a high speed internet. The ARPA Internet, which has contributed a number of fundamental ideas to the field of internetworking of diverse networks, cannot be used in its current form as a model for the very high speed internetworks (VHSI) of the future.In this report, we propose a revised internet model, called the VHSI model, which among other things, argues for a number of application-oriented lightweight transport protocols (ALTPs). As part of our effort on the design of a VHSI model, we considered the appropriateness of recently proposed transport protocols, NETBLT and VMTP, as ALTP candidates. The purpose of this report is to present the results of this study, and present our thoughts on the design of ALTPs. The summary of the results of this study is that NETBLT and VMTP have contributed a number of interesting ideas to the design of transport protocols, and they do improve upon TCP within the current Internet model for the applications they were originally designed for. However, we believe that these protocols are not appropriate solutions for the VHSI model, because the underlying assumptions and trade-offs that these protocols are based on are very different in the VHSI model. For example, the VHSI model assumes a {\em quasi-reliable} connection-oriented internet protocol (as opposed to the current unreliable datagram IP), which can make performance guarantees and can ensure that the internet is congestion free (almost all the time). Also, the network speeds in the VHSI are a few order of magnitude more than what NETBLT and VMTP assume. We argue that the transport protocols in the VHSI model should avoid end-to-end flow control as much as possible, and make the end-to-end error control application specific and indepedent of the end-to-end latency. In general, the transport protocols should be simpler, designed to be mostly implemented in VLSI, well integrated with the host architecture and operating system, and targetted for a specific class of applications. The rest of this report is organized as follows: Section 2 provides an overview of the ARPA Internet model and the VHSI model. It also gives an overview of TCP and its associated problems. Section 3 provides an overview of NETBLT and VMTP and summarizes how these protocols are improvements over TCP. Section 4 describes the limitations of NETBLT and VMTP within the VHSI model. Section 5 presents our thoughts on the design of ALTP protocols for VHSI, and finally, Section 6 is the conclusion.  -----------[000109][next][prev][last][first]---------------------------------------------------- Date: Wed, 10 Aug 88 09:22:01 EDT From: Barry Shein <bzs%bu-cs.bu.edu%bu-it.bu.edu%ntt-sh.ntt.jp@RELAY.CS.NET> To: MURAKAMI%ntt-20.ntt.jp%RELAY.CS.NET%ntt.jp@RELAY.CS.NET Cc: tcp-ip%sri-nic.arpa%nuesun.ntt.jp%RELAY.CS.NET%ntt.jp@RELAY.CS.NET, Crispin%sumex-aim.stanford.edu%nuesun.ntt.jp%RELAY.CS.NET%ntt.jp@RELAY.CS.NET, george%iguanodon.cis.ohio-state.edu%nuesun.ntt.jp%RELAY.CS.NET%ntt.jp@RELAY.CS.NET, nowicki%sun.com%nuesun.ntt.jp%RELAY.CS.NET%ntt.jp@RELAY.CS.NET, celeste%coherent.com%nuesun.ntt.jp%RELAY.CS.NET%ntt.jp@RELAY.CS.NET, earle%mahendo.Jpl.Nasa.Gov%nuesun.ntt.jp%RELAY.CS.NET%ntt.jp@RELAY.CS.NET, he%idt.unit.no%relay.cs.net%nuesun.ntt.jp%RELAY.CS.NET%ntt.jp@RELAY.CS.NET Subject: Summary: Proxy ARP on SUN  (quite a CC: list, oh well.) Here's the deal: I wrote a proxy arp based upon Sun's rarpd server which has been in production here at BU for over a year. The mainline is definitely Sun's but I call out to a bunch of routines which I wrote and put in a separate file, mainly the logic like "does this packet need a proxy rarp?" and the formatting of the reply and read-in of a table of networks to do Proxy arp for. So I've distributed it only as the .o (binary) of Sun's stuff and my added sources for relinking with a makefile and manual page. Some folks reported problems, the bit shift thing can be easily fixed but the "unaligned read" is a little mysterious (gee, works here, same machine, same OS, I'll have a look.) I don't believe any of this will work under Sun O.S. 4.0 (at least one try to recompile indicated some things had changed and 4.0 sources might be needed to make it work again.) So it's a little shaky at best, got me thru the night. Some of my tardiness in replying to people is explained by the fact that I am currently changing jobs and just haven't been around, I'm catching up (gee, these net requestors are harsh taskmasters!) The good news is this: A) I'll put what I have up for anonymous FTP soon, anyone that has a copy of my stuff should of course feel free to redistribute as stated above, binary of the mainline etc., as I distributed it. B) Haavard Eidnes claims to have completely written a new Proxyd from scratch based on my basic design (not the Sun sources) and I assume will make all sources available. He recently asked if he could just re-work the manual page I distributed and of course I said yes (Haavard: if you still haven't gotten my permission here it is again, if I didn't want people using my stuff I wouldn't give it out!) SOOOOOO... You should probably wait for B) to become available and that will solve all sorts of problems. My Proxyd kind of got out there by accident when someone mentioned I had given them a copy on one of the major lists. I knew it was a bit kinky and never really intended it for wide distribution nor thought all the problems could be worked out w/o a complete re-write due to its being based on the Sun rarpd (tho it was a good idea at the time, it was up in an hour or two.) And, of course, you might also consider Sun's product. Also, as I understand it you can get some limited amount of proxy arping by just sticking published arptab entries in with /etc/arp under SunOS or 4.3 (and probably others.) That's a limited hack as it's per-host rather than per-network so either you need large tables or small networks, but I thought I'd mention it. -Barry Shein  -----------[000110][next][prev][last][first]---------------------------------------------------- Date: Wed 10 Aug 88 10:22:44 From: ken-ichiro murakami <MURAKAMI%ntt-20.ntt.jp@RELAY.CS.NET> To: tcp-ip%sri-nic.arpa%nuesun.ntt.jp@RELAY.CS.NET Cc: Crispin%sumex-aim.stanford.edu%nuesun.ntt.jp@RELAY.CS.NET, george%iguanodon.cis.ohio-state.edu%nuesun.ntt.jp@RELAY.CS.NET, nowicki%sun.com%nuesun.ntt.jp@RELAY.CS.NET, celeste%coherent.com%nuesun.ntt.jp@RELAY.CS.NET, earle%mahendo.Jpl.Nasa.Gov%nuesun.ntt.jp@RELAY.CS.NET, he%idt.unit.no%relay.cs.net%nuesun.ntt.jp@RELAY.CS.NET Subject: Summary: Proxy ARP on SUN  I recently asked Mark<Crispin@sumex-aim.stanford.edu> for info about Proxy ARP on SUN. He kindly forwarded to TCP-IP mailing-list, and I received many helpful responses. I modified and summarized these responses. Mark, George, Bill, Celeste, Greg and Haavard, thank you very much for your help. I hope this summary also helps other net people. (1) Barry Shein<bzs@bu-cs.bu.edu>'s proxy ARP daemon > From: "George M. Jones" <george@iguanodon.cis.ohio-state.edu> > I have Sun 3 (or possibly 4) binary and man page for Barry Shein's > proxy arp daemon, but you will have to contact him directly about > source. (2) "consulting special product" from Sun > From: Bill Nowicki <nowicki@sun.com> > From: "Celeste C. Stokely" <celeste@coherent.com> > From: Greg Earle <earle@mahendo.Jpl.Nasa.Gov> > Proxy ARP is available as a "consulting special product" from Sun > Software Support. If you are in the USA, you can call > 1-800-USA-4-SUN and request it. If you are not in the USA, you can > probably get it from the technical support people in your Sun sales > office. > The author, David Robinson, has made it available for anonymous FTP > from elroy.JPL.NASA.GOV as well as (I believe) the ~ftp/pub > directory on uunet.UU.NET. I should warn you that Sun's code is > basically David's, with perhaps minor modifications. Note that the > code is for SunOS 3.4 or SunOS 3.5. There is no support for SunOS > 4.0 as of yet. (3) From: Haavard Eidnes IDT <he%idt.unit.no@relay.cs.net> > I just happen to have written such a program. It will run on SunOS > 3.3, 3.4 and 3.5 -- the SunOS 4.0 code for using NIT is different, and > I haven't got any SunOS 4.0 machines here yet. > I tried out Barry Shein <bzs@bu-cs.bu.edu>'s program, proxyd, but > could not make Barry's proxyd work for me. It stopped with the > error message "badly aligned read" after a small number of packets > (when started with the '-d' option, at least). Besides, Barry's > program is only partly delivered in source form, and a comment in > there seemed to indicate that it was specific for class B subnetted > hosts. Also, there was a shift in there somewhere (>>8) that should > not be there -- I reported it to Barry, but got the usual silence... > As my program stands now, it has a couple of mis-features that I > intend to weed out before I let the net have it (I intend to > distribute it freely). I have not yet created a man page for my > program -- I thought of using Barry Shein's ,and asked him for > permission. He hasn't responded yet. > I intend also to complete the distribution with a README file before > I let it loose on the net. > Sorry, no documentation yet, but you can largely use Barry's man > page, except that you can't have comments anywhere on a line of the > /etc/proxytab file, only in the first column. > Good luck! Please report back to me if you find bugs or implement > enhancements (diff -c2 is preferred for updates/changes). Again, thank you very much for your help. --Ken Ken-ichiro Murakami NTT Laboratories Tokyo, Japan -------  -----------[000111][next][prev][last][first]---------------------------------------------------- Date: Wed, 10 Aug 88 17:58:06 PDT From: braden@venera.isi.edu To: dzoey@terminus.umd.edu Cc: braden@venera.isi.edu, tcp-ip@sri-nic.arpa Subject: Re: FTP questions.  I have some questions about FTP. Why is there an EOR indication in the descriptor code for block mode? If you are sending record oriented data then you are presumably using a record structure which already defines its EOR indication. Joe, Huh? If you are sending record-oriented data, then the FTP EOR indication marks the end of each record. The record structure is not assumed to be somehow encoded into the data, but is made explicit... so another system that also has record structure, but encodes it differently, can handle the data. If you are not sending record oriented data then why do you need to determine EOR? You don't. You don't have to set the EOR bit if it is inappropriate. That's the nice thing about bits, they can be on or off. Is it correct to duplicate the EOR information if you are using a record structure in block mode? No. See above. Does the EOR in block mode indicate that at most one record per block may be sent? Yes. I like the fact that you don't need to close the data connection when transfering in block or compressed mode since there is an EOF indication. When using page or record structures in stream mode, it is possible to detect EOF (since it is part of the descriptor info) even though the mode is stream. Why is it necessary to close the data connection even though EOF is indicated in the structure. It isn't necessary. Section 3.2 discusses at some length when the connection has to be closed. For block mode, it is the server's option. P.S. Does anyone know of any machine I can test block mode and record structure against? IBM VM/TCP will do block mode but only stream structure and 2.4 Ultrix does neither... Try any of the OS/MVS systems derived from the UCLA ACP. Bob Braden  -----------[000112][next][prev][last][first]---------------------------------------------------- Date: Wed, 10 Aug 88 17:19:18 EDT From: dzoey@terminus.UMD.EDU To: tcp-ip@sri-nic.arpa Subject: FTP questions.  I have some questions about FTP. Why is there an EOR indication in the descriptor code for block mode? If you are sending record oriented data then you are presumably using a record structure which already defines its EOR indication. If you are not sending record oriented data then why do you need to determine EOR? Is it correct to duplicate the EOR information if you are using a record structure in block mode? This seems to be so, but I'm seeking reassurance. Does the EOR in block mode indicate that at most one record per block may be sent? I like the fact that you don't need to close the data connection when transfering in block or compressed mode since there is an EOF indication. When using page or record structures in stream mode, it is possible to detect EOF (since it is part of the descriptor info) even though the mode is stream. Why is it necessary to close the data connection even though EOF is indicated in the structure. I have the nagging feeling that I'm missing something basic, like EOF descriptors are optional in record descriptors or EOR is optional in block descriptors. Can someone enlighten me? Please? Adthanksvance Joe Herman PC/IP @ Maryland P.S. Does anyone know of any machine I can test block mode and record structure against? IBM VM/TCP will do block mode but only stream structure and 2.4 Ultrix does neither... dzoey@terminus.umd.edu  -----------[000113][next][prev][last][first]---------------------------------------------------- Date: 10 Aug 88 17:04:49 GMT From: att!chinet!mcdchg!clyde!watmath!utgpu!utzoo!yunexus!maccs!beame@ucbvax.Berkeley.EDU (Carl Beame) To: tcp-ip@sri-nic.arpa Subject: NFS for IBM PC  We are currently involved in the creation of the commercial product BW-NFS, an implementation of Network File System for the PC (client version). Now that the alpha-test stage is complete, we are looking for interested parties to participate in beta-testing. The physical requirements are PCs with 3Com 3C501 ethernet cards, and DOS 3.x. Servers which implement NFS, RPC and XDR and have a C compiler are a must. - Carl Beame Beame@McMaster.CA ... !uunet!attcan!utzoo!utgpu!maccs!beame (416) 648-6556  -----------[000114][next][prev][last][first]---------------------------------------------------- Date: 10 Aug 88 19:23:50 GMT From: karn@thumper.bellcore.com (Phil R. Karn) To: comp.sys.mac,comp.protocols.tcp-ip Subject: Re: Summary: TCP/IP and NFS for the Mac  There has apparently been some confusion regarding the status of my TCP/IP package. As it very clearly states when you bring it up, it is copyrighted by myself. Although I have granted to noncommercial users (including university and amateur radio groups) the right to use, copy and modify it for free, this does not in any way diminish my other rights under copyright, nor does it place the package into the public domain. I am well aware that my policy of openly publishing my sources makes it much harder, as a practical matter, to keep commercial users from abusing my copyright restriction. It has also probably diminished the commercial value of the software. However, very early on I decided that, despite this risk, open publication was essential to maximize the benefit to the amateur radio community for which the package is primarily intended. Although most of the code in the package is by myself, certain sections have been contributed by other amateurs with the same understanding: free for noncommercial use only. The authors of these sections are identified by comments in their respective source files. I ask others to respect the wishes of myself and the other authors in this matter. Thank you. Phil Karn, KA9Q  -----------[000115][next][prev][last][first]---------------------------------------------------- Date: 10 Aug 88 20:30:18 GMT From: hsi!stevens@uunet.uu.net (Richard Stevens) To: tcp-ip@sri-nic.arpa Subject: IEEE 802.2, 802.3 & Ethernet questions I have a few questions regarding the use of TCP/IP on an Ethernet. From reading RFC 1042, I'm led to believe that "all communication is performed using 802.2 type 1 communication." That would seem to imply that the 8-byte LLC header and SNAP header is being used, but going through our 4.3 BSD sources, I can't find any refernces to these headers. Later in the RFC, they talk about "Interoperation with Ethernet", which makes me think that what we're using is the "Ethernet" instead of the 802.3 link level control. I can't find many references that describe 802.2 at all - I don't want to read the IEEE standard (if possible) and Stallings Volume 2 (which the local bookstore doesn't have) appears to be the only reference I've seen. (1) What are the differences between Ethernet V1.0 and V2.0 and 802.3 ? From seeing how our hardware is set up, it appears that all our interface cards are set for 802.3. (2) Do any TCP/IP implementations on an "ethernet" use the 802.2 LLC ? Looking at the RT PC AIX V2.1 manual (pp. 1-17 to 1-19) leads me to belive that this implementation does use the 802.2 LLC. (3) Why do some documents refer to the 2-byte field in the Ethernet MAC (immediately following the destination address and source address) as "length" (RFC 1042, for example) while others call it "packet type" (Comer's new book, for example) ? (4) Are there any implementations of TCP/IP on a Token-Ring (802.5) other than the RT PC ? Thanks for any light anyone can shed on this. Richard Stevens Health Systems International, New Haven, CT { uunet | yale } ! hsi ! stevens  -----------[000116][next][prev][last][first]---------------------------------------------------- Date: 11 Aug 88 09:16:00 PST From: <art@acc.arpa> To: "hsi!stevens" <hsi!stevens@uunet.uu.net> Cc: tcp-ip@sri-nic.arpa Subject: RE: IEEE 802.2, 802.3 & Ethernet questions  Richard, >I have a few questions regarding the use of TCP/IP on an Ethernet. >From reading RFC 1042, I'm led to believe that "all communication >is performed using 802.2 type 1 communication." That would seem to >imply that the 8-byte LLC header and SNAP header is being used, >but going through our 4.3 BSD sources, I can't find any refernces >to these headers. Later in the RFC, they talk about "Interoperation >with Ethernet", which makes me think that what we're using is the >"Ethernet" instead of the 802.3 link level control. We tend to get a little lax in our use of terminology. People tend to interchange the use of the terms "Ethernet" and "802.3" even though they are not really quite the same thing. >I can't find many references that describe 802.2 at all - I don't >want to read the IEEE standard (if possible) and Stallings Volume 2 >(which the local bookstore doesn't have) appears to be the only >reference I've seen. The IEEE 802 standards are much easier reading than some of the ISO or CCITT documents. >(1) What are the differences between Ethernet V1.0 and V2.0 and 802.3 ? > From seeing how our hardware is set up, it appears that all our > interface cards are set for 802.3. First keep in mind that these specifications have mechanical, electrical and protocol components. Ethernet V1.0 is the original, derived from the 3mb/sec CSMA/CD work done at Xerox PARC. This standard was pushed by the joint efforts of DEC, INTEL, and Xerox. Ethernet V2.0 was released a few years later and mainly changed the electrical interface between the host and transceiver. The MAC headers did not change between V1.0 and V2.0 and both define the last word of the MAC header to be the protocol type. When IEEE took up standardization of LANs, 802.3 was developed for CSMA/CD (Ethernet type) LANS. 802.3 is really broader than Ethernet and covers more speeds and media types (and is still being extended). 802.3 and Ethernet V2.0 are close enough at mechanical and electrical levels to be functionally equivalent. IEEE 802 defines many MAC technologies (CSMA/CD, token bus, token ring) but attempts to provide a common link level service. To do this, 802 protocols are broken into two layers, Media Access Control (MAC) and Logical Link Control (LLC or 802.2). The MAC headers tend to differ amoung the LAN types, but each LAN type has at least one type of "Information" MAC frame. These MAC frames carry LLC packets whose length must be derived from the MAC header. For 802.3 there is only one MAC frame type. The 802.3 MAC header consists of <Dest, Src, Len>, where Dest and Src are either 2 byte or 6 byte MAC addresses and Len is the LLC packet length. For networks using 6 byte addresses, the Ethernet and 802.3 headers only differ in the last word being a protocol id or an LLC length respectively. In 802 protocols, the LLC header identifies the next layer "user" using the "Service Access Point" (SAP) fields. Unfortuneately, they only defined 6 usable bits for LLC SAPs and refused to assign standard SAP values for protocols like ARP (though IP was assigned a value). To solve this problem, the Sub-Network Access Protocol (SNAP) was defined to expand protocol identification. One variant of the SNAP header carries Ethernet protocol type codes. RFC 1042 is basically describing this situation. > >(2) Do any TCP/IP implementations on an "ethernet" use the 802.2 LLC ? > Looking at the RT PC AIX V2.1 manual (pp. 1-17 to 1-19) leads > me to belive that this implementation does use the 802.2 LLC. Most TCP/IP vendors still use Ethernet MAC headers, but there are one or two that have adopted LLC and SNAP. It is expected that when ISO protocols get established that 802.2 will be more widespread. Note that for "Etherenet" it is possible to distinguish between Ethernet and 802.3 MAC headers because the Ethernet protocol types are illegal LLC length values and vice versa. >(3) Why do some documents refer to the 2-byte field in the Ethernet > MAC (immediately following the destination address and source > address) as "length" (RFC 1042, for example) while others call > it "packet type" (Comer's new book, for example) ? As above, in Ethernet it is "type" and in 802.3 it is "length". >(4) Are there any implementations of TCP/IP on a Token-Ring (802.5) > other than the RT PC ? I believe that IBM's VM TCP/IP supports TR. I would assume Proteon does in their routers and some universities are probably running TCP/IP TRs. (Of course there is the whole TR source routing controversy :-> ). >Thanks for any light anyone can shed on this. I hope this helps. > Richard Stevens > Health Systems International, New Haven, CT > { uunet | yale } ! hsi ! stevens Art Berggreen art@acc.arpa ------  -----------[000117][next][prev][last][first]---------------------------------------------------- Date: Thu, 11 Aug 88 09:53:43 PDT From: braden@venera.isi.edu To: dzoey@terminus.umd.edu Cc: tcp-ip@sri-nic.arpa Subject: Re: FTP questions.  Bob, thanks for clearing up some of my misconceptions. I realize now that the EOR bit in block mode is useful for page structure. Apparently we are still not communicating. Page structure is irrelevant. Suppose you have a file that is a sequence of records; call them (C1,D1), (C2,D2), (C3,D3)..., where the Ci's are the control information that the local operating system uses to delimit records (typically a count and maybe some flag bits), and Di's are the ACTUAL DATA parts of the records. To transmit this file using FTP, you would transmit: D1, EOR, D2, EOR, D3, EOR... where the EOR flags are transmitted as specified by the FTP protocol, eg in block mode in the block headers. The local operating system control fields are NOT transmitted, only the data parts Di. Bob Braden  -----------[000118][next][prev][last][first]---------------------------------------------------- Date: Thu, 11 Aug 88 09:25:05 EDT From: dzoey@terminus.UMD.EDU To: braden@venera.isi.edu Cc: tcp-ip@sri-nic.arpa Subject: Re: FTP questions. Bob, thanks for clearing up some of my misconceptions. I realize now that the EOR bit in block mode is useful for page structure. I'm still a little confused about when it is permissible to keep the data connection open. [in stream mode] >> Why is it necessary to close the data connection even though >> EOF is indicated in the structure. > It isn't necessary. Section 3.2 discusses at some length when the connection > has to be closed. For block mode, it is the server's option. My question about when to close the data connection stems from section 3.3 where it says: "When using the stream mode of data transfer, the end of file must be indicated by closing the connection." I guess that is pretty straight forward, but if EOF can be determined from the structure, it seems a shame to have to close the connection to signal EOF again. > Bob Braden Thanks for the help. Joe Herman dzoey@terminus.umd.edu  -----------[000119][next][prev][last][first]---------------------------------------------------- Date: Thu, 11 Aug 88 09:41:59 EDT From: jas@proteon.com (John A. Shriver) To: hsi!stevens@uunet.uu.net Cc: tcp-ip@sri-nic.arpa Subject: IEEE 802.2, 802.3 & Ethernet questions IEEE 802.3 != Ethernet. There are no frame format or protocol differences between Ethernet Version 1 and 2. The only differences are subtle (but important) ones in the electrical interface over the transceiver cable between the host and transceiver. IEEE 802.3 does not have the same frame format as Ethernet. What was the type field in Ethernet becomes a length field. Thus, a new header has to be added to indicate what Network layer protocol the packet is for. This (among other things) is provided by IEEE 802.2. One backwards-compatability has been provided in 802.3 for Ethernet format frames. It turns out that almost all of the values of the type field were longer than a maximum length Ethernet packet. So, if the length is too long, it must be a type. Electrically, IEEE 802.3 is quite similar to Ethernet Version 2, mostly stricter. Again, the differences are primarily in the transceiver cable. On the coax, all three standards are fully compatible. Almost nobody runs IP over "Ethernet" using the RFC1042 encapsulation. Instead, the format defined in RFC894 "A Standard for the Transmission of IP Datagrams over Ethernet Networks" is used. (Note that RFC894 is older than those 4.3bsd sources, whereas RFC1042 is much newer.) I guess the existence of any "Ethernet" RFC1042 implmenations stems from an obsession with standards (eg. IEEE) over interoperability. Of course, the other 802 networks (802.4 and 802.5) most definitely use the RFC1042 encapsulation.  -----------[000120][next][prev][last][first]---------------------------------------------------- Date: Thu, 11 Aug 88 14:58:38 MDT From: ntia!chris@handies.ucar.edu (Chris Bogart) To: nbires!tcp-ip@sri-nic.arpa  We are going to do performance measurements of IP, both DoD and ISO versions, at NTIA, and I am looking for information concerning the two standards. Does anyone know of any documents which compare and contrast the two IP's? I'm interested in how they differ in: - interface with transport layer - functions performed Thanks in advance for any help you can give me. My UUCP mailing address is: ...ihnp4!stcvax!nbires!ntia!chris or U.S. Mail Chris Bogart NTIA/ITS.N3 325 Broadway Boulder, CO 80303  -----------[000121][next][prev][last][first]---------------------------------------------------- Date: Thu, 11 Aug 88 13:57:37 EDT From: barns@gateway.mitre.org (Bill Barns) To: braden@venera.isi.edu, dzoey@terminus.UMD.EDU Cc: tcp-ip@sri-nic.arpa Subject: Re: FTP questions. As best I recollect (someone correct me if I'm wrong), TOPS-20 transfers that use page structure and stream mode do not close the data connection after each file. I don't recall hearing anyone claim that this was the wrong thing to do, at least within the last few years. By analogy, I think it is ok to leave the connection up for record structure and stream mode. It's unfortunate that 3.3 is not quite consistent with 3.2 (and implicitly disagrees with 3.4.x also, where a point is made of saying that the close is necessary in file structure, but nothing is said about it for the other structures.) I think that 3.2 should be believed. The closing of the data connection at the end of any transfer is at the server's discretion, so you wouldn't be out of spec to do it if you are writing a server, but as you said in the first place, it seems like a useless thing to do. I believe that MIL-STD-1780 FTP is consistent with what I have just said. The relevant reference seems to be section 5.4.2, entitled "Alternate Data" (huh?) The MIL-STD has its little organizational glitches too, you see. Sigh. I have not noticed anything in the MIL-STD that replicates the troublesome wording of 3.3 of the RFC, but given the way the MIL-STD is put together, I'm not willing to make a promise even though I've got it open right in front of me. Bill Barns / MITRE / barns@gateway.mitre.org  -----------[000122][next][prev][last][first]---------------------------------------------------- Date: Thu, 11 Aug 88 17:15:28 PDT From: braden@venera.isi.edu To: barns@gateway.mitre.org, dzoey@terminus.umd.edu Cc: tcp-ip@sri-nic.arpa Subject: Re: FTP questions.  As best I recollect (someone correct me if I'm wrong), TOPS-20 transfers that use page structure and stream mode do not close the data connection after each file. I don't recall hearing anyone claim that this was the wrong thing to do, at least within the last few years. By analogy, I think it is ok to leave the connection up for record structure and stream mode. That sounds right to me. If the receiver can unambiguously tell when the end of data has come by somehow parsing the stream, the sender does not have to close the connection to indicate EOF. The record-structure escape sequences in stream mode can carry the EOF bit, or the page structure has its own encoding that says "last page". It's unfortunate that 3.3 is not quite consistent with 3.2 (and implicitly disagrees with 3.4.x also, where a point is made of saying that the close is necessary in file structure, but nothing is said about it for the other structures.) I think that 3.2 should be believed. The closing of the data connection at the end of any transfer is at the server's discretion, so you wouldn't be out of spec to do it if you are writing a server, but as you said in the first place, it seems like a useless thing to do. Right. I believe that MIL-STD-1780 FTP is consistent with what I have just said. The relevant reference seems to be section 5.4.2, entitled "Alternate Data" (huh?) The MIL-STD has its little organizational glitches too, you see. Sigh. I have not noticed anything in the MIL-STD that replicates the troublesome wording of 3.3 of the RFC, but given the way the MIL-STD is put together, I'm not willing to make a promise even though I've got it open right in front of me. Well, I wouldn't know a MIL-STD FTP even if (especially if?) I met one coming through a dark alley on a moonless night. But people I trust tell me it is obsolete, being based on RFC-765, so I wouldn't pay attention to it anyway. Unfortunate, DoD turned its back on Internet standards some time ago. Bob Braden Bill Barns / MITRE / barns@gateway.mitre.org  -----------[000123][next][prev][last][first]---------------------------------------------------- Date: Thu, 11 Aug 88 23:20:22 -0500 From: Gurudatta Parulkar <guru@flora.wustl.edu> To: tcp-ip%sri-nic.arpa@uunet.UU.NET Subject: retry > We just completed a DRAFT of a technical report with the abstract > enclosed. If you would like a copy to review, please send me a note. > I want to mention that this report does not contain any quantitative > analysis, and has only qualitative reasoning to support the claims. Comments on Proposed Transport Protocols Anil Bhatia James Sterbenz Guru Parulkar guru@flora.wustl.edu Well, I received over 70 requests in last two days asking for copies of this report. To avoid mailing those many copies, I have decided to make it available via anonymous ftp. Could you please retrieve this via ftp to flora.wustl.edu ? In case you cannot, please send me (or to anil@flora.wustl.edu) another note, and we'll send you a printed copy. I guess the abstract seems to have raised the expectations too much!? In any case, we'll appreciate your comments on the report. The details for anonymous ftp are Host - flora.wustl.edu (128.252.123.41) File name in pub directory - cotp.tar or cotp.tar.Z (cotp = comments on transport protocols) When you do uncompress and untar, you will get four files: cotp.tex - in LaTeX format bib.tex - bibliography to go with cotp.tex fig1.ps - figure in postscript form fig2.ps - figure in postscript form -guru Dr. Guru Parulkar Asst Professor guru@flora.wustl.edu Dept of Computer Science parulkar@udel.edu Washington University wucs1!guru@uunet.uu.net St. Louis MO 63130 (314) 889-4621  -----------[000124][next][prev][last][first]---------------------------------------------------- Date: Thu, 11 Aug 88 14:01:28 +0200 From: he@idt.unit.no To: bzs@bu-cs.bu.edu Cc: MURAKAMI@ntt-20.ntt.jp, tcp-ip@sri-nic.arpa, crispin@sumex-aim.stanford.edu, george@iguanodon.cis.ohio-state.edu, nowicki@sun.com, celeste@coherent.com, earle@mahendo.Jpl.Nasa.Gov Subject: Summary: Proxy ARP on SUN Barry Shein writes: Some of my tardiness in replying to people is explained by the fact that I am currently changing jobs and just haven't been around, I'm catching up (gee, these net requestors are harsh taskmasters!) Uh, I probably am guilty of some harshness, especially in my letter to Murakami that got forwarded to this list. I really am sorry for my wording, and I apologise. To follow up on Barry's good news section: I've completed my proxy arp daemon for SunOS 3.[345], with README file and man page (based on Barry's -- thanks Barry!). I'll probably get around to submitting my code to SunSpots for inclusion in their sun-source archive. However, as it usually takes some time between things get submitted to they make it to the archive, I propose that it should be FTP'able also. For those of you in a hurry, you can pick it up from loke.unit.no (IP: 128.39.5.27), in ~ftp/pub/proxyarpd.shar. It's only ~26KBytes. However, for most of you this is the other side of the Atlantic, so don't expect too god performance... Unfortunately, we'll (temporarily, but for at least 2 months) lose our internet connection this coming monday (August 15th), so I'll send a copy off to Barry and ask him to put it in their anonymous FTP area. Regards, Haavard Eidnes, Division of Computer Systems and Telematics Norwegian Institute of Technology, N-7034 Trondheim, Norway E-Mail; any of: he@idt.unit.no (will soon cease to work) he%idt.unit.no@norunix.bitnet eidnes@norunit.bitnet h_eidnes%vax.runit.unit.uninett@cernvax.uucp  -----------[000125][next][prev][last][first]---------------------------------------------------- Date: 11 Aug 88 18:25:45 GMT From: rochester!srs!dan@cu-arpa.cs.cornell.edu (Dan Kegel) To: tcp-ip@sri-nic.arpa Subject: Update on "NFS and TCP/IP for the Mac" I recently posted a summary about networking between the Mac SE and Unix machines. Enough new information has come in to make reposting worthwhile. There seem to be only two systems that let plain old Mac programs transparantly access files on a remote Unix fileserver: 1. Cayman Systems' Gatorbox This box lets Mac applications use files from any NFS file server; it is also a complete superset of the Kinetics FastPath. Not only does it allow use of TCP/IP protocols on LocalTalk, but it allows use of AppleTalk protocols on Ethernet, and translates Apple Filing Protocol requests into NFS requests regardless of whether they arrive over Ethernet or Appletalk. Either LocalTalk or Ethernet may be used to connect the Macs to the box; either thick or thin Ethernet may be specified. The number of Macs that one Gatorbox can support depends on how often the Macs need to use the network. This is a slick box! They built EXACTLY what I was looking for. Cayman Systems' phone number is (617) 494-1999. System cost: Using LocalTalk:50 per client + $3500 for the Gatorbox bridge Using EtherTalk:$600 per client + $3500 for the Gatorbox bridge 2. TOPS, a proprietary network file system developed independantly and later purchased by Sun; this has been available for some time. The only Unix box that TOPS currently runs on is the Sun-3. Either LocalTalk or Ethernet may be used to connect the Macs to the Sun. TOPS phone number is (800) 445-8677. System cost: Software: TOPS server on Sun ($900 for 1-4 clients, $1600 for 1-16 clients) TOPS client on Mac ($250 per client)
Hardware:
using LocalTalk: $50 per client +$2000 for the Kinetics Fastpath bridge
using EtherTalk: $600 per client Another NFS systems, rumored but not currently available, are 3. Peter Honeyman (one of the authors of HoneyDanBer uucp?) led a project at CITI that put tcp/ip and NFS on Macs, under contract to Apple. Apple has the software now; it's unclear when if ever they will release it. UMich was involved in testing CITI's software. Terminology: LocalTalk is Apple's 230 kilobit/sec serial networking hardware; EtherTalk is Ethernet, the standard 10 Megabite/sec networking hardware; Appletalk is Apple's set of networking protocols; TCP/IP is a standard networking protocol. (Although Appletalk is usually used with LocalTalk, and TCP/IP is usually used with Ethernet, any protocol can concievable run over any hardware.) NFS is a standard file serving protocol; Appleshare is Apple's file serving protocol. There are also systems available that let TCP/IP aware programs communicate with other machines on an Ethernet. 1. Kinetics sells Ethernet boards for all versions of the Macintosh; it also sells a TCP/IP (Ethernet) to TCP/IP (LocalTalk) bridge, called the FastPath. 2. NCSA maintains a professional-looking TELNET package for the PC and the Mac which supports remote login, multiple VT102 emulation, Tek 4014 emulation, subnetting, and dynamic IP address assignment via RARP. I think this is shipped with Kinetics equipment. 3. Either Stanford or Columbia maintain something called KIP and CAP which seems to be another TCP/IP package; this might also be used with the FastPath or Gatorbox. 4. Phil Karn's KA9Q package is another TCP/IP implementation. It is free for non-commerical use, and source is available. Thanks to everybody who sent in corrections. -- Dan Kegel "We had to get it passed before the columnists attacked!" srs!dan@cs.rochester.edu rochester!srs!dan dan%srs.uucp@harvard.harvard.edu  -----------[000126][next][prev][last][first]---------------------------------------------------- Date: 11 Aug 88 20:16:21 GMT From: caip.rutgers.edu!aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu (Charles Hedrick) To: tcp-ip@sri-nic.arpa Subject: Re: IEEE 802.2, 802.3 & Ethernet questions Arrgggg. There are two issues: electrical and software. Electrically, Ethernet v1, Ethernet v2, and IEEE 802.3 all put out signals that are more or less compatible on the cable. We've seen problems with Ethernet v1 talking to IEEE now and then (where we have a choice, we standardize on Ethernet v2), but by and large you can mix all three types of equipment on the same cable. However between the transceiver and the computer things are less free. Each given computer's interface board is designed with a particular type of transceiver in mind. You must use the one they had in mind. These days most equipment is designed to take either Ethernet v2 or IEEE 802.3 transceivers. The two standards are very close electrically. Some equipment can even deal with all three types of transceiver. But there is still equipment around (and probably even being sold) than can deal only with Ethernet v1 transceivers. So make sure your vendor tells you. (To make things worse, the people you can get to normally don't know the difference between the three standards, so it is sometimes hard to find out. We normally assume Ethernet v2 unless stated otherwise.) There are also differences that show up in the software rather than the hardware. 802.3, which is nominally about the hardware, does reflect this difference in its terminology, but it shows up mostly in 802.2. Ethernet uses an Ethernet type code in the Ethernet header. It does not use 802.2 By using the type codes, the device-level software is able to determine the protocol and dispatch the packet to the right protocol-handling software. IEEE did one of those wonderful political numbers on us and changed the type field to a length field. They then added 802.2 which has ways to figure out what the packet is about. Mostly TCP/IP implementors have ignored 802.2 and continued to use the Ethernet type code rather than the length code that 802.3 describes. The vendors generally claim that their systems support 802.3, but to the extent that they are putting a type code rather than a length code in the Ethernet header, one could claim that actually are supporting Ethernet v2 rather than 802.3. This is all done for compatibility. Since the original implementations were done in the days before the IEEE standards, it is natural that they used the Ethernet type code rather than 802.2. Newer implementations then continued this, in order to be able to talk to the older ones. Vendors that put out a product that insists on using 802.2 find that they can't talk to anyone. (This happened to H-P with the 3000.) Their customers tend to demand a change. However for newer networks that following the 802.x standards (e.g. token and broadband networks), it's almost certain that full 802.x, including 802.2, will be used. That's what the new 802.x RFC is about. It should probably contain a warning explaining this situation, so that people realize that it typically does not apply to Ethernet. In order to make it easier to design bridges that will connect a new network to an old one, some vendors are probably going to support both formats on Ethernet/802.3. It is possible to design software that can deal with both types of encapsulation. When you want to talk to somebody, you encode an ARP request both ways, send them both, and see which one he answers. In the ARP table, you have a flag indicating which encapsulation to use with that host. However at the moment most software for 802.3 was really designed for Ethernet, and does not use 802.2.  -----------[000127][next][prev][last][first]---------------------------------------------------- Date: 11 Aug 88 23:46:18 GMT From: holmes@ford-wdl1.arpa (Randy D. Holmes) To: tcp-ip@sri-nic.arpa Subject: MAC II timing on ethernet ?  I was wondering if anybody could get me started in the right direction in a search for some timing stats. I'm trying to find out how fast a Mac II can transfer a large amount (1M+) of data to a second Mac II on an ethernet with various currently available configurations. Tests from RAM to RAM would be ideal, but at this point I'll settle for anything. I have contacted Kinetics, 3Com, and Apple, but nobody will admit to any bench marks. Any help at all would be greatly appreciated Randy Holmes holmes@ford-wdl1.arpa  -----------[000128][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 88 00:09:38 GMT From: admin.cognet.ucla.edu!casey@CS.UCLA.EDU (Casey Leedom) To: tcp-ip@sri-nic.arpa Subject: Re: IEEE 802.2, 802.3 & Ethernet questions In article <Aug.11.16.16.21.1988.23584@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: > > IEEE did one of those wonderful political numbers on us and changed the > type field to a length field. They then added 802.2 which has ways to > figure out what the packet is about. So just how complicated is this predicate that figures out what type of packet has been received. It's got to be more complicated than simply doing a case statement based on a type field. A prevoius article on this subject also mentioned the political nature of this design decision. It stated that IEEE wanted everyone to be at equal disadvantage. Does this make it right to make a bad design? > Mostly TCP/IP implementors have ignored 802.2 and continued to use the > Ethernet type code rather than the length code that 802.3 describes. Did you mean that second IEEE number (802.3 near the end of the sentence) to be 802.2? I'm still not exactly sure what the differences between 802.2 and 802.3 are, but I don't want to waste any more of your or the net's time. Thanks for the info. Casey  -----------[000129][next][prev][last][first]---------------------------------------------------- Date: Fri, 12 Aug 88 08:50:49 EDT From: george@iguanodon.cis.ohio-state.edu (George M. Jones) To: he%idt.unit.no@relay.cs.net Cc: bzs@bu-cs.bu.edu, MURAKAMI@ntt-20.ntt.jp, tcp-ip@sri-nic.arpa, crispin@sumex-aim.stanford.edu, nowicki@sun.com, celeste@coherent.com, earle@mahendo.Jpl.Nasa.Gov Subject: Summary: Proxy ARP on SUN  I propose that it should be FTP'able also. For those of you in a hurry, you can pick it up from loke.unit.no (IP: 128.39.5.27), in ~ftp/pub/proxyarpd.shar. It's only ~26KBytes. However, for most of you this is the other side of the Atlantic, so don't expect too god performance... I managed to successfully FTP it at the blinding rate of 9.8 characters/sec. It is now available for anonymous FTP from tut.cis.ohio-state.edu (128.146.8.60) as as ~ftp/proxydarp/proxyarpd.shar ---George Jones OSU Computer & Inf. Science 2036 Neil Ave.,Columbus,Ohio 43210. 614-292-7325 george@cis.ohio-state.edu or ...!osu-cis!george Quality of life can be measured as the inverse of lawyers per thousand.  -----------[000130][next][prev][last][first]---------------------------------------------------- Date: Fri, 12 Aug 88 12:48:36 EDT From: jbvb@vax.ftp.com (James Van Bokkelen) To: tcp-ip@sri-nic.arpa Subject: TCP/IP for Token Ring As far as I know, you can get TCP/IP for 802.5 Token Ring from these vendors, for these machines: IBM PC/XT/AT/PS/2, PC/RT, 9370 & larger VM machines. Proteon PC/XT/AT, P4200 IP router FTP Software PC/XT/AT/PS/2 Some of the other VM & MVS TCP/IP vendors may also support 802.5, but I don't know for sure. James VanBokkelen FTP Software Inc.  -----------[000131][next][prev][last][first]---------------------------------------------------- Date: Fri, 12 Aug 88 13:18:21 EDT From: map@gaak.LCS.MIT.EDU (Michael A. Patton) To: admin.cognet.ucla.edu!casey@cs.ucla.edu Cc: tcp-ip@sri-nic.arpa Subject: IEEE 802.2, 802.3 & Ethernet questions  Date: 12 Aug 88 00:09:38 GMT From: admin.cognet.ucla.edu!casey@cs.ucla.edu (Casey Leedom) [...] So just how complicated is this predicate that figures out what type of packet has been received. It's got to be more complicated than simply doing a case statement based on a type field. If you already have a case statement for Ethernet types you presumably have a default clause to discard types you don't want. You just add a simple test here that if the code is less than the max length, treat it as an IEEE802 packet. The feature of this technique is it doesn't slow down the processing of any traffic you presently deal with and can deal with IEEE802 nearly as fast as assuming that's all there is. If you want to be IEEE802 biased, you could put the max length test on the outside and do the ether-type dispatch in the "too long" clause. Again normal 802 traffic isn't slowed by the ability to handle Ethernet, and Ethernet traffic isn't much worse off. If you have a reasonable compiler, the protocol you're biased for executes an identical instruction stream as in the one protocol case and the other is charged only a few (probably 2) extra instructions. The only problem is you may get to do more processing of packets that get thrown away. Mike Patton, Network Manager Laboratory for Computer Science Massachusetts Institute of Technology Disclaimer: The opinions expressed above are a figment of the phosphor on your screen and do not represent the views of MIT, LCS, or MAP. Your mileage may vary, void where prohibited by law. :-)  -----------[000132][next][prev][last][first]---------------------------------------------------- Date: Fri, 12 Aug 88 14:54:33 EST From: HEILNER_K@VAXC.STEVENS-TECH.EDU To: tcp-ip@sri-nic.arpa Subject: Help with TCP problem Hello- I am running CMU V6.2(6.3 is on order)TCP/IP on a VAX 11/785. We seem to have developed a strange problem. We can TELNET and FTP into other networks from this node but we seem to have lost connectivity with our network. All other TCP nodes on our network can connect with each other but can not connect with the 11/785. With logging enabled I get the following message: 23:59:58.26 Log event mask set to 80000000 23:59:57.84 Memory Mgmt. Fault detected., EC = 00158214 Can someone help me with this....thanks in advance Keith Heilner Heilner_k@sitvxb Heilner_k@vaxb.stevens-tech.edu ------------  -----------[000133][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 88 12:58:20 GMT From: root@yale.UUCP (Celray Stalk) To: comp.sys.mac,comp.protocols.tcp-ip Subject: Re: Update on "NFS and TCP/IP for the Mac"  I just received an information packet from Kinetics. Included was a paper bound book "Network Primer" published by Kinetics. Section 5, Network Software, mentions a package developed by the Center for Information Technology Integration (CITI) group of the Information Technology Division of the University of Michigan called MacNFS. According to the article, "Apple Computer has recently acquired the rights to MacNFS. For availability information, contact Apple or CITI." Anyone have information on this?  -----------[000134][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 88 13:16:33 GMT From: iguanodon.cis.ohio-state.edu!george@tut.cis.ohio-state.edu (George M. Jones) To: tcp-ip@sri-nic.arpa Subject: Re: Summary: Proxy ARP on SUN he@idt.unit.no writes: I propose that it should be FTP'able also. For those of you in a hurry, you can pick it up from loke.unit.no (IP: 128.39.5.27), in ~ftp/pub/proxyarpd.shar. It's only ~26KBytes. However, for most of you this is the other side of the Atlantic, so don't expect too god performance... It is now available on tut.cis.ohio-state.edu (128.146.8.60) as ~ftp/proxyarp/proxyarpd.shar. ---George Jones -=- OSU Computer & Inf. Science 2036 Neil Ave.,Columbus,Ohio 43210. 614-292-7325 george@cis.ohio-state.edu or ...!osu-cis!george Quality of life can be measured as the inverse of lawyers per thousand.  -----------[000135][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 88 16:21:41 GMT From: rlgvax!dennis@uunet.uu.net (Dennis.Bednar) To: tcp-ip@sri-nic.arpa Subject: Re: Summary: Proxy ARP on SUN In article <8808101322.AA20581@bu-cs.bu.edu>, bzs%bu-cs.bu.EDU%bu-it.bu.EDU@ntt-sh.ntt.jp (Barry Shein) writes: > I wrote a proxy arp based upon Sun's rarpd server ... Could someone please explain what is "proxy arp"? Thanks in advance. -- FullName: Dennis Bednar UUCP: {uunet|sundc}!rlgvax!dennis USMail: CCI; 11490 Commerce Park Dr.; Reston VA 22091 Telephone: +1 703 648 3300  -----------[000136][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 88 16:39:13 GMT From: panda!teddy!rdt@husc6.harvard.edu (Ron D. Thornton) To: tcp-ip@sri-nic.arpa Subject: Re: IEEE 802.2, 802.3 & Ethernet questions  As noted, the differences between V1 ethernet, V2 ethernet, and 802.2/802.3 are both electrical and header format. On the coax, all 3 versions are fairly compatible. I don't have the specifications in front of me, but IEEE probably changed some edge specifications just to be different. On the tranceiver to controller electrical side: Version 1 used DC coupling on the tranceiver cable interface which make it totally incompatible with Version 2 or 802.3 tranceivers (some tranceivers/ controllers can be strapped for either DC or AC coupling). Version 2 changed to AC coupling on the tranceiver cable interface. V2 also specified that collision detect from the tranceiver should be forced on when a transmission is ended to provide a heartbeat or verification from the tranceiver. 803.2 took Version 2, played with some differential levels and driver/receiver specifications but remains reasonable compatible with the Version 2 tranceiver interface. It also added an optional control signal from the controller to the tranceiver and added an optional 3rd state to the collision presence signal (oscillate at 5Mhz instead of 10Mhz). On the packet header side: All 3 versions define the first 6 octets as destination address, and next 6 as source address. Version 1 and 2 ethernet use the next 2 octets as type field to define the next higher protocol level. 802.3 uses those 2 octets as a length field. Short packets may need to be padded and this field tells where data ends and padding starts. The ethernet specs leave it to the next level in the protocol to determine what is data and what is pad. 802.3 relys on the next level up, 802.2 to define more octets that are then used to determine the next level of protocol. There is an escape in the 802.3 header specification that allow 802.3 and ethernet packets to co-exist. The maximum packet length is 1500 and any 802.3 packet with a length field greater than maximum can be used in a user defined fashion. By only using ethernet type codes greater than 1500 you know at a glance if a packet is 802.3 or ethernet. All internet type codes have values greater than 1500. -Ron- rdt@genrad.COM  -----------[000137][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 88 21:48:05 GMT From: amdahl!cerebus!edb@ames.arc.nasa.gov (Edward Bunch) To: tcp-ip@sri-nic.arpa Subject: Re: IEEE 802.2, 802.3 & Ethernet questions I have a practical question. When dealing with tranceiver cables, how does one tell the difference between the three? I was told once that on a Ethernet tranceiver cable pin 1 (ground) was missing; ground really being on pin 7. Is this true? Need I worry about the type of tranceiver cable I use? The cables are rarely marked "For use with 802.3 etc.". -- Edward A. Bunch Fujitsu America, Inc. Computer Support and Administation. {uunet,amdahl,sun}!cerebus!edb  -----------[000138][next][prev][last][first]---------------------------------------------------- Date: Sat, 13 Aug 88 09:47:41 EDT From: bzs%bu-cs.bu.edu@bu-it.BU.EDU To: rlgvax!dennis@uunet.uu.net Cc: tcp-ip@sri-nic.ARPA Subject: Summary: Proxy ARP on SUN  >In article <8808101322.AA20581@bu-cs.bu.edu>, bzs%bu-cs.bu.EDU%bu-it.bu.EDU@ntt-sh.ntt.jp (Barry Shein) writes: >> I wrote a proxy arp based upon Sun's rarpd server ... > >Could someone please explain what is "proxy arp"? >Thanks in advance. >-- >FullName: Dennis Bednar I'll be explaining it at a talk at Interop88...ok, ok, that's not what you wanted to hear. In short, a non-subnet host will broadcast an ARP for a host that's actually on another subnet and won't hear it (why?) A proxy arp daemon responds with the hardware address of the gateway the packets should be sent to (possibly, but not necessarily, itself.) The original host doesn't know better and sends subsequent traffic to that gateway which then forwards the packets appropriately. See, I believe, RFC's 925 and 1027. Doug Comer's latest text also has a section on it. -Barry Shein  -----------[000139][next][prev][last][first]---------------------------------------------------- Date: 13 Aug 88 19:42:12 GMT From: minshall@kinetics.UUCP (Greg Minshall) To: comp.sys.mac,comp.protocols.tcp-ip Subject: Re: Summary: TCP/IP and NFS for the Mac  Just to add a bit to the list, Kinetics has recently announced a "TCPort Toolkit", which includes TCP/IP support for the Mac (installed as drivers) and a programming library to interface to the drivers (and a "socket emulation" library). It isn't available until October or so (I haven't seen the announcement). (In addition, there is a separate product with telnet, ftp, etc.) Greg Minshall Kinetics ...ucbvax!mtxinu!kinetics!minshall (415)947-0998  -----------[000140][next][prev][last][first]---------------------------------------------------- Date: 13 Aug 88 21:13:10 GMT From: motsj1!mcdchg!clyde!watmath!utgpu!utzoo!henry@hplabs.hp.com (Henry Spencer) To: tcp-ip@sri-nic.arpa Subject: Re: Summary: Proxy ARP on SUN In article <972@rlgvax.UUCP> dennis@rlgvax.UUCP (Dennis.Bednar) writes: >Could someone please explain what is "proxy arp"? Proxp arp is when one machine answers an ARP request aimed at another, giving its own physical address rather than the target's address. I.e., "send anything meant for him to me". The main purpose of this is to hide network partitioning: if the gateway between two physical networks does proxy ARP on network A for all machines on network B, and vice-versa, the two networks look like one on the IP level. It's sort of a poor man's subnetting. The main advantage is that it hides the topology completely and can be used with hosts that don't do subnetting properly. The main disadvantage is that it's a special-purpose hack that doesn't work well in unfavorable circumstances (e.g. complex topologies). -- Intel CPUs are not defective, | Henry Spencer at U of Toronto Zoology they just act that way. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu  -----------[000141][next][prev][last][first]---------------------------------------------------- Date: 14 Aug 88 05:44:19 GMT From: (Casey Leedom) To: tcp-ip@sri-nic.arpa Subject: Re: Summary: Proxy ARP on SUN In article <8808121250.AA03525@iguanodon.cis.ohio-state.edu> george@tut.cis.ohio-state.edu writes (George Jones): > > I managed to successfully FTP it at the blinding rate of 9.8 characters/sec. > It is now available for anonymous FTP from tut.cis.ohio-state.edu > (128.146.8.60) as as ~ftp/proxydarp/proxyarpd.shar I had such a difficult time getting through to Ohio State, I left copies of the shar in ~ftp/pub on lll-crg.llnl.gov (128.115.1.1) and cs.ucla.edu (128.97.28.20). Casey  -----------[000142][next][prev][last][first]---------------------------------------------------- Date: Mon, 15 Aug 88 08:36:22 PDT From: DDN Reference <NIC@SRI-NIC.ARPA> To: att!chinet!mcdchg!usenet@ucbvax.berkeley.edu Cc: tcp-ip@SRI-NIC.ARPA, nic@SRI-NIC.ARPA Subject: Learning Tree Software and Internet Advertising We thought you should be made aware of the usage policies of the DDN. Read "DDN" wherever "ARPANET" is mentioned. The ARPANET was not designed for commercial gain such as product advert- isement. Learning Tree Software should pursue other means of making their products known. The following paragraphs from the DDN New User Guide, which the DDN Network Information Center produced for the Defense Communications Agency, summarize the purpose of the ARPANET. Note: ARPANET Traffic originating from other networks still needs to follow the guidelines. The purpose of the ARPANET is to provide a facility for advanced packet-switched communications technologies research and experimental communication support of government-sponsored university computer science research. Consequently, access to, and use of, ARPANET will not be authorized to support operational (as opposed to experimental) communication requirements. Such operational facilities are provided for DoD users by the DDN (such as MILNET), and for others by public and private packet-switched networks (such as TYMNET or TELENET). Users of ARPANET may only use the network to conduct the official business for which their access was authorized. They must not violate privacy or any other applicable laws, and must not use the network for private gain or for commercial purposes, such as advertising or recruiting. -------  -----------[000143][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 88 10:31:00 PDT From: Dave Crocker <dcrocker@TWG.COM> To: tcp-ip <tcp-ip@sri-nic.arpa> Subject: Re: Van's algorithms in Streams Steve Alexander cites Lachman's Streams implementation as containing Van's performance enhancements. While the congestion control enhancements drop in relatively easily, it is my understanding that Van has not yet released his header-prediction changes. I would be interested to know the origins of the code that Lachman acquired. Steve? With respect to the ease of adding Berkeley code to Streams, the key is the degree of conformance to streams architecture. One can be formally conformant, but still have variations is certain features. Dave  -----------[000144][next][prev][last][first]---------------------------------------------------- Date: Mon, 15 Aug 88 10:05:00 CDT From: anil@flora.wustl.edu (Anil Bhatia) To: tcp-ip%sri-nic.arpa@uunet.UU.NET Subject: Technical report "Comments on Proposed Transport Protocols"  RE: Draft of Techinal Report Comments on Proposed Transport Protocols Anil Bhatia James Sterbenz Guru Parulkar guru@flora.wustl.edu A POSTSCRIPT version of the draft of our technical report is now available. This can be copied over the net by anonymous FTP on "flora.wustl.edu" with any password. - anil anil@flora.wustl.edu --------------------------------------------------- Direct further enquiries to: Guru Parulkar guru@flora.wustl.edu  -----------[000145][next][prev][last][first]---------------------------------------------------- Date: Mon 15 Aug 88 09:37:57-EDT From: Del Waggoner <Waggoner-D@OSU-20.IRCC.OHIO-STATE.EDU> To: TCP-IP@SRI-NIC.ARPA Cc: Waggoner-D@OSU-20.IRCC.OHIO-STATE.EDU Subject: Re: TCP/IP for Token Ring thanks for the information... -------  -----------[000146][next][prev][last][first]---------------------------------------------------- Date: Mon 15 Aug 88 18:12:25-PDT From: William Westfield <BILLW@MATHOM.CISCO.COM> To: dcrocker@TWG.COM Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Van's algorithms in Streams Grumble. All things considered, Van's congestion control enhancments are MUCH more important than the header-prediction changes. Bill Westfield cisco Systems. -------  -----------[000147][next][prev][last][first]---------------------------------------------------- Date: 16 Aug 88 00:52:43 GMT From: jerry@olivey.olivetti.com (Jerry Aguirre) To: comp.sources.wanted,comp.protocols.tcp-ip Subject: Wanted: rarp or bootp for 4.3BSD  I need to be able to run either a RARP or Bootp server on a 4.3BSD Vax. Any pointers to where I can obtain either would be much appreciated. Jerry Aguirre @ Olivetti ATC  -----------[000148][next][prev][last][first]---------------------------------------------------- Date: Tue, 16 Aug 88 15:40:09 PST From: geoff@Fernwood.MPK.CA.US (the tty of Geoff Goodfellow) To: tcp-ip@sri-nic.arpa Subject: BOF on SLIP at Interop 88 -- Thurs Sept 19th. There will be a birds of a feather session on SLIP at the InterOP '88 Conference Thursday Sept 29th after the formal sessions conclude. If you have SLIP hackery to share, please contact me. I'd like to schedule a few 10 minute presentations at the start of the BOF on interesting works involving SLIP, completed or in progress. Topics might be: dynamic dial-up SLIPing / SLIP header compression / SLIP security & authentication / itinerant host SLIPing / SLIP built into modems / SLIP over Value Added Networks / Etc / other suggestions welcomed... Geoff Goodfellow Anterior Technology Geoff@Fernwood.MPK.CA.US (415) 328-5615 ------- Interop is soliciting topics for other BOF sessions. If you feel you have a topic of interest, contact Advanced Computing Environments at (415) 941-3399 to schedule a discussion during the conference. -------  -----------[000149][next][prev][last][first]---------------------------------------------------- Date: 16 Aug 88 14:21:07 GMT From: mcvax!ukc!etive!adam@uunet.uu.net (A Hamilton) To: tcp-ip@sri-nic.arpa Subject: Re: Ether loopback... In article <12420888971.28.BILLW@MATHOM.CISCO.COM> BILLW@MATHOM.CISCO.COM (William Westfield) writes: : Some ethernet controllers are capable of hearing packets that they are : transmitting as they are being transmitted. If this is true, then : sending a packet to yourself is a good way to check whether the : ethernet is in good shape - it checks the transceiver and the ethernet : cable as well as the controller. : Actually not so. Many ethernet controllers have a smart processor which will check for a loopback packet and return it to the host as if it had been received from the Ethernet. But the transceivers CANNOT listen during their own transmission. In article <88Aug7.130257hst.4295@dorsai.ics.hawaii.edu> torben@DORSAI.ICS.HAWAII.EDU ("Torben N. Nielsen") writes: > >Anyone happen to know if there're legitimate reasons for sending to yourself >onan Ethernet? That is, Ethernet packets where the source and the destination >address are identical? Seems pointless since as far as I know, you cannot read >packets you yourself transmitted off of the wire..... Am I wrong? > > Torben No, you are right (in terms of hardware but it has to be fixed by some form of s/w [see above]) but it is not pointless. There are 2 reasons I am aware of. 1) The IEEE 802.3 spec. says that all stations should be capable of receiving a self-addressed Ethernet packet as though it were received from the net (section 2.3.3.5). The IEEE 802.2 spec. requires a station to transmit such a packet at startup so as to perform a "duplicate address check". (The packet is an IEEE 802.2 TEST packet). It is required that exactly one reply is received in an appropriate period of time (this one packet is from the originating station itself which replies to this TEST packet as to any other). Section 6.9.2 is the relevant bit in my (out-of-date) copy. 2) Loopback tests are often required if no other station supports the relevant s/w. They can also be useful as they give very different timing effects. Under these circumstances it can be very useful if packets go out onto the real network where they can be picked up by a monitor, rather than being soft looped entirely. Adam Hamilton  -----------[000150][next][prev][last][first]---------------------------------------------------- Date: 16 Aug 88 18:29:00 GMT From: clio!berger@uxc.cso.uiuc.edu To: tcp-ip@sri-nic.arpa Subject: Re: TFTP on PS/2  Can you make do with NCSA Telnet? I believe it supports the micro channel architecture. Mike Berger Department of Statistics Science, Technology, and Society University of Illinois berger@clio.las.uiuc.edu {ihnp4 | convex | pur-ee}!uiucuxc!clio!berger  -----------[000151][next][prev][last][first]---------------------------------------------------- Date: 16 Aug 88 19:59:17 GMT From: mcvax!enea!kth!draken!ragge@uunet.uu.net (Ragnar Sundblad) To: tcp-ip@sri-nic.arpa Subject: Re: MAC II timing on ethernet ? In article <3950005@wdl1.UUCP> holmes@wdl1.UUCP (Randy D. Holmes) writes: > I was wondering if anybody could get me started in the right direction > in a search for some timing stats. I'm trying to find out how fast > a Mac II can transfer a large amount (1M+) of data to a second Mac II > on an ethernet with various currently available configurations. > Tests from RAM to RAM would be ideal, but at this point I'll settle > for anything. I have contacted Kinetics, 3Com, and Apple, but nobody > will admit to any bench marks. Any help at all would be greatly appreciated I made some stupid programs to benchmark ethernet bridges with MacIIs. One of them just sends ethernet packets at the highest speed possible, the other just receives and counts them. With these I got 98-99 percent, meaning ~1.24MByte/s. The NUBUS and MacII should have no troubles keeping this speed. The bottleneck is usually the ethernet driver, not the hardware.  -----------[000152][next][prev][last][first]---------------------------------------------------- Date: 17 Aug 88 05:15:00 EDT From: "NRL::FARNHAM" <farnham%nrl.decnet@nrl.arpa> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Cc: farnham Subject: THANKS!! To all the wonderfully kind people out their in TCP/IP land who helped me gather beginners info. Thank you, I received a great deal of helpful information and have finally digested it and am moving on to the reading list I was sent. I really appreciated all of the feedback and wanted you all to know I thought it was great that so many of you responded to my queries. Emily D. Farnham code 2861.7 Naval Research Laboratory Washington, D.C.  -----------[000153][next][prev][last][first]---------------------------------------------------- Date: Wed, 17 Aug 88 08:51:46 EDT From: ted@nadc.arpa (T. Calkins) To: farnham%nrl.decnet@NRL3.ARPA, tcp-ip@sri-nic.arpa Cc: farnham@sri-nic.arpa Subject: Re: THANKS!! >From tcp-ip-RELAY@SRI-NIC.ARPA Wed Aug 17 08:32:48 1988 >Received: by NADC.ARPA (5.51/1.0 ) > id AA28307; Wed, 17 Aug 88 08:32:34 EDT >Message-Id: <8808171232.AA28307@NADC.ARPA> >Received: from nrl.arpa by SRI-NIC.ARPA with TCP; Wed, 17 Aug 88 02:19:20 PDT >Date: 17 Aug 88 05:15:00 EDT >From: "NRL::FARNHAM" <farnham%nrl.decnet@nrl.arpa> >Subject: THANKS!! >To: "tcp-ip" <tcp-ip@sri-nic.arpa> >Cc: farnham@SRI-NIC.ARPA >Status: R > >To all the wonderfully kind people out their in TCP/IP land who helped >me gather beginners info. >Thank you, I received a great deal of helpful information and have finally >digested it and am moving on to the reading list I was sent. I really >appreciated all of the feedback and wanted you all to know I thought it >was great that so many of you responded to my queries. > > > Emily D. Farnham > code 2861.7 > Naval Research Laboratory > Washington, D.C. > > --------------------------- Emily: Would you be interested in "sharing" the TCP/IP "beginners info" that you recieved from the net? If yes, mail it directly to me: ted@NADC.ARPA. If no, thanks anyway. For now, Ted Calkins ( ted@NADC.ARPA ) NADC = Naval Air Development Center Warminster, PA  -----------[000154][next][prev][last][first]---------------------------------------------------- Date: 17 Aug 88 07:59:37 GMT From: david@elroy.jpl.nasa.gov (David Robinson) To: tcp-ip@sri-nic.arpa Subject: proxyarpd for SunOS 4.0 I have finished a port of proxyarpd to SunOS 4.0 using the new STREAMS NIT modules. It is available for anonymous FTP from elroy.jpl.nasa.gov [128.149.1.100] I have sent the changes back to the author also. -- David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov ARPA {cit-vax,ames}!elroy!david UUCP Disclaimer: No one listens to me anyway!  -----------[000155][next][prev][last][first]---------------------------------------------------- Date: Wed, 17 Aug 88 17:09:56 EDT From: Philip Prindeville <philipp@Larry.McRCIM.McGill.EDU> To: geoff@fernwood.mpk.ca.us Cc: TCP/IP <tcp-ip@sri-nic.arpa> Subject: Re: BOF on SLIP at Interop 88 -- Thurs Sept 19th. SLIP is currently being refined by the IETF Point-to-Point Protocol working group. Rather than have duplication of effort, you should get in contact with Dre Perkins <ddp@andrew.cmu.edu> or the interest mailing list <ietf-ppp-interest@ucdavis.edu>... -Philip  -----------[000156][next][prev][last][first]---------------------------------------------------- Date: Wed, 17 Aug 88 21:31:55 -0400 From: Craig Partridge <craig@SH.CS.NET> To: tcp-ip@sri-nic.ARPA Subject: Van's algorithms  For people interested in Van's work, I suggest you read the paper he is giving at SIGCOMM '88 this week. It explains most of the performance improvements he has made. (SIGCOMM is probably the most important networking conference of the year -- consider this a plug to join ACM SIGCOMM). Craig  -----------[000157][next][prev][last][first]---------------------------------------------------- Date: Wed, 17 Aug 88 10:12 +0300 From: Yehavi Bourvine +972-2-584279 <YEHAVI%HUJIVMS.BITNET@CUNYVM.CUNY.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: Tcp/Ip code for Unix V. We are looking for TcpIp sources implemented for system-V, version 5.2. Does anyone have such sources and can give them? The low-level driver is preferably EXOS, but others will be good too. Thanks in advance, __Yehavi: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Yehavi Bourvine, Phones: +972-2-584279, H Computation Center, +972-2-521574 H The Hebrew University of Jerusalem, H Givat-Ram, Jerusalem 91904 H H H Fax: +972-2-527349 HH H BITnet: YEHAVI@HUJIVMS H H InterNet: YEHAVI@VMS.HUJI.AC.IL H Israeli DECnet: HUJICC::YEHAVI H =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=  -----------[000158][next][prev][last][first]---------------------------------------------------- Date: 17 Aug 88 18:19:22 GMT From: awm@doc.ic.ac.uk (Aled Morris) To: comp.unix.wizards,comp.protocols.tcp-ip Subject: /etc/services  Below, I have included a copy of my /etc/services file. I am trying to build a comprehensive table of known ports, starting from "Assigned Numbers" (the most recent version in my possession is RFC1010), and including as many operating system quirks as is feasible. Hopefully, the publication of this in Unix /etc/services format will encourage the use of standard port numbers and names, and avoid future clashes (some hope! :-) There are no doubt a large number of holes in this (my first attempt). Please mail me any corrections, and I will update my master copy. A number of services have been given protocol type "new", if you know better, please mail me. If you have already done any of this, please mail me, I don't want to duplicate anyone's effort! I assume that with the emergence of ISO networking standards, /etc/services will be updated. If anyone has implemented ISO versions of any of these services, I would be glad to include them---I expect the entry would be something like: finger 79/tp4 # ISO "Finger" server MAIL ONLY PLEASE, DON'T FOLLOWUP TO THE NET. ^^^^ ^^^^ ^^^^^^ Aled Morris systems programmer mail: awm@doc.ic.ac.uk | Department of Computing uucp: ..!ukc!icdoc!awm | Imperial College talk: 01-589-5111x5085 | 180 Queens Gate, London SW7 2BZ # # /etc/services: Network services, Internet style # Aled Morris (awm@doc.ic.ac.uk), 15th Aug, 1988 # # See RFC1010 "Assigned Numbers" (issued May, 1987) for details. # # Operating systems consulted were: # 4.3BSD, 4.2BSD, SunOS 4.0_Export, Gould UTX/32 2.1a, HP-UX 6.0, # Dynix 3.0.8 # # Notes: # RJE (5) all implementations used port 77 # LOGIN (49) all implementations use port 513 # MTP (57) the only private terminal access protocol I could find # PRINTER (35) all implementations use port 515 # PORTMAP (111) is the name used by HP-UX for SUNRPC # LINK (245) many 4.2 derived systems use the name for port 87 # unknown protocols are marked "new" # # NAME PORT/PROTOCOL ALIASES COMMENTS # ---- ---- -------- ------- -------- # reserved 0 # unassigned 1-4 # rje 5 # remote job entry echo 7/tcp echo 7/udp discard 9/tcp sink null discard 9/udp sink null systat 11/tcp users daytime 13/udp daytime 13/tcp netstat 15/tcp # unassigned in RFC1010 qotd 17/tcp quote # Quote of the Day chargen 19/tcp ttytst source # Character Generator chargen 19/udp ttytst source ftp-data 20/tcp ftpdata ftp 21/tcp telnet 23/tcp smtp 25/tcp mail nsw-fe 27/new # NSW User System FE msg-icp 29/new # MSG ICP msg-auth 31/new # MSG Authentication dsp 33/new # Display Support Protocol # 35/new # any private printer server time 37/tcp timserver time 37/udp timserver rlp 39/new resource # Resource Location Protocol graphics 41/new # Graphics name 42/udp nameserver whois 43/tcp nicname # usually to sri-nic mpm-flags 44/new # MPM FLAGS Protocol mpm 45/new # Message Processing Module mpm-snd 46/new # MPM [default send] ni-ftp 47/new # NI FTP #login 49/new # Login Host Protocol la-maint 51/new # IMP Logical Address Maint. domain 53/udp domain 53/tcp isi-gl 55/new # ISI Graphics Language mtp 57/tcp # any private terminal access # 59/new # any private file service ni-mail 61/new # NI MAIL via-ftp 63/new # VIA Systems - FTP tacacs-ds 65/new # TACACS-Database Service bootps 67/new # Bootstrap Protocol Server bootpc 68/new # Bootstrap Protocol Client tftp 69/udp netrjs-1 71/new # Remote Job Service netrjs-2 72/new # Remote Job Service netrjs-3 73/new # Remote Job Service netrjs-4 74/new # Remote Job Service # 75/new # any private dial out service rje 77/tcp netrjs # any private RJE service finger 79/tcp # Finger hosts2-ns 81/new # HOSTS2 Name Server mit-ml-dev 83/new # MIT ML Device mit-ml-dev 85/new # MIT ML Device link 87/tcp ttylink # any private terminal link su-mit-tg 89/new # SU/MIT Telnet Gateway mit-dov 91/new # MIT Dover Spooler dcp 93/new # Device Control Protocol supdup 95/tcp # SUPDUP hostnames 101/tcp hostname # usually to sri-nic iso-tsap 102/tcp # ISO-TSAP x400 103/tcp # ISO Mail (X.400) x400-snd 104/tcp # X.400-SND csnet-ns 105/tcp # Mailbox Name Nameserver rtelnet 107/new # Remote Telnet Service pop-2 109/tcp pop postoffice # Post Office Protocol (rev.2) sunrpc 111/udp portmap # SUN Remote Procedure Call sunrpc 111/tcp portmap auth 113/new # Authentication Service sftp 115/new # Simple File Transfer Protocol uucp-path 117/tcp # UUCP Path Service nntp 119/tcp usenet untp # Network News Transfer erpc 121/new # HYDRA Expedited RPC ntp 123/tcp # Network Time Protocol locus-map 125/new # Locus PC-Interface Net Map locus-con 127/new # Locus PC-Interface Conn Server pwdgen 129/new # Password Generator Protocol cisco-fna 130/new # CISCO FNATIVE cisco-tna 131/new # CISCO TNATIVE cisco-sys 132/new # CISCO SYSMAINT statsrv 133/new # Statistics Service ingres-net 134/new # INGRES-NET Service loc-srv 135/new # Location Service profile 136/new # PROFILE Naming System netbios-ns 137/new # NETBIOS Name Service netbios-dgm 138/new # NETBIOS Datagram Service netbios-ssn 139/new # NETBIOS Session Service emfis-data 140/new # EMFIS Data Service emfis-cntl 141/new # EMFIS Control Service bl-idm 142/new # Britton-Lee IDM NeWS 144/tcp news # Window System sur-meas 243/new # Survey Measurement #link 245/new # LINK # # unassigned 143-159 # reserved 160-223 # unassigned 224-241 # unassigned 247-255 # # KIP AppleTalk interface # official numbers as of April, 1988 # at-rmtp 201/udp # AppleTalk Routing Maintenance at-nbp 202/udp # AppleTalk Name Binding #at-3 203/udp # AppleTalk unused at-echo 204/udp # AppleTalk Echo #at-5 205/udp # AppleTalk unused at-zis 206/udp # AppleTalk Zone Information #at-7 207/udp # AppleTalk Unused #at-8 208/udp # AppleTalk Unused # # Unofficial port assignments. # exec 512/tcp biff 512/udp comsat login 513/tcp who 513/udp whod shell 514/tcp cmd # no passwords used syslog 514/udp printer 515/tcp spooler # experimental talk 517/udp # old talk (bsd4.2, utx2.0) ntalk 518/udp # new talk (bsd4.3, utx3.0) efs 520/tcp # for LucasFilm route 520/udp router routed search 525/tcp searchd # inter-machine search timed 525/udp timeserver tempo 526/tcp newdate courier 530/tcp rpc # experimental conference 531/tcp chat netnews 532/tcp readnews netwall 533/udp # -for emergency broadcasts uucp 540/tcp uucpd # uucp daemon new-rwho 550/udp new-who # experimental remotefs 556/tcp rfs_server rfs # Brunhoff remote filesystem rmonitor 560/udp rmonitord # experimental monitor 561/udp # experimental rlb 1260/tcp # HP-UX ingreslock 1524/tcp nft 1536/tcp # HP-UX nfsd 2049/udp # HP-UX NFS implementation rfa 4672/tcp # HP-UX Remote File Access man 9535/tcp # remote manual server rman 9535/udp # more of same # # the end  -----------[000159][next][prev][last][first]---------------------------------------------------- Date: 17 Aug 88 20:58:59 GMT From: jpm@sauna.hut.fi (Jussi-Pekka Mantere) To: comp.sys.mac,comp.protocols.tcp-ip,comp.protocols.appletalk Subject: Re: Update on "NFS and TCP/IP for the Mac"  In article <951@srs.UUCP>, dan@srs (Dan Kegel) writes: >There seem to be only two systems that let plain old Mac programs >transparantly access files on a remote Unix fileserver: > >1. Cayman Systems' Gatorbox > This box lets Mac applications use files from any NFS file server; How about using Mac files stored on the NFS file server from the Unix side? Will there be three different files for the three Macintosh file forks (info, data & resource)? If so, how will a text file be stored? Especially, is there any character set conversions from US ASCII to a "national" ASCII set (pick your favorite European character set)? > it is also a complete superset of the Kinetics FastPath. Will it be able to run KIP (Kinetics Internet Protocol) code or is it compatible with KIP style dynamic IP address assignment? How will it configure itself to the two networks? Does it "autoconfigure" itself, the way Kinetics FastPath 4 does, or does it require explicit network administration? > Not only does it allow use of TCP/IP protocols on LocalTalk, > but it allows use of AppleTalk protocols on Ethernet, and Is this "EtherTalk" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > translates Apple Filing Protocol requests into NFS requests regardless of > whether they arrive over Ethernet or Appletalk. > Either LocalTalk or Ethernet may be used to connect the Macs to the box; > either thick or thin Ethernet may be specified. > The number of Macs that one Gatorbox can support depends on how often the > Macs need to use the network. > This is a slick box! They built EXACTLY what I was looking for. BUT: Can it be used to access both AppleTalk-in-IP speaking hosts (an Unix host running CAP (Columbia Appletalk Package)) and EtherTalk speaking hosts (a VAX/VMS host with AppleTalk for VMS, a Sun-3 with TOPS for Sun) from Macs speaking either AppleTalk or EtherTalk? To summarize: I'm impressed, but does it work for us? >Terminology: > EtherTalk is Ethernet, the standard 10 Megabite/sec networking hardware; Actually, EtherTalk is another Ethernet-protocol, and not restricted to any particular hardware. For example, a Mac can use EtherTalk over twisted pair wires, or phone lines, with the appropriate hardware. Not necessarily your "standard networking hardware" :-) > Dan Kegel "We had to get it passed before the columnists attacked!" > srs!dan@cs.rochester.edu rochester!srs!dan dan%srs.uucp@harvard.harvard.edu -- Jussi-Pekka Mantere jpm@cs.hut.fi Helsinki University of Technology, Finland jpm@finhutcs.bitnet Laboratory of Information Processing Science + 358 0 451 2487  -----------[000160][next][prev][last][first]---------------------------------------------------- Date: 18 Aug 88 01:41:00 EDT From: "NRL::FARNHAM" <farnham%nrl.decnet@nrl.arpa> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Cc: farnham Subject: Re: Status of NTP? From: NRL::MAILER 29-JUN-1988 12:38 To: NRL::FARNHAM Subj: [From: celeste@coherent.com] Charles Hedrick's tcp/ip intro Return-Path: <celeste@coherent.com> Received: from ames.arc.nasa.gov by nrl.arpa with SMTP ; Wed, 29 Jun 88 12:37:51 EDT Received: Wed, 29 Jun 88 09:33:43 PDT by ames.arc.nasa.gov (5.59/1.2) Received: from frosted.coherent.com by coherent.com (3.2/SMI-3.2) id AA26349; Wed, 29 Jun 88 09:26:40 PDT Received: by frosted.coherent.com (3.2/SMI-3.2) id AA22634; Wed, 29 Jun 88 09:26:40 PDT Date: Wed, 29 Jun 88 09:26:40 PDT From: celeste@coherent.com (Celeste C. Stokely) Message-Id: <8806291626.AA22634@frosted.coherent.com> To: farnham%nrl.DECnet@NRL3.ARPA Subject: Charles Hedrick's tcp/ip intro I'm assuming that this is what you're looking for. If so, enjoy! ..Celeste Stokely Coherent Thought Inc. UUCP: ...!{ames,sun,uunet}!coherent!celeste Domain: celeste@coherent.com Internet: coherent!celeste@ames.arpa or ...@sun.com or ...@uunet.uu.net VOX: 415-493-8805 SNAIL:3350 W. Bayshore Rd. #205, Palo Alto CA 94303 From amdcad!ames!rutgers!topaz.rutgers.edu!hedrick Mon Jun 29 15:40:52 PDT 1987 Article 451 of comp.protocols.tcp-ip: Path: sun!amdcad!ames!rutgers!topaz.rutgers.edu!hedrick >From: hedrick@topaz.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP introduction Message-ID: <12979@topaz.rutgers.edu> Date: 28 Jun 87 07:52:42 GMT Organization: Rutgers Univ., New Brunswick, N.J. Lines: 936 I keep seeing requests on various newsgroups for an introduction to TCP/IP. I also get such requests locally. I believe that the only appropriate description of TCP/IP is the RFC's. However I also think a brief introduction is likely to be helpful before plowing right into them. The following document is an attempt to do that. It also recommends some RFC's to look at and tells you how to get them. -------------------------------- This document is a brief introduction to TCP/IP, followed by advice on what to read for more information. This is not intended to be a complete description, but merely enough of an introduction to allow you to start reading the RFC's. At the end of the document there will be a list of the RFC's that we recommend reading. TCP/IP is a set of protocols developed to allow cooperating computers to share resources across a network. It was developed by a community of researchers centered around the ARPAnet. Certainly the ARPAnet is the best-known TCP/IP network. However as of June, 87, at least 130 different vendors had products that support TCP/IP, and thousands of networks of all kinds use it. First some basic definitions. Although TCP/IP (or IP/TCP) seems to be the most common term these days, most of the documentation refers to the "Internet protocols". The Internet is a collection of networks, including the Arpanet, NSFnet, regional networks such as NYsernet, local networks at a number of University and research institutions, and a number of military networks. The term "Internet" applies to this entire set of networks. The subset of them which is managed by the Department of Defense is referred to as the "DDN" (Defense Data Network). This includes some research-oriented networks, such as the Arpanet, as well as more strictly military ones. (Because much of the funding for Internet protocol developments is done via the DDN organization, the terms Internet and DDN can sometimes seem equivalent.) All of these networks are connected to each other, and users can send messages from any of them to any other (except where security or other policy restrictions control access). Officially speaking, the Internet protocol documents are simply standards adopted by the Internet community for its own use. More recently, the Department of Defense issued a MILSPEC definition of TCP/IP. This was intended to be a more formal definition, appropriate for use in purchasing specifications. However most of the TCP/IP community continues to use the Internet standards. The MILSPEC version is intended to be consistent with it. Whatever it is called, TCP/IP is a family of protocols. A few are basic ones used for many applications. These include IP, TCP, and UDP. Others are protocols for doing specific tasks, e.g. transferring files between computers, sending mail, or finding out who is logged in on another computer. Any real application will use several of these protocols. A typical situation is sending mail. First, there is a protocol for mail. This defines a set of commands which one machine sends to another, e.g. commands to specify who the sender of the message is, who it is being sent to, and then the text of the message. However this protocol assumes that there is a way to communicate reliably between the two computers. Mail, like other application protocols, simply defines a set of commands and messages to be sent. It is designed to be used together with TCP and IP. TCP is responsible for making sure that the commands get through to the other end. It keeps track of what is sent, and retransmitts anything that did not get through. If any message is too large for one packet, e.g. the text of the mail, TCP will split it up into several packets, and make sure that they all arrive correctly. Since these functions are needed for many applications, they are put together into a separate protocol, rather than being part of the specifications for sending mail. You can think of TCP as forming a library of routines that applications can use when they need reliable network communications with another computer. Similarly, TCP calls on the services of IP. Although the services that TCP supplies are needed by many applications, there are still some kinds of applications that don't need them. However there are some services that every application needs. So these services are put together into IP. As with TCP, you can think of IP as a library of routines that TCP calls on, but which is also available to applications that don't use TCP. This strategy of building several levels of protocol is called "layering". We think of the applications programs such as mail, TCP, and IP, as being separate "layers", each of which calls on the services of the layer below it. Generally, TCP/IP applications use 4 layers: - an application protocol such as mail - a protocol such as TCP that provides services need by many applications - IP, which provides the basic service of getting packets to their destination - the protocols needed to manage a specific physical medium, such as Ethernet or a point to point line. TCP/IP is based on the "catenet model". (This is described in more detail in ien-48.txt.) This model assumes that there are a large number of independent networks connected together by gateways. The user should be able to access computers or other resources on any of these networks. Packets will often pass through a dozen different networks before getting to their final destination. The routing needed to accomplish this should be completely invisible to the user. As far as the user is concerned, all he needs to know in order to access another system is an "Internet address". This is an address that looks like 128.6.4.194. It is actually a 32-bit number. However it is normally written as 4 decimal numbers, each representing 8 bits of the address. (The term "octet" is used by Internet documentation for such 8-bit chunks. The term "byte" is not used, because TCP/IP is supported by some computers that have byte sizes other than 8 bits.) Generally the structure of the address gives you some information about how to get to the system. For example, 128.6 is a network number assigned by a central authority to Rutgers University. Rutgers uses the next octet to indicate which of the campus Ethernets is involved. 128.6.4 happens to be an Ethernet used by the Computer Science Department. The last octet allows for up to 254 systems on each Ethernet. Note that 128.6.4.194 and 128.6.5.194 would be different systems. (The structure of an Internet address is described in a bit more detail later.) Of course we normally refer to systems by name, rather than by Internet address. When we specify a name, the network software looks it up in a database, and comes up with the corresponding Internet address. Most of the network software deals strictly in terms of the address. (rfc-882.txt describes the database used to look up names.) TCP/IP is a "connectionless" protocol. Information is transfered in "packets". Each of these packets is sent through the network individually. There are provisions to open connections to systems. However at some level, information is put into packets, and those packets are treated by the network as completely separate. For example, suppose you want to transfer a 15000 octet file. Most networks can't handle a 15000 octet packet. So the protocols will break this up into something like 30 500-octet packets. Each of these packets will be sent to the other end. At that point, they will be put back together into the 15000-octet file. However while those packets are in transit, the network doesn't know that there is any connection between them. It is perfectly possible that packet 14 will actually arrive before packet 13. It is also possible that somewhere in the network, an error will occur, and a packet won't get through at all. In that case, that packet has to be sent again. In fact, there are two separate protocols involved in doing this. TCP (the "transmission control protocol") is responsible for breaking up the message into packets, reassembling them at the other end, resending anything that gets lost, and putting things back in the right order. IP (the "internet protocol") is responsible for routing individual packets. It may seem like TCP is doing all the work. And in small networks that is true. However in the Internet, simply getting a packet to its destination can be a complex job. A connection may require the packet to go through several networks at Rutgers, a serial line to the John von Neuman Supercomputer Center, a couple of Ethernets there, a series of 56Kbaud phone lines to another NSFnet site, and more Ethernets on another campus. Keeping track of the routes to all of the destinations and handling incompatibilities among different transport media turns out to be a complex job. Note that the interface between TCP and IP is fairly simple. TCP simply hands IP a packet with a destination. IP doesn't know how this packet relates to any packet before it or after it. It may have occured to you that something is missing here. We have talked about Internet addresses, but not about how you keep track of multiple connections to a given system. Clearly it isn't enough to get a packet to the right destination. TCP has to know which connection this packet is part of. This task is referred to as "demultiplexing." In fact, there are several levels of demultiplexing going on in TCP/IP. The information needed to do this demultiplexing is contained in a series of "headers". A header is simply a few extra octets tacked onto the beginning of a packet by some protocol in order to keep track of it. It's a lot like putting a letter into an envelope and putting an address on the outside of the envelope. Except with modern networks it happens several times. It's like you put the letter into a little envelope, your secretary puts that into a somewhat bigger envelope, the campus mail center puts that envelope into a still bigger one, etc. Here is an overview of the headers that get stuck on a message that passes through a typical TCP/IP network: We start with a single data stream, say a file you are trying to send to some other computer: ...................................................... TCP breaks it up into managable chunks. (In order to do this, TCP has to know how large a packet your network can handle. Actually, the TCP's at each end say how big a packet they can handle, and then they pick the smallest size.) .... .... .... .... .... .... .... .... TCP puts a header at the front of each packet. This header actually contains at least 20 octets, but the most important ones are a source and destination "port number" and a "sequence number". The port numbers are used to keep track of different conversations. Suppose 3 different people are transferring files. Your TCP might allocate port numbers 1000, 1001, and 1002 to these transfers. When you are sending a packet, this becomes the "source" port number, since you are the source of the packet. Of course the TCP at the other end has assigned a port number of its own for the conversation. Your TCP has to know the port number used by the other end as well. (It finds out when the connection starts, as we will explain below.) It puts this in the "destination" port field. Of course if the other end sends a packet back to you, the source and destination port numbers will be reversed, since then it will be the source and you will be the destination. Each packet has a sequence number. This is used so that the other end can make sure that it gets the packets in the right order, and that it hasn't missed any. (See the TCP specification for details. TCP doesn't number the packets, but the octets. So if there are 500 octets of data in each packet, the first packet might be numbered 0, the second 500, the next 1000, the next 1500, etc.) Finally, I will mention the Checksum. This is a number that is computed by adding up all the octets in the packet (more or less - see the TCP spec). The result is put in the header. TCP at the other end computes the checksum again. If they disagree, then something bad happened to the packet in transmission, and it is thrown away. So here's what the packet looks like now. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | various other junk | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | various other junk | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | other junk | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | your data ... next 500 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... | If we abbreviate the TCP header as "T", the whole file now looks like this: T.... T.... T.... T.... T.... T.... T.... T.... TCP now sends each of these packets to IP. Of course it has to tell IP the Internet address of the computer at the other end. Note that this is all IP is concerned about. It doesn't care about what is in the packet, or even in the TCP header. IP's job is simply to find a route for the packet and get it to the other end. In order to allow gateways or other intermediate systems to forward the packet, it adds its own header. The main things in this header are the source and destination Internet address (32-bit addresses, like 128.6.4.194), the protocol number, and another checksum. The source Internet address is simply the address of your machine. (This is necessary so the other end knows where the packet came from.) The destination Internet address is the address of the other machine. (This is necessary so any gateways in the middle know where you want the packet to go.) The protocol number tells IP at the other end to send the packet to TCP. Although most IP traffic uses TCP, there are other protocols that can use IP, so you have to tell IP which protocol to send the packet to. Finally, the checksum allows IP at the other end to verify that the packet wasn't damaged in transit. Note that TCP and IP have separate checksums. This is because IP doesn't know anything about TCP. As far as IP is concerned, everything after its header is just a bunch of bits. So IP computes a checksum of its own header, and IP at the other end checks it to make sure that the message didn't get damaged in transit. Once IP has tacked on its header, here's what the message looks like: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | various other junk | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | various other junk | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | junk | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TCP header, then your data ...... If we represent the IP header by an "I", your file now looks like this: IT.... IT.... IT.... IT.... IT.... IT.... IT.... IT.... At this point, it's possible that no more headers are needed. If your computer happens to have a direct phone line connecting it to the destination computer, or to a gateway, it may simply send the packets out on the line (though likely a synchronous protocol such as HDLC would be used, and it would add at least a few octets at the beginning and end). However most of our networks these days use Ethernet. So now we have to describe Ethernet's headers. Unfortunately, Ethernet has its own addresses. The people who designed Ethernet wanted to make sure that no two machines would end up with the same Ethernet address. Furthermore, they didn't want the user to have to worry about assigning addresses. So each Ethernet controller comes with an address builtin from the factory. In order to make sure that they would never have to reuse addresses, the Ethernet designers allocated 48 bits for the Ethernet address. People who make Ethernet equipment have to register with a central authority, to make sure that the numbers they assign don't overlap any other manufacturer. Ethernet is a "broadcast medium". That is, it is in effect like an old party line telephone. When you send a packet out on the Ethernet, every machine on the network sees the packet. So something is needed to make sure that the right machine gets it. As you might guess, this involves the Ethernet header. Every Ethernet packet has a 14-octet header that includes the source and destination Ethernet address, and a type code. Each machine is supposed to pay attention only to packets with its own Ethernet address in the destination field. (It's perfectly possible to cheat, which is one reason that Ethernet communications are not terribly secure.) Note that there is no connection between the Ethernet address and the Internet address. Each machine has to have a table of what Ethernet address corresponds to what Internet address. (We will describe how this table is constructed a bit later.) In addition to the addresses, the header contains a type code. The type code is to allow for several different protocol families to be used on the same network. So you can use TCP/IP, DECnet, Xerox NS, etc. at the same time. Each of them will put a different value in the type field. Finally, there is a checksum. The Ethernet controller computes a checksum of the entire packet. When the other end receives the packet, it recomputes the checksum, and throws the packet away if the answer disagrees with the original. The checksum is put on the end of the packet, not in the header. The final result is that your message looks like this: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet destination address (first 32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet dest (last 16 bits) |Ethernet source (first 16 bits)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet source address (last 32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP header, then TCP header, then your data | | | ... | | | end of your data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If we represent the Ethernet header with "E", and the Ethernet checksum with "C", your file now looks like this: EIT....C EIT....C EIT....C EIT....C EIT....C EIT....C When these packets are received by the other end, of course all the headers are removed. The Ethernet interface removes the Ethernet header and the checksum. It looks at the type code. Since the type code is the one assigned to IP, the Ethernet device driver passes the packet up to IP. IP removes the IP header. It looks at the IP protocol field. Since the protocol type is TCP, it passes the packet up to TCP. TCP now looks at the packet sequence number. It uses the sequence numbers and other information to combine all the packets into the original file. The ends our initial summary of TCP/IP. There are still some crucial concepts we haven't gotten to, so we'll now go back and add details in several areas. (For detailed descriptions of the items discussed here see, rfc793.txt for TCP, rfc791.txt for IP, and rfc894.txt and rfc826.txt for sending IP over Ethernet.) Well-known sockets and the applications layer ============================================= So far, we have described how a stream of data is broken up into packets, sent to another computer, and put back together. However something more is needed in order to accomplish anything useful. There has to be a way for you to open a connection to a specified computer, log into it, tell it what file you want, and control the transmission of the file. (If you have a different application in mind, e.g. computer mail, some analogous protocol is needed.) This is done by "application protocols". The application protocols run "on top" of TCP/IP. That is, when they want to send a message, they give the message to TCP. TCP makes sure it gets delivered to the other end. Because TCP and IP take care of all the networking details, the applications protocols can treat a network connection as if it were a simple byte stream, like a terminal or phone line. Before going into more details about applications programs, we have to describe how you find an application. Suppose you want to send a file to a computer whose Internet address is 128.6.4.7. To start the process, you need more than just the Internet address. You have to connect to the file transfer server at the other end. In general, network programs are specialized for a specific set of tasks. Most systems have separate programs to handle file transfers, remote terminal logins, mail, etc. When you connect to 128.6.4.7, you have to specify that you want to talk to the file transfer program. This is done by having "well-known sockets" for each program. Recall that TCP uses port numbers to keep track of individual conversations. User programs normally use more or less random port numbers. However specific port numbers are assigned to the programs that sit waiting for requests. For example, if you want to send a file, you will start a program called "ftp". It will open a connection using some random number, say 1234, for the port number on its end. However it will specify port number 21 for the other end. This is the official port number for the ftp server. Note that there are two different programs involved. You run ftp on your side. This is a program designed to accept commands from your terminal and pass them on to the other end. The program that you talk to on the other machine is the ftp server. It is designed to accept commands from the network connection, rather than an interactive terminal. There is no need for your program to use a well-known socket number for itself. Nobody is trying to find it. However the servers have to have well-known numbers, so that people can open connections to them and start sending them commands. The official port numbers for each program are given in "Assigned Numbers". Note that a connection is actually described by a set of 4 numbers: the Internet address at each end, and the TCP port number at each end. Every packet has all four of those numbers in it. (The Internet addresses are in the IP header, and the TCP port numbers are in the TCP header.) In order to keep things straight, no two connections can have the same set of numbers. However it is enough for any one number to be different. For example, it is perfectly possible for two different users on a machine to be sending files to the same other machine. This could result in connections with the following parameters: Internet addresses TCP ports connection 1 128.6.4.194, 128.6.4.7 1234, 21 connection 2 128.6.4.194, 128.6.4.7 1235, 21 Since the same machines are involved, the Internet addresses are the same. Since they are both doing file transfers, one end of the connection involves the well-known port number for file transfer. The only thing that differs is the port number for the program that the users are running. That's enough of a difference. Generally, at least one end of the connection asks the network software to assign it a port number that is guaranteed to be unique. Normally, it's the user's end, since the server has to use a well-known number. Now that we know how to open connections, let's get back to the applications programs. As mentioned above, once TCP has opened a connection, we have something that might as well be a simple wire. All the hard parts are handled by TCP and IP. However we still need some agreement as to what we send over this connection. In effect this is simply an agreement on what set of commands the application will understand, and the format in which they are to be sent. Generally, what is sent is a combination of commands and data. They use context to differentiate. For example, the mail protocol works like this: Your mail program opens a connection to the mail server at the other end. Your program gives it your machine's name, the sender of the message, and the recipients you want it sent to. It then sends a command saying that it is starting the message. At that point, the other end stops treating what it sees as commands, and starts accepting the message. Your end then starts sending the text of the message. At the end of the message, a special mark is sent (a dot in the first column). After that, both ends understand that your program is again sending commands. This is the simplest way to do things, and the one that most applications use. File transfer is somewhat more complex. The file transfer protocol involves two different connections. It starts out just like mail. The user's program sends commands like "log me in as this user", "here is my password", "send me the file with this name". However once the command to send data is sent, a second connection is opened for the data itself. It would certainly be possible to send the data on the same connection, as mail does. However file transfers often take a long time. The designers of the file transfer protocol wanted to allow the user to continue issuing commands while the transfer is going on. For example, the user might make an inquiry, or he might abort the transfer. Thus the designers felt it was best to use a separate connection for the data and leave the original command connection for commands. (It is also possible to open command connections to two different computers, and tell them to send a file from one to the other. In that case, the data couldn't go over the command connection.) Remote terminal connections use another mechanism still. For remote logins, there is just one connection. It normally sends data. When it is necessary to send a command (e.g. to set the terminal type or to change some mode), a special character is used to indicate that the next character is a command. If the user happens to type that special character as data, two of them are sent. We are not going to describe the application protocols in detail in this document. It's better to read the RFC's yourself. However there are a couple of common conventions used by applications that will be described here. First, the common network representation: TCP/IP is intended to be usable on any computer. Unfortunately, not all computers agree on how data is represented. There are differences in character codes (ASCII vs. EBCDIC), in end of line conventions (carriage return, line feed, or a representation using counts), and in whether terminals expect characters to be sent individually or a line at a time. In order to allow computers of different kinds to communicate, each applications protocol defines a standard representation. Note that TCP and IP do not care about the representation. TCP simply sends octets. However the programs at both ends have to agree on how the octets are to be interpreted. The RFC for each application specifies the standard representation for that application. Normally it is "net ASCII". This uses ASCII characters, with end of line denoted by a carriage return followed by a line feed. For remote login, there is also a definition of a "standard terminal", which turns out to be a half-duplex terminal with echoing happening on the local machine. Most applications also make provisions for the two computers to agree on other representations that they may find more convenient. For example, PDP-10's have 36-bit words. There is a way that two PDP-10's can agree to send a 36-bit binary file. Similarly, two systems that prefer full-duplex terminal conversations can agree on that. However each application has a standard representation, which every machine must support. (For more details about the protocols mentioned in this section, see rfc821.txt and rfc822.txt for mail, rfc959.txt for file transfer, and rfc854.txt and rfc855.txt for remote logins. For the well-known port numbers, see the current edition of Assigned Numbers, and possible rfc814.txt.) Protocols other than TCP: UDP and ICMP ====================================== So far, we have described only connections that use TCP. Recall that TCP is responsible for breaking up messages into packets, and reassembling them properly. However in many applications, we have messages that will always fit in a single packet. An example is name lookup. When a user attempts to make a connection to another system, he will generally specify the system by name, rather than Internet address. His system has to translate that name to an address before it can do anything. Generally, only a few systems have the database used to translate names to addresses. So the user's system will want to send a query to one of the systems that has the database. This query is going to be very short. It will certainly fit in one packet. So will the answer. Thus it seems silly to use TCP. Of course TCP does more than just break things up into packets. It also makes sure that the data arrives, resending packets where necessary. But for a question that fits in a single packet, we don't need all the complexity of TCP to do this. If we don't get an answer after a few seconds, we can just ask again. For applications like this, there are alternatives to TCP. The most common alternative is UDP ("user datagram protocol"). UDP is designed for applications where you don't need to put sequences of packets together. It fits into the system much like TCP. There is a UDP header. The network software puts the UDP header on the front of your data, just as it would put a TCP header on the front of your data. Then UDP sends the data to IP, which adds the IP header, putting UDP's protocol number in the protocol field instead of TCP's protocol number. However UDP doesn't do as much as TCP does. It doesn't split data into multiple packets. It doesn't keep track of what it has sent so it can resend if necessary. About all that UDP provides is port numbers, so that several programs can use UDP at once. UDP port numbers are used just like TCP port numbers. There are well-known port numbers for servers that use UDP. Note that the UDP header is shorter than a TCP header. It still has source and destination port numbers, and a checksum, but that's about it. No sequence number, since it is not needed. UDP is used by the protocols that handle name lookups (see ien-116.txt, rfc882.txt, and rfc883.txt), and a number of similar protocols. Another alternative protocol is ICMP ("Internet control message protocol"). ICMP is used for error messages, and other messages intended for the TCP/IP software itself, rather than any particular user program. For example, if you attempt to connect to a host, your system may get back an ICMP message saying "host unreachable". ICMP can also be used to find out some information about the network. See rfc792.txt for details of ICMP. ICMP is similar to UDP, in that it handles messages that fit in one packet. However it is even simpler than UDP. It doesn't even have port numbers in its header. Since all ICMP messages are interpreted by the network software itself, no port numbers are needed to say where a ICMP message is supposed to go. Routing ======= The description above indicated that the IP implementation is responsible for getting packets to the destination indicated by the destination address, but little was said about how this would be done. The task of finding how to get a packet to its destination is referred to as "routing". In fact many of the details depend upon the particular implementation. However some general things can be said. First, it is necessary to understand the model on which IP is based. IP assumes that a system is attached to some local network. We assume that the system can send packets to any other system on its own network. (In the case of Ethernet, it simply finds the Ethernet address of the destination system, and puts the packet out on the Ethernet.) The problem comes when a system is asked to send a packet to a system on a different network. This problem is handled by gateways. A gateway is a system that connects a network with one or more other networks. Gateways are often normal computers that happen to have more than one network interface. For example, we have a Unix machine that has two different Ethernet interfaces. Thus it is connected to networks 128.6.4 and 128.6.3. This machine can act as a gateway between those two networks. The software on that machine must be set up so that it will forward packets from one network to the other. That is, if a machine on network 128.6.4 sends a packet to the gateway, and the packet is addressed to a machine on network 128.6.3, the gateway will forward the packet to the destination. Major communications centers often have gateways that connect a number of different networks. Routing in IP is based entirely upon the network number of the destination address. Each computer has a table of network numbers. For each network number, a gateway is listed. This is the gateway to be used to get to that network. Note that the gateway doesn't have to connect directly to the network. It just has to be the best place to go to get there. For example at Rutgers, our interface to NSFnet is at the John von Neuman Supercomputer Center (JvNC). Our connection to JvNC is via a high-speed serial line connected to a gateway whose address is 128.6.3.12. Systems on net 128.6.3 will list 128.6.3.12 as the gateway for many off-campus networks. However systems on net 128.6.4 will list 128.6.4.1 as the gateway to those same off-campus networks. 128.6.4.1 is the gateway between networks 128.6.4 and 128.6.3, so it is the first step in getting to JvNC. When a computer wants to send a packet, it first checks to see if the destination address is on the system's own local network. If so, the packet can be sent directly. Otherwise, the system expects to find an entry for the network that the destination address is on. The packet is sent to the gateway listed in that entry. This table can get quite big. For example, the Internet now includes several hundred individual networks. Thus various strategies have been developed to reduce the size of the routing table. One strategy is to depend upon "default routes". Often, there is only one gateway out of a network. This gateway might connect a local Ethernet to a campus-wide backbone network. In that case, we don't need to have a separate entry for every network in the world. We simply define that gateway as a "default". When no specific route is found for a packet, the packet is sent to the default gateway. A default gateway can even be used when there are several gateways on a network. There are provisions for gateways to send a message saying "I'm not the best gateway -- use this one instead." (The message is sent via ICMP. See rfc792.txt) Most network software is designed to use these messages to add entries to their routing tables. Suppose network 128.6.4 has two gateways, 128.6.4.59 and 128.6.4.1. 128.6.4.59 leads to several other internal Rutgers networks. 128.6.4.1 leads indirectly to the NSFnet. Suppose we set 128.6.4.59 as a default gateway, and have no other routing table entries. Now what happens when we need to send a packet to MIT? MIT is network 18. Since we have no entry for network 18, the packet will be sent to the default, 128.6.4.59. As it happens, this gateway is the wrong one. So it will forward the packet to 128.6.4.1. But it will also send back an error saying in effect: "to get to network 18, use 128.6.4.1". Our software will then add an entry to the routing table. Any future packets to MIT will then go directly to 128.6.4.1. Most IP experts recommend that individual computers should not try to keep track of the entire network. Instead, they should start with default gateways, and let the gateways tell them the routes, as just described. However this doesn't say how the gateways should find out about the routes. The gateways can't depend upon this strategy. They have to have fairly complete routing tables. (It is possible to do hierarchical routing, where all of the gateways on a campus know about the campus network, but direct all off-campus traffic to a single gateway with connections off-campus.) For this, some sort of routing protocol is needed. A routing protocol is simply a technique for the gateways to find each other, and keep up to date about the best way to get to every network. rfc1009.txt contains a review of gateway design and routing. However rip.doc is probably a better introduction to the subject. It contains some tutorial material, and a detailed description of the most commonly-used routing protocol. Details about Internet addresses: subnets and broadcasting ========================================================== As indicated above, Internet addresses are 32-bit numbers, normally written as 4 octets (in decimal), e.g. 128.6.4.7. There are actually 3 different types of address. The problem is that the address has to indicate both the network and the host within the network. It was felt that eventually there would be lots of networks. Many of them would be small, but probably 24 bits would be needed to represent all the IP networks. It was also felt that some very big networks might need 24 bits to represent all of their hosts. This would seem to lead to 48 bit addresses. But the designers really wanted to use 32 bit addresses. So they adopted a kludge. The assumption is that most of the networks will be small. So they set up three different ranges of address. Addresses beginning with 1 to 126 use only the first octet for the network number. The other three octets are available for the host number. Thus 24 bits are available for hosts. These numbers are used for large networks. But there can only be 126 of these very big networks. The Arpanet is one, and there are a few large commercial networks. But few normal organizations get one of these "class A" addresses. For normal large organizations, "class B" addresses are used. Class B addresses use the first two octets for the network number. Thus network numbers are 128.1 through 191.254. (We avoid 0 and 255, for reasons that we see below. We also avoid addresses beginning with 127, because that is used by some systems for special purposes.) The last two octets are available for host addesses, giving 16 bits of host address. This allows for 64516 computers, which should be enough for most organizations. (It is possible to get more than one class B address, if you run out.) Finally, class C addresses use three octets, in the range 192.1.1 to 223.254.254. These allow only 254 hosts on each network, but there can be lots of these networks. Addresses above 223 are reserved for future use, as class D and E (which are currently not defined). Many large organizations find it convenient to divide their network number into "subnet". For example, Rutgers has been assigned a class B address, 128.6. We find it convenient to use the third octet of the address to indicate which Ethernet a host is on. This division has no significance outside of Rutgers. A computer at another institution would send any packet whose destination address began with 128.6 on the best route to Rutgers. They would not have different routes for 128.6.4 or 128.6.5. But inside Rutgers, we treat 128.6.4 and 128.6.5 as separate networks. In effect, gateways inside Rutgers have separate entries for each Rutgers subnet, whereas gateways outside Rutgers just have one entry for 128.6. Note that we could do exactly the same thing by using a separate class C address for each Ethernet. As far as Rutgers is concerned, it would be just as convenient for us to have a number of class C addresses. However using class C addresses would make things inconvenient for the rest of the world. Every institution that wanted to talk to us would have to have a separate entry for each one of our networks. If every institution did this, there would be far too many networks for any reasonable gateway to keep track of. By subdividing a class B network, we hide our internal structure from everyone else, and save them trouble. This subnet strategy requires special provisions in the network software. It is described in rfc950.txt. 0 and 255 have special meanings. 0 is reserved for machines that don't know their address. In certain circumstances it is possible for a machine not to know the number of the network it is on, or even its own host address. So 0.0.0.23 would be a machine that knew it was host number 23, but didn't know on what network. 255 is used for "broadcast". A broadcast is a message that you want every system on the network to see. Broadcasts are used in some situations where you don't know who to talk to. For example, suppose you need to look up a host name and get its Internet address. Sometimes you don't know the address of the system that has the host name data base. In that case, you might send the request as a broadcast. There are also cases where a number of systems are interested in information. It is then less expensive to send a single broadcast than to send packets individually to each host that is interested in the information. In order to send a broadcast, you use an address that is made by using your network address, with all ones in the part of the address where the host number goes. For example, if you are on network 128.6.4, you would use 128.6.4.255 for broadcasts. How this is actually implemented depends upon the medium. It is not possible to send broadcasts on the Arpanet, or on point to point lines. However it is possible on an Ethernet. If you use an Ethernet address with all its bits on (all ones), every machine on the Ethernet is supposed to look at that packet. Although the official broadcast address for network 128.6.4 is now 128.6.4.255, there are some other addresses that may be treated as broadcasts by certain implementations. For convenience, the standard also allows 255.255.255.255 to be used. This refers to all hosts on the local network. It is often simpler to use 255.255.255.255 instead of finding out the network number for the local network and forming a broadcast address such as 128.6.4.255. In addition, certain older implementations may use 0 instead of 255 to form the broadcast address, e.g. 128.6.4.0. Finally, certain older implementations may not understand about subnets. Thus they consider the network number to be 128.6. In that case, they will assume a broadcast address of 128.6.255.255 or 128.6.0.0. Until support for broadcasts is implemented properly, it can be a somewhat dangerous feature to use. Because 0 and 255 are used for unknown and broadcast addresses, normal hosts should never be given addresses containing 0 or 255. Addresses should never begin with 0, 127, or any number above 223. Addresses violating these rules are sometimes referred to as "Martians", because of rumors that the Central University of Mars is using network 225. Packet splitting and reassembly =============================== TCP/IP is designed for use with many different kinds of network. Unfortunately, network designers do not agree about how big packets can be. Ethernet packets can be 1500 octets long. Arpanet packets have a maximum of around 1000 octets. Some very fast networks have much larger packet sizes. At first, you might think that IP should simply settle on the smallest possible size. Unfortunately, this would cause serious performance problems. When transferring large files, big packets are far more efficient than small ones. So we want to be able to use the largest packet size possible. But we also want to be able to handle networks with small limits. There are two provisions for this. First, TCP has the ability to "negotiate" about packet size. When a TCP connection first opens, both ends can send the maximum packet size they can handle. The smaller of these numbers is used for the rest of the connection. This allows two implementations that can handle big packets to use them, but also lets them talk to implementations that can't handle them. However this doesn't completely solve the problem. The most serious problem is that the two ends don't necessarily know about all of the steps in between. For example, when sending data between Rutgers and Berkeley, it is likely that both computers will be on Ethernets. Thus they will both be prepared to handle 1500-octet packets. However the connection will at some point end up going over the Arpanet. It can't handle packets of that size. For this reason, there are provisions to split packets up into pieces. The IP header contains fields indicating the a packet has been split, and enough information to let the pieces be put back together. If a gateway connects an Ethernet to the Arpanet, it must be prepared to take 1500-octet Ethernet packets and split them into pieces that will fit on the Arpanet. Furthermore, every implementation of TCP/IP must be prepared to accept pieces and put them back together. This is referred to as "reassembly". TCP/IP implementations differ in the approach they take to deciding on packet size. It is fairly common for implementations to use 576-byte packets whenever they can't verify that the entire path is able to handle larger packets. The problem is that many implementations have bugs in the code to reassemble pieces. So many implementors try to avoid ever having splits occur. Different implementors take different approaches to deciding when it is safe to use large packets. Some use them only for the local network. Others will use them for any network on the same campus. 576 bytes is a "safe" size, which every implementation must support. Ethernet encapsulation: ARP =========================== There was a brief discussion above about what IP packets looked like on an Ethernet. The discussion showed the Ethernet header and checksum. However it left one hole: It didn't say how to figure out what Ethernet address to use when you want to talk to a given Internet address. In fact, there is a separate protocol for this, called ARP ("address resolution protocol"). Note by the way that ARP is not an IP protocol. That is, the ARP packets do not have IP headers. Suppose you are on system 128.6.4.194 and you want to connect to system 128.6.4.7. Your system will first verify that 128.6.4.7 is on the same network, so it can talk directly via Ethernet. Then it will look up 128.6.4.7 in its ARP table, to see if it already knows the Ethernet address. If so, it will stick on an Ethernet header, and send the packet. But suppose this system is not in the ARP table. There is no way to send the packet, because you need the Ethernet address. So it uses the ARP protocol to send an ARP request. Essentially an ARP request says "I need the Ethernet address for 128.6.4.7". Every system listens to ARP requests. When a system sees an ARP request for itself, it is required to respond. So 128.6.4.7 will see the request, and will respond with an ARP reply saying in effect "128.6.4.7 is 8:0:20:1:56:34". (Recall that Ethernet addresses are 48 bits. This is 6 octets. Ethernet addresses are conventionally shown in hex, using the punctuation shown.) Your system will save this information in its ARP table, so future packets will go directly. Most systems treat the ARP table as a cache, and clear entries in it if they have not been used in a certain period of time. Note by the way that ARP requests must be sent as "broadcasts". There is no way that an ARP request can be sent to the right system. After all, the whole reason for sending an ARP request is that you don't know the Ethernet address. So an Ethernet address of all ones is used, i.e. ff:ff:ff:ff:ff:ff. By convention, every machine on the Ethernet is required to pay attention to packets with this as an address. So every system sees every ARP requests. They all look to see whether the request is for their own address. If so, they respond. If not, they could just ignore it. (Some hosts will use ARP requests to update their knowledge about other hosts on the network, even if the request isn't for them.) Note that packets whose IP address indicates broadcast (e.g. 255.255.255.255 or 128.6.4.255) are also sent with an Ethernet address that is all ones. Getting more information ======================== This directory contains documents describing the major protocols. There are literally hundreds of documents, so we have chosen the ones that seem most important. Internet standards are called RFC's. RFC stands for Request for Comment. A proposed standard is initially issued as a proposal, and given an RFC number. When it is finally accepted, it is added to Official Internet Protocols, but it is still referred to by the RFC number. We have also included two IEN's. (IEN's are an older form of RFC.) The convention is that whenever an RFC is revised, the revised version gets a new number. This is fine for most purposes, but it causes problems with two documents: Assigned Numbers and Official Internet Protocols. These documents are being revised all the time, so the RFC number keeps changing. You will have to look in rfc-index.txt to find the number of the latest edition. Anyone who is seriously interested in TCP/IP should read the RFC describing IP (791). RFC 1009 is also useful. It is a specification for gateways to be used by NSFnet. As such, it contains an overview of a lot of the TCP/IP technology. You should probably also read the description of at least one of the application protocols, just to get a feel for the way things work. Mail is probably a good one (821/822). TCP (793) is of course a very basic specification. However the spec is fairly complex, so you should only read this when you have the time and patience to think about it carefully. Fortunately, the author of the major RFC's (Jon Postel) is a very good writer. The TCP RFC is far easier to read than you would expect, given the complexity of what it is describing. You can look at the other RFC's as you become curious about their subject matter. Here is a list of the documents you are more likely to want: rfc-index - list of all RFC's rfc1012 - somewhat fuller list of all RFC's rfc1011 - Official Protocols. It's useful to scan this to see what tasks protocols have been built for. This defines which RFC's are actual standards, as opposed to requests for comments. rfc1010 - Assigned Numbers. If you are working with TCP/IP, you will probably want a hardcopy of this as a reference. It's not very exciting to read. It lists all the offically defined well-known ports and lots of other things. rfc1009 - NSFnet gateway specifications. A good overview of IP routing and gateway technology. rfc973 - update on domains rfc959 - FTP (file transfer) rfc950 - subnets rfc894 - how IP is to be put on Ethernet, see also rfc825 rfc882/3 - domains (the database used to go from host names to Internet address and back -- also used to handle UUCP these days). See also rfc973 rfc854/5 - telnet - protocol for remote logins rfc826 - ARP - protocol for finding out Ethernet addresses rfc821/2 - mail rfc814 - names and ports - general concepts behind well-known ports rfc793 - TCP rfc792 - ICMP rfc791 - IP rfc768 - UDP rip.doc - details of the most commonly-used routing protocol ien-116 - old name server (still needed by several kinds of system) ien-48 - the Catenet model, general description of the philosophy behind TCP/IP The following documents are somewhat more specialized. rfc813 - window and acknowledgement strategies in TCP rfc815 - packet reassembly techniques rfc816 - fault isolation and resolution techniques rfc817 - modularity and efficiency in implementation rfc879 - the maximum segment size option in TCP rfc896 - congestion control rfc827,888,904,975,985 - EGP To those of you who may be reading this document remotely instead of at Rutgers: The most important RFC's have been collected into a three-volume set, the DDN Protocol Handbook. It is available from the DDN Network Information Center, SRI International, 333 Ravenswood Avenue, Menlo Park, California 94025 (telephone: 800-235-3155). You should be able to get them via anonymous FTP from sri-nic.arpa. File names are: RFC's: rfc:rfc-index.txt rfc:rfcxxx.txt IEN's: ien:ien-index.txt ien:ien-xxx.txt rip.doc is available by anonymous FTP from topaz.rutgers.edu, as /pub/tcp-ip-docs/rip.doc. Sites with access to UUCP but not FTP may be able to retreive them via UUCP from UUCP host rutgers. The file names would be RFC's: /topaz/pub/pub/tcp-ip-docs/rfc-index.txt /topaz/pub/pub/tcp-ip-docs/rfcxxx.txt IEN's: /topaz/pub/pub/tcp-ip-docs/ien-index.txt /topaz/pub/pub/tcp-ip-docs/ien-xxx.txt /topaz/pub/pub/tcp-ip-docs/rip.doc Note that SRI-NIC has the entire set of RFC's and IEN's, but rutgers and topaz have only those specifically mentioned above.  -----------[000161][next][prev][last][first]---------------------------------------------------- Date: 18 Aug 88 00:52:46 GMT From: aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu (Charles Hedrick) To: tcp-ip@sri-nic.arpa Subject: yes, Ethernet controllers really can hear their own output adam@etive.ed.ac.uk (A Hamilton) tells us that Ethernet transceivers "CANNOT listen during their own transmission." but must use software to simulate doing so. The version 2 Ethernet spec in section 7.2.1.2 requires that "In the case of a station transmitting without collision interference, the station's own transmit transitions on the coaxial cable will also appear on the receive pair, after a delay due to propagation through the transceiver." So there is no problem with the transceiver. However most controllers can't receive at the same time as they transmit. I just took at look at the description for the Intel Ethernet chips. These are among the most common chips used in controllers (and happen to be the only ones I have details on). The 82501, which does the signal processing, is full duplex, and can handle send and receive at the same time. The controller chip, 82586, can do so only when it is in loopback mode. One gets the impression that they explicitly disallow simultaneous sending and receiving because the chip can't handle the throughput of doing both at once. (I am guessing that this is the limit because they say that in loopback mode, where they do send and receive at the same time, the size of packet must be limited in order to avoid overruning the receiver portion.) The message from Bill Westfield saying that some controllers can hear their own packets is describing an actual controller made by Bill's company (cisco). It really does hear its own output. I don't think this is the first controller with this property. (At the very least, I think Stanford's MEIS had it.)  -----------[000162][next][prev][last][first]---------------------------------------------------- Date: Thu, 18 Aug 88 07:38 EST From: BEAME%SSCvax.McMaster.CA@CORNELLC.CCS.CORNELL.EDU To: TCP-IP@SRI-NIC.ARPA Subject: RE: yes, Ethernet controllers really can hear their own output  The 3C501 ethernet board for the PC can listen and receive its own output BUT ... If the packet sent is over around 512 bytes, it causes the transmitted packet to become garbled and have an incorrect CRC. -Carl  -----------[000163][next][prev][last][first]---------------------------------------------------- Date: Thu, 18 Aug 88 13:46:33 -0400 From: Craig Partridge <craig@NNSC.NSF.NET> To: tcp-ip@sri-nic.ARPA Subject: re: Van's algorithms  I got an interesting question: > How does one go about joining SIGCOMM? There are two methods: (1) If you are already an ACM member, call the membership line and ask to be added to SIGCOMM. They will add you *free* (at least they used to). You'll only start paying SIGCOMM dues when your ACM membership is renewed. (2) If you are not an ACM member, join the ACM and while you are doing that, sign up for SIGCOMM (an extra few $$). Craig  -----------[000164][next][prev][last][first]---------------------------------------------------- Date: 18 Aug 88 16:49:57 GMT From: mcvax!dkuug!freja!hartvig@uunet.uu.net (Hartvig Ekner) To: tcp-ip@sri-nic.arpa Subject: Another reason for loopback packets I have found that some ethernet chips (NIC's) simply die if they don't get to transmit a packet every now and then. This is particularly true for the early versions of the Intel 82586. Sending a loopback packet every second or so is the best solution I could come up with. Hartvig Ekner ...mcvax!diku!hartvig  -----------[000165][next][prev][last][first]---------------------------------------------------- Date: 18 Aug 88 22:57:57 GMT From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) To: comp.unix.wizards,comp.protocols.tcp-ip Subject: Re: mbuf leaks  In article <2881@ttidca.TTI.COM> mb@ttidca.tti.com (Michael Bloom) writes: : Can anyone suggest good techniques for tracking down mbuf leaks? I don't know if this is still valid, but in 4.2 I split up the DATA mbuf type into twenty-some-odd different types of mbufs, depending on where they were allocated. After tweaking netstat to show which DATA type, it was easy to see which allocator didn't have a matching deallocator. Generally that was sufficient to deduce the location of the leak. Sometimes a judicious printf or two helps as well, just so you don't go overboard. Generally you want to hide a printf behind a debugging variable you can turn on and off with adb. There may be better tools to diagnose this by now... Larry Wall lwall@jpl-devvax.jpl.nasa.gov  -----------[000166][next][prev][last][first]---------------------------------------------------- Date: 18 Aug 88 23:39:19 GMT From: amdahl!nsc!rfg@ames.arc.nasa.gov (Ron Guilmette) To: tcp-ip@sri-nic.arpa Subject: ENOTTY running System V shl(1) with WINS/TCP-IP. Has anybody ever gotten the System V shell layers program "shl" to run on any machine which uses the Wollogong TCP-IP product (aka WINS)? I called Wollogong and they said that this is not supported and never has been. But I'm stubborn and I think it should be! (We are running WINS 2.1 on System V.3.1). The shl program works fine when used from a "real" RS-232 serial port but it (internally) gets the errno ENOTTY when it tries to do the ioctl SXTIOCLINK operation if the "controlling" "terminal" is actually an rlogin'd pty. This causes "shl" to exit with the message "not using a tty device". We tracked this into the kernel and found out that the "sxt" driver was returning the ENOTTY because of the fact that there was no "struct tty" pointer in the cdevsw[] table entry for the major device number of the /dev/ttypX devices. We were able to fix that up easily because there was already an array of "struct tty" things allocated to hold "tty" style information for the pty's. So we just forced the name of that array into the proper entry in our conf.c file and relinked the kernel. Now it doesn't get ENOTTY anymore, but "shl" gets hung up inside of the sxt driver somewhere. Does anybody have a fix? -- Ron Guilmette National SemiConductor Internet: rfg@nsc.nsc.com or amdahl!nsc!rfg@ames.arc.nasa.gov Uucp: ...{pyramid,sun,amdahl,apple}!nsc!rfg  -----------[000167][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 88 03:04:57 GMT From: munnari!otc!metro!ipso!stcns3!dave@uunet.uu.net (Dave Horsfall) To: tcp-ip@sri-nic.arpa Subject: Serial TCP/IP - all the same? Just a simple question - is there a single standard for TCP/IP over an RS-232 line (SLIP?), or are there many (like Ethernet1.0/2.0/802.3 etc)? We are trying to determine what is wrong with our serial link (a CCI Power 6/32 running Sys V) and our local agents have never heard of a serial TCP/IP analyser, but are willing to write a protocol module for the famous LM-1 box. If we can provide the specs, that is. As a last resort, I'll dig out the Tektronix 834, but decoding SNA frames with that was bad enough, and I won't even _consider_ looking at X.25! Hence our interest in the LM-1, if it'll do serial TCP/IP. Many thanks for any advice... -- Dave Horsfall (VK2KFU), Alcatel-STC Australia, dave@stcns3.stc.oz dave%stcns3.stc.OZ.AU@uunet.UU.NET, ...munnari!stcns3.stc.OZ.AU!dave UUCP does it with a bang!  -----------[000168][next][prev][last][first]---------------------------------------------------- Date: Fri, 19 Aug 88 10:59:10 PDT From: braden@venera.isi.edu To: BILLW@mathom.cisco.com, dcrocker@twg.com Cc: tcp-ip@sri-nic.arpa Subject: Re: Van's algorithms in Streams  Date: Mon 15 Aug 88 18:12:25-PDT From: William Westfield <BILLW@MATHOM.CISCO.COM> Subject: Re: Van's algorithms in Streams To: dcrocker@TWG.COM Cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "Dave Crocker <dcrocker@twg.com>" of Mon 15 Aug 88 10:31:00-PDT Message-Id: <12422755198.10.BILLW@MATHOM.CISCO.COM> Status: R Grumble. All things considered, Van's congestion control enhancments are MUCH more important than the header-prediction changes. Bill Westfield cisco Systems. ------- Bill, I strongly agree. The congestion control enhancements will improve the performance of the Internet for EVERYBODY, and will significantly improve the THROUGHPUT for the enhanced TCP's over most real Internet paths. The header-prediction changes only reduce the CPU OVERHEAD for the individual system and are mostly important for a TCP operating over a high-speed one-hop path, e.g., across a LAN. Bob Braden  -----------[000169][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 88 17:25:00 PDT From: John Bartas <jb@TWG.COM> To: tcp-ip <tcp-ip@sri-nic.arpa>  A Birds of a Feather session on OS/2 has been set up for 7:30pm Thursday the 29th at INTEROP 88. The discussion will include implementing TCP/IP on OS/2, supporting network hardware, porting applications, and APIs. Please contact me with any further ideas for topics. The field is wide open. Also: ACE is still looking for more BOF sessions. If you have a topic you would like to moderate a session on, contact them at (415) 941-3399 ----------------------------------------------------- John Bartas Project Leader The Wollongong Group  -----------[000170][next][prev][last][first]---------------------------------------------------- Date: Fri, 19 Aug 88 14:06:36 WET DST From: Nick Felisiak <mcvax!tarantula.spider.co.uk!nick@uunet.UU.NET> To: tcp-ip@sri-nic.ARPA Subject: Re: mbuf leaks In article <2690@jpl-devvax.JPL.NASA.GOV> responding to <2881@ttidca.TTI.COM> lwall@jpl-devvax.jpl.nasa.gov (Larry Wall) writes: > > In article <2881@ttidca.TTI.COM> mb@ttidca.tti.com (Michael Bloom) writes: > : Can anyone suggest good techniques for tracking down mbuf leaks? > > I don't know if this is still valid, but in 4.2 I split up the DATA mbuf > type into twenty-some-odd different types of mbufs, depending on where they > were allocated. After tweaking netstat to show which DATA type, it was easy > to see which allocator didn't have a matching deallocator. Generally > that was sufficient to deduce the location of the leak. > [...] > > There may be better tools to diagnose this by now... > > Larry Wall > lwall@jpl-devvax.jpl.nasa.gov > Working with streams buffers (rather than 4.2 mbufs), on our TCP and X.25 packages, I have used the following technique sucessfully: 1. #define allocb(size, pri) Xallocb (size, pri, __LINE__, __FILE__), and ditto for all its friends (freeb, dupb, etc). 2. Add a couple of fields to the header structures, or build parallel structures maintained by the 'X*' functions, which record the line and file info thoughtfully included by cpp as the last two parameters. 3. When a lost buffer is identified, find out exactly where it came from. Doing this *without* source is somewhat tricky - you need to put a small module between the top of tcp (or whatever), and the stream head to catch blocks coming up and down from the user. However, it is possible. Nick Felisiak nick@spider.co.uk (nick%spider.co.uk@uunet.uu.net)  -----------[000171][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 88 18:46:08 GMT From: spl1!laidbak!aes@lll-winken.llnl.gov (Andy Schweig) To: tcp-ip@sri-nic.arpa Subject: Re: Van's algorithms in Streams In article <8808160634.AA03685@ucbvax.Berkeley.EDU> dcrocker@TWG.COM (Dave Crocker) writes: >Steve Alexander cites Lachman's Streams implementation as containing >Van's performance enhancements. While the congestion control enhancements >drop in relatively easily, it is my understanding that Van has not yet >released his header-prediction changes. I would be interested to know >the origins of the code that Lachman acquired. Steve? Steve did not mention anything about Van's header prediction code. Since it was not available at the time of our last release, it was not included. What we did include was all of the available congestion control algorithms from Van et al. >With respect to the ease of adding Berkeley code to Streams, the key is >the degree of conformance to streams architecture. One can be formally >conformant, but still have variations is certain features. It is certainly true that some of the Berkeley code requires modification before it can be incorporated into a STREAMS-based implementation. Some of it, in fact, is conceptually incompatible with the STREAMS approach. However, changes in areas such as congestion control rarely present any problems. Since our product is based on the 4.3BSD TCP/IP code, these changes pretty much just dropped right in. In areas of the code such as this that deal with the mechanics of the TCP protocol itself, there are virtually no STREAMS dependencies, so the fact that our code is STREAMS-based was not an issue. Andy Schweig - TCP/IP Development Lachman Associates, Inc. ...!laidbak!aes  -----------[000172][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 88 21:12:48 GMT From: nic.MR.NET!como!pwcs!ems!quest!cnt!rod@csd1.milw.wisc.edu (rod merry) To: tcp-ip@sri-nic.arpa Subject: BLAST? Can someone pass along some information on what I think is a bulk file transfer protocol called BLAST on top of TCP/IP. One of my company's salespeople has been talking about it, he says its from NCAR. thanks rod -- Rod Merry rod@cnt.MN.ORG Computer Network Technology {quest|bungia}!cnt!rod 9440 Science Center Drive Minneapolis, MN 55428 (612)535-8111  -----------[000173][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 88 21:15:57 GMT From: indra@amdcad.AMD.COM (Indra K. Singhal) To: comp.sys.ibm.pc,comp.protocols.tcp-ip Subject: tn3270 for the IBM PC ??  Does anyone know if tn3270 has been ported to the IBM PC ? If so, I would greatly appreciate hearing about it. Thanks. -- Indra K. Singhal | | {ucbvax,decwrl,allegra}!amdcad!indra | This space for rent ! | indra@amdcad.AMD.COM | | (408) 749-5445(w) | |  -----------[000174][next][prev][last][first]---------------------------------------------------- Date: Sat 20 Aug 88 03:25:05-EDT From: John Romkey <ROMKEY@XX.LCS.MIT.EDU> To: tcp-ip@sri-nic.arpa, pcip@udel.edu Subject: Packet Driver BOF at Interop '88 I'm going to be running a Birds of a Feather session at the next TCP/IP Interoperability Conference, in September. This BOF will take place on Wednesday the week of the conference, at 5PM. It won't run past 6PM because the conference reception will be then, though if there's enough interest (or need) we can continue it later on or at another time if we can find a place for it. The BOF will be about "standardizing" on a programming interface through which MS-DOS applications (yes, presumably running on IBM PC-like things) can access a network interface and send raw packets. This interface should allow multiple protocol stacks to run simultaneously in the machine, and should insulate the application as much as possible from the network media particular network interface being used. While I was at FTP Software, I designed and implemented something called the "Packet Driver" interface, which has been becoming rather popular on the PC/IP mailing list recently. The packet driver has some problems, both with ambiguities in the specification and with some important pieces of lacking functionality. I want to redesign the interface to allow it to be more efficient, more general and more powerful, and I want to make sure that it will meet the needs of protocol implementors and network itnerface manufacturers. If this is done properly, vendors of non-smart board TCP/IP implementations will not have to keep writing new drivers every time a new ethernet card comes out; they'll be able to point to this specification and have hardware vendors implement a driver which conforms to it. The hardware vendors have the advantage that as soon as they've written this driver, their hardware will be supported by whatever conforming software already uses it, with little effort on their part (no beating up on software companies to support them). I want to encourage vendors of TCP/IP and proprietary LAN protocols for the IBM PC to come to the BOF, and for IBM PC network interface vendors to attend. I hope to generate an RFC from this spec, and get several pieces of public domain software written that we can give out to people who want to support it, in order to make their task easier. - john romkey epilogue technology corp. -------  -----------[000175][next][prev][last][first]---------------------------------------------------- Date: 20 Aug 88 19:13:43 GMT From: hollandm@prlhp1.prl.philips.co.uk (Martin Holland) To: comp.protocols.tcp-ip Subject: Multiple TCP/IP servers on one Host.  I have an 8 port Micom TCP/IP terminal server with all ports set to slave mode connected to a non-TCP/IP host. This setup allows TCP/IP hosts access to a non TCP/IP host over Ethernet. I now need to add more ports, and intend buying another 8 port server to add to the first. Now the problem. The first server is accessed by name and all the ports are treated as a "hunting group". How can I add a second server without giving it a different name and internet number so the user will not have to try each server in turn to find a vacant port? Is there any way, transparent to the user, that he can "TELNET server1" and if the first server is all in use automatically "TELNET server2"? Martin Holland.  -----------[000176][next][prev][last][first]---------------------------------------------------- Date: 21 Aug 88 01:17:16 GMT From: fletcher@cs.utexas.edu (Fletcher Mattox) To: comp.bugs.4bsd,comp.unix.wizards,comp.protocols.tcp-ip Subject: Interlan drops a byte?  Has anybody else seen a 4.3BSD VAX with an Interlan Ethernet interface drop a byte of data? Well, that's what we're seeing. For example, if you % rsh remotehost cat 183_byte_file and the remotehost is a 4.3/Interlan host, the rsh will fail. If you look at a packet on the wire, say, with etherfind or tcpdump, the IP header claims there are 223 bytes (183+40 TCP/IP headers), which is correct. Yet there are really only 222 bytes of data in the packet. Hmm. Futhermore other file sizes fail. It appears that if (n%256 == 183) where n is the number of bytes in the above rsh, then TCP/IP fails because a byte is dropped from the data. If we replace the Interlan with a DEUNA, all is as it should be. Any ideas? -- Fletcher Mattox fletcher@cs.utexas.edu cs.utexas.edu!fletcher  -----------[000177][next][prev][last][first]---------------------------------------------------- Date: Sun, 21 Aug 88 11:23:20 EDT From: dms@wheaties.ai.mit.edu (David M Siegel) To: tcp-ip@sri-nic.arpa Subject: SGMP Our Proteon Gateways support SGMP (simple gateway monitoring protocol). Does anyone have pointers to Unix software that can frob the gateway using this protocol? Proteon claims there is some software floating around, but couldn't point me to it. Thanks, -Dave  -----------[000178][next][prev][last][first]---------------------------------------------------- Date: Sun, 21 Aug 88 22:24:42 EDT From: "Robert J. Reschly Jr." <reschly@BRL.MIL> To: Fletcher Mattox <cs.utexas.edu!fletcher@husc6.harvard.edu> Cc: tcp-ip@sri-nic.arpa Subject: Re: Interlan drops a byte?  Fletcher, I just tried two tests against vgr.brl.mil, a vax running 4.3 (plus some tahoe code, I believe), and did not see the problem you mention. Vgr is a Perdue implementation dual 780 and is running an Interlan NI1010 Ethernet card. I ran the tests from a Gould 6081 connected to the same Ethernet. The first test was against a file containing 90 'a's, a newline, 91 'b's, and another newline, and the second was against a file containing 183 'a's. I piped the output of the "rsh" to 'wc', and got 183 bytes both times. Two questions, a) which Interlan interface are you using, and b) do you have any other Interlan boards you can test against? Our experience has been that, though the board is not the fastest, it has been reliable. Later, Bob -------- Phone: (301)278-6678 AV: 298-6678 FTS: 939-6678 Arpa: reschly@BRL.MIL (or BRL.ARPA) UUCP: ...!brl-smoke!reschly Postal: Robert J. Reschly Jr. Advanced Computer Systems Team Systems Engineering and Concepts Analysis Division U.S. Army Ballistic Research Laboratory ATTN: SLCBR-SE (Reschly) APG, MD 21005-5066 (Hey, *I* don't make 'em up!) **** For a good time, call: (303) 499-7111. Seriously! ****  -----------[000179][next][prev][last][first]---------------------------------------------------- Date: 21 Aug 88 20:12:43 GMT From: aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu (Charles Hedrick) To: tcp-ip@sri-nic.arpa Subject: Re: SGMP The usual recommendation for SGMP is to talk to the folks at Nysernet. An initial implementation was done at RPI. It's more or less public (not public domain, but freely distributable). Nysernet cleaned it up a good deal, and is selling it for a minimal cost (not enough to make money -- just enough to cause everybody maximal administrative overhead). They have also produced an SNMP version. cisco and Rutgers have been playing with the original RPI code. As long as you don't want anything sophiscated (e.g. I haven't gotten the X window-based stuff to work), it's fine. I'm not sure how happy cisco would be about doing free software distribution to Proteon's customers, but you could take our copy. (However you should probably consider Nyser's first. It's likely to be better in the long run.) There is also a project at Berkeley that's rewriting SGMP. So far they seem to have a subroutine library but almost no applications. (By the way, I don't know who to contact at these Nysernet or Berkeley, so please don't ask. At cisco, you might contact customer-service@mathom.cisco.com.)  -----------[000180][next][prev][last][first]---------------------------------------------------- Date: 21 Aug 88 20:38:43 GMT From: mailrus!emv@ames.arc.nasa.gov (Edward Vielmetti) To: tcp-ip@sri-nic.arpa Subject: Re: SGMP Merit is using an sgmp monitor to watch the NSFnet machines. I believe I saw an "IBM Internal Use Only" banner on it, but to be quite honest I have no idea what its availability is. It runs under X and is quite colorful. I suspect that nsfnet-info@merit.edu would be able to give you more information if they are willing. The file nis.nsf.net: [NSFNET] MONITOR.MTG-6-88 has some interesting information on sgmp and snmp strategies for the NSFnet backbone. (nis.nsf.net is 35.1.1.48). --Ed Edward Vielmetti, U of Michigan mail group  -----------[000181][next][prev][last][first]---------------------------------------------------- Date: Mon, 22 Aug 88 10:19:09 PDT From: satz@clash.cisco.com To: aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu (Charles Hedrick) Cc: tcp-ip@sri-nic.arpa Subject: Re: SGMP The RPI SGMP tools are available for anonymous ftp from clash.cisco.com (192.31.7.24). The file you want is sgmp.tar.Z. It is a compressed tar file containing the most recent working sources with bug fixes made at cisco and Rutgers. Please note that this software is being provided as is without any assertion as to its quality, usefulness or correctness. This code will make core files for you if you push it too hard. However it is quite useful as an introduction to ASN.1 and SGMP if you are persistant enough. Any bug reports sent to me will be politely ignored. However, if you fix a bug, please send it back for inclusion in the distribution. Greg Satz cisco Systems PS. requests for sending this through the mail cannot be honoured so please do not ask.  -----------[000182][next][prev][last][first]---------------------------------------------------- Date: 22 Aug 88 12:49:00 PDT From: Dave Crocker <dcrocker@TWG.COM> To: tcp-ip <tcp-ip@sri-nic.arpa> Subject: Re: Van's algorithms in Streams Another religious issue... Network friendliness vs. throughput? Clearly, any host participating in an internet needs to be a good neighbor. Van, et cie's, combined efforts seem to provide enough mechanism to settle the questions of "how?" The question of whether it is more or less important that performance is, mostly, deciding on the number of checksums that can fit on the head of a PIN. Nonetheless, I am curious to see the dominant point of view assuming that internet friendliness must be the answer. It presupposes a certain kind of market. If 90% of the marketplace is on small lans, then performance is likely to be foremost in the customers' minds. They do little or no internetting and therefore do not care about congestion control. No, the current number probably is not 90%, but there is a threshold, somewhere, that says performance needs to dominate. Dave  -----------[000183][next][prev][last][first]---------------------------------------------------- Date: Mon, 22 Aug 88 13:36:43 -0400 From: Atul Khanna BBNCC 20/670 873-2531 <akhanna@ALEXANDER.BBN.COM> To: Craig Partridge <craig@NNSC.NSF.NET> Cc: tcp-ip@SRI-NIC.ARPA, akhanna@ALEXANDER.BBN.COM Subject: Re: Van's algorithms >> (2) If you are not an ACM member, join the ACM and while you are >> doing that, sign up for SIGCOMM (an extra few$$). You can also join SIGCOMM without becoming an ACM member (annual dues =$37).

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 88 15:27:53 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 for the IBM PC??

Greg Minshall's spring 1987 Unix tn3270 distribution included a TN3270 for
the PC, but it was built around U-B's socket library (for their NIU card),
and used a curses package that Berkeley had done (which may not have been
generally available).  This may have changed in newer releases.

FTP Software's PC/TCP has included a TN3270 since July 1987 (based on Greg's
3270 emulator).  It emulates a 3278-2, and does screen redisplays quite
rapidly (1/4 sec or less).  The version that will ship with v2.03 of PC/TCP
has a re-mappable keyboard, simple 4-color support, and will emulate a 3278-4
on an EGA or VGA.

IBM's TCP/IP for DOS also includes a TN3270, but I haven't seen it or
its manual.  It was done at UMD under contract (based on Greg's code, I
think).

James VanBokkelen
FTP Software Inc.
(617) 868-4878


-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 88 16:29:08 GMT
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: Broadcast IP on Apple LocalTalk

From article <612@kinetics.UUCP>, by minshall@kinetics.UUCP (Greg Minshall):
> From article <63660@sun.uucp>, by pugs%whitsun@Sun.COM (Tom Lyon):
> There are a few points here.  First off, there is no relation between
> AppleTalk zones and IP subnetworks specified "anywhere".  The fact is
> that quite often there is such a relation, but no one can count on it.

I disagree. The MacIP implementations I know of do a lookup for the gateway
with the zone name "*".  This implies that the "domain" (if you will)
for the MacIP forwarding is the current zone.  The MacIP forwarding is
generally specified as an IP subnet or a subrange thereof. So, a relationship
excists between AppleTalk zones and IP subnet forwarding by the gateway.

I've taken this to further imply that an IP broadcast should be sent by
a gateway to all nets in the current zone, just and an NBP Bridge request
would be.

Certainly I haven't seen any of this on paper.  One could argue that it's
not part of any formal spec, but that the implementations seem to enforce the
relationship described above.

ps: I have a terrible cold and all of this might be jibberish; but at least
it's an interesting thought ;-)

--
"What will you do when you wake up one morning to find that God's made you
blind in a beautiful person's world and all those great recepies have let you
down, and you're twenty and a half and you're not getting age where you go look
for the boys 'says I love you lets get married and have kids." -Billy Bragg.


-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 88 17:19:09 GMT
From:      satz@CLASH.CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   Re: SGMP

The RPI SGMP tools are available for anonymous ftp from clash.cisco.com
(192.31.7.24). The file you want is sgmp.tar.Z. It is a compressed tar file
containing the most recent working sources with bug fixes made at cisco and
Rutgers. Please note that this software is being provided as is without any
assertion as to its quality, usefulness or correctness. This code will make
core files for you if you push it too hard. However it is quite useful as
an introduction to ASN.1 and SGMP if you are persistant enough. Any bug
reports sent to me will be politely ignored. However, if you fix a bug,
please send it back for inclusion in the distribution.

Greg Satz
cisco Systems

PS. requests for sending this through the mail cannot be honoured so please


-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 88 17:36:43 GMT
From:      akhanna@ALEXANDER.BBN.COM (Atul Khanna BBNCC 20/670 873-2531)
To:        comp.protocols.tcp-ip
Subject:   Re: Van's algorithms

>>     (2) If you are not an ACM member, join the ACM and while you are
>>     doing that, sign up for SIGCOMM (an extra few $$). You can also join SIGCOMM without becoming an ACM member (annual dues = 37).  -----------[000188][next][prev][last][first]---------------------------------------------------- Date: 22 Aug 88 19:49:00 GMT From: dcrocker@TWG.COM (Dave Crocker) To: comp.protocols.tcp-ip Subject: Re: Van's algorithms in Streams  Another religious issue... Network friendliness vs. throughput? Clearly, any host participating in an internet needs to be a good neighbor. Van, et cie's, combined efforts seem to provide enough mechanism to settle the questions of "how?" The question of whether it is more or less important that performance is, mostly, deciding on the number of checksums that can fit on the head of a PIN. Nonetheless, I am curious to see the dominant point of view assuming that internet friendliness must be the answer. It presupposes a certain kind of market. If 90% of the marketplace is on small lans, then performance is likely to be foremost in the customers' minds. They do little or no internetting and therefore do not care about congestion control. No, the current number probably is not 90%, but there is a threshold, somewhere, that says performance needs to dominate. Dave  -----------[000189][next][prev][last][first]---------------------------------------------------- Date: 22 Aug 88 20:29:06 GMT From: BILLW@MATHOM.CISCO.COM (William Westfield) To: comp.protocols.tcp-ip Subject: Re: Serial TCP/IP - all the same?  There are many different serial encapsulations used by TCP/IP over serial lines. To start with, it depends on whether the line is synchronous or asynchronous. The protocol used on async lines (SLIP) is pretty standard, and has its own RFC (RFC1055). On synchronous lines, things are more complicated - for example, our (cisco Systems) products support about 5 different encapsulations. Two of these are X.25 and DDN X.25, which are pretty much standardized. An ordinary X.25 protocol analyzer is useful for debugging these. We also support LAPB (level 2 of X.25) with and without a "packet type" field, and a sort of bare HDLC protocol (which is not any sort of standard, but can be documented). Other vendors are rumored to use DEC's DDCMP protocols, and/or various non-standard protocols, some of which are considered proprietary. There is currently an Internet Engineering Task Force who is investigating the specification of a standard for Point-to-Point serial links, but this is likely to take a while, and it is still likely that a vendor would like to talk their own protocol to their own boxes. I don't know of any serial analyzers that support ANY of the TCP/IP formats used on serial lines - even the standard ones... Bill Westfield cisco Systems. -------  -----------[000190][next][prev][last][first]---------------------------------------------------- Date: 22 Aug 88 22:32:53 GMT From: rlgvax!dennis@uunet.uu.net (Dennis.Bednar) To: tcp-ip@sri-nic.arpa Subject: Re: Serial TCP/IP - all the same? In article <759@stcns3.stc.oz>, dave@stcns3.stc.oz (Dave Horsfall) writes: > Just a simple question - is there a single standard for TCP/IP over an > RS-232 line (SLIP?), or are there many (like Ethernet1.0/2.0/802.3 etc)? > > We are trying to determine what is wrong with our serial link (a CCI > Power 6/32 running Sys V) and our local agents have never heard of a > serial TCP/IP analyser, but are willing to write a protocol module for > the famous LM-1 box. If we can provide the specs, that is. Yes, there is a single standard for SLIP. It basically is a protocol that describes the format and manner when sending IP packets over a serial (RS-232 asynchronous) line. SLIP is not that complicated. Basically SLIP describes the characters used to surround an IP packet, and describes how such characters may be sent as data within the IP packet by using data escaping conventions. There are several sources of information: The recent RFC written by John Romkey (I believe) that describes SLIP, A mail message that I once posted that describes SLIP (below). You can also use a line monitor (aka datascope) to look at the packets on the RS-232 asynch line. From my own experience, when things don't work, it is usually a network configuration or routing problem. Make sure that your gateways file is correct. Netstat or nstat may be helpful. Also check that your hosts file is correct. Usually one of the gateways doesn't know how to properly forward an IP packet, and the packet sometimes loops until the TTL (time to live) field in the IP header hits zero, and the packet disintegrates. Finally, it would be rather easy to write a SLIP RS-232 line analyzer. Simply dedicate two RS-232 ports for "passing thru" information, while capturing it. That is, read from port 1, and write the same to port 2, and vice-versa. Place the two ports between the sending and receiving machines, and you then passively intercept the traffic between the two active machines. Then you can use your computer to analyze the packets at a leisurely basis. I once wrote such a tool. Below is the text of an old message that describes the SLIP packet format, and justifies the rules for the escape conventions used: How IP Packets are Sent over an Asynchronous Line +------------+--------------------------------------------+-------------+ | LNI header | LNI (Local Network Interface) data | LNI Trailer | +------------+-----------+------------+-------------------+-------------+ | IP header | TCP header | optional TCP data | +-----------+------------+-------------------+ |<------------ Data Encoding Rules --------->| Special Octets Used For Data Encoding Name Hex Octal Decimal Description FRMEND 0xc0 0300 192 Frame End Character FRMESC 0xdb 0333 219 Frame Escape Character M_FRMEND 0xdc 0334 220 Meta Frame End Character M_FRMESC 0xdd 0335 221 Meta Frame Escape Character There is no LNI header for an asynchronous serial line. That is, there is no special character to introduce a sent frame. In the LNI data field, the sender applies the following rules: A data FRMEND octet is sent as FRMESC, M_FRMEND sequence. A data FRMESC octet is sent as FRMESC, M_FRMESC sequence. All other octets are sent without any translation. The receiving IP decodes by stripping and translating the extra octets. The LNI trailer contains only the FRMEND octet. That is, a frame is sent ending with the FRMEND character. Example: Want to send ('a', FRMESC, 'b', FRMEND, 'c'). Sent as ('a', FRMESC, M_FRMESC, 'b', FRMESC, M_FRMEND, 'c', FRMEND). Note the last sent octet is not part of the LNI data field. Data Octet To Send Data Sequence Actually Sent Hex Octal Decimal Hex Octal Decimal 0xdb 0333 219 (0xdb, 0xdd) (0333, 0335) (219, 221) 0xc0 0300 192 (0xdb, 0xdc) (0333, 0334) (219, 220) Justification of the Rules: 1. Sending the FRMEND data octet as a FRMESC, M_FRMEND sequence: We must be able to send the FRMEND as a data character, so the FRMEND has to be escaped, otherwise the receiver would misinterpret it as a premature end of packet. 2. Sending the FRMESC data octet as a FRMESC, M_FRMESC sequence: Because the FRMESC is used as an escape, there has to be a way of treating a FRMESC as data. For example, if this rule weren't defined, then there would be an ambiguous packet. Suppose the sender wanted to send the (data_char, FRMESC, M_FRMEND, data_char) sequence. According to rule 1 only, there would be no translation of octets. Therefore the receiver would receive it as (data_char, FRMEND_data_char, data_char), which is not what is intended. -- FullName: Dennis Bednar UUCP: {uunet|sundc}!rlgvax!dennis USMail: CCI; 11490 Commerce Park Dr.; Reston VA 22091 Telephone: +1 703 648 3300  -----------[000191][next][prev][last][first]---------------------------------------------------- Date: 22 Aug 88 22:42:08 GMT From: rlgvax!dennis@uunet.uu.net (Dennis.Bednar) To: tcp-ip@sri-nic.arpa Subject: Re: Interlan drops a byte? In article <3210@cs.utexas.edu>, fletcher@cs.utexas.edu (Fletcher Mattox) writes: > > If you look at a packet on the wire, say, with etherfind or tcpdump, > ... Say, these "ethernet sniffer" tools sound like very useful tools. Do these tools run on the UNIX machine, or on a PC? Is source available? Tell me more about them. Thanks. -- FullName: Dennis Bednar UUCP: {uunet|sundc}!rlgvax!dennis USMail: CCI; 11490 Commerce Park Dr.; Reston VA 22091 Telephone: +1 703 648 3300  -----------[000192][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 88 02:29:10 GMT From: davidc@TERMINUS.UMD.EDU (David R. Conrad) To: comp.protocols.tcp-ip Subject: Re: tn3270 for the IBM PC??  >IBM's TCP/IP for DOS also includes a TN3270, but I haven't seen it or >its manual. It was done at UMD under contract (based on Greg's code, I >think). Nope. IBM's tn3270 is based originally on work done by Jacob Rehkter at IBM's TJ Watson Research Center, modified by Drew Perkins of CMU, then modified by us. -drc ------------------------------------------------------------------------------- David R. Conrad The University of Maryland arpa: davidc@umd5.umd.edu (301) 454-2946 PC/IP Group bitnet: conradd@umdd.bitnet  -----------[000193][next][prev][last][first]---------------------------------------------------- Date: Tue, 23 Aug 88 08:56:45 EDT From: Frank KAstenholz <KASTEN@MITVMA.MIT.EDU> To: <tcp-ip@sri-nic.arpa> Cc: Dave Crocker <dcrocker@TWG.COM> Subject: Re: Van's algorithms in Streams Speaking as a commercial developer who is trying to make extensive use of TCP/IP in a product that will eventually be required to move large images through a network very quickly and highly reliably I would say that the more important of the two choices (friendliness vs speed) is that one be a good neighbor. Our products perform newspaper composition - editing articles, pictures, ads, graphics, etc, designing pages, and sending full page images to a photo typesetter. All of this requires a fairly large bandwidth (worst case - a newspaper page could be over 20 Megabytes and the requirement is to ship one of these pages to the phototypesetter every minute). However, while the speed requirement is high, that can allways be alleviated by throwing more money at the system (buying more/bigger CPU's, etc, etc). What is important to us (and maybe many other commercial developers/users of TCP) is that the network be reliable. If the newspaper does not get printed then the publisher looses his/her ad revenue for the day, etc, etc and that is millions. So, a reliable network is more important than a fast one - even on a single local lan. This is only one data point but I guess that it represents a large portion of the people who wish to integrate TCP into their products. Frank Kastenholz Atex/EPPS/Eastman Kodak All opinions are mine and mine alone (etc etc etc).  -----------[000194][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 88 05:32:10 GMT From: barmar@think.COM (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: Serial TCP/IP - all the same?  In article <977@rlgvax.UUCP> dennis@rlgvax.UUCP (Dennis.Bednar) writes: > Justification of the Rules: The justifications you gave explain why there must be SOME escape convention (which should go without saying), but not why that particular one was chosen. Why is this particular escape convention better than the old "double the special characters" convention or preceding a special character by the escape character? I don't think the doubled-character convention would actually work in SLIP because of the lack of a header (if a packet begins with FRMEND_data_char there would be three FRMEND characters in a row, and it would look like the FRMEND_data_char is actually the last character of the previous packet). But it would work to precede a FRMEND_data_char or FRMESC_data_char with a FRMESC: when forming a packet, you search for a FRMEND or FRMESC; if you find a FRMESC first you remove it from the stream, read the next character into the packet buffer, and then search again. The only advantage I see of the chosen scheme is that packetization and escape processing can occur as separate steps; was this the issue that resulted in this more complex scheme? Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar  -----------[000195][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 88 07:16:49 GMT From: hulsebos@philmds.UUCP (Rob Hulsebos) To: comp.protocols.tcp-ip Subject: Re: Difference between the various STREAM implementations.  In article <163@bud.UUCP> kwang@bud.UUCP (Kwang Sung) writes: >I would like know "what is the significant difference between the following >various products in according to AT&T STREAMS Functional Specification ?". > >1. The Wollongong STREAM implementation. >2. The Convergent STREAM implementation. ( ~ Lachman's STREAM product) >3. The Mitre STREAM implementation. ( ~ Unisoft's STREAM product) >4. CMC, EXCELAN STREAM implementation. >5. Or, any other STREAM implementation, if you can think. Me too! Me too! Especially anything to do with Unisoft! ------------------------------------------------------------------------------ R.A. Hulsebos ...!mcvax!philmds!hulsebos Philips I&E Automation Modules phone: +31-40-785723 Building TQ-III-1, room 11 Eindhoven, The Netherlands # cc -O disclaimer.c ------------------------------------------------------------------------------  -----------[000196][next][prev][last][first]---------------------------------------------------- Date: Tue, 23 Aug 88 11:26:55 edt From: snorthc@nswc-g.ARPA To: nic.MR.NET!como!pwcs!ems!quest!cnt!rod@csd1.milw.wisc.edu, tcp-ip@sri-nic.arpa Subject: Re: BLAST? BLAST stands for Blocked Asynch protocol (I think) it is usually done over serial lines. It is proprietary, but the company does have implementations for a bunch of HW. BLAST gives something on the order of ZMODEM file xfer rates, 2 - 3 times Kermits. The only way I can see to run BLAST over TCP/IP would be to establish [Da Telnet session and run it over that session. No matter what the problem, it wuld seem there is a better solution. Hope this helps Stephen Northcutt (snorthc@nswc-g.arpa) Standard disclaimer applies  -----------[000197][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 88 12:05:03 GMT From: swb@DAINICHI.TN.CORNELL.EDU (Scott Brim) To: comp.protocols.tcp-ip Subject: Re: Serial TCP/IP - all the same?  >I don't know of any serial analyzers that support ANY of the TCP/IP >formats used on serial lines - even the standard ones... > >Bill Westfield For a project we almost did last year, both Tekelec and LP-COM were interested in writing a TCP/IP formatting module for us to watch T1 lines (taking into account the encapsulation schemes of several vendors), and for a reasonable price to boot. One of them was even willing to talk with us during the development process to make sure it suited our needs(!) I don't know if they went ahead without us or not. Scott  -----------[000198][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 88 12:56:45 GMT From: KASTEN@MITVMA.MIT.EDU (Frank KAstenholz) To: comp.protocols.tcp-ip Subject: Re: Van's algorithms in Streams  Speaking as a commercial developer who is trying to make extensive use of TCP/IP in a product that will eventually be required to move large images through a network very quickly and highly reliably I would say that the more important of the two choices (friendliness vs speed) is that one be a good neighbor. Our products perform newspaper composition - editing articles, pictures, ads, graphics, etc, designing pages, and sending full page images to a photo typesetter. All of this requires a fairly large bandwidth (worst case - a newspaper page could be over 20 Megabytes and the requirement is to ship one of these pages to the phototypesetter every minute). However, while the speed requirement is high, that can allways be alleviated by throwing more money at the system (buying more/bigger CPU's, etc, etc). What is important to us (and maybe many other commercial developers/users of TCP) is that the network be reliable. If the newspaper does not get printed then the publisher looses his/her ad revenue for the day, etc, etc and that is millions. So, a reliable network is more important than a fast one - even on a single local lan. This is only one data point but I guess that it represents a large portion of the people who wish to integrate TCP into their products. Frank Kastenholz Atex/EPPS/Eastman Kodak All opinions are mine and mine alone (etc etc etc).  -----------[000199][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 88 15:24:27 GMT From: pierre@imag.imag.fr (Pierre LAFORGUE) To: comp.bugs.4bsd,comp.unix.wizards,comp.protocols.tcp-ip Subject: Re: Interlan drops a byte?  In article <3210@cs.utexas.edu> fletcher@cs.utexas.edu (Fletcher Mattox) writes: >Has anybody else seen a 4.3BSD VAX with an Interlan Ethernet interface >drop a byte of data? Well, that's what we're seeing. >For example, if you > % rsh remotehost cat 183_byte_file >and the remotehost is a 4.3/Interlan host, the rsh will fail. Your report is not very accurate; I think it depends of the Interlan interface. Here, we are using the both types: NI1010A and NP100. Both work well (I tried your test, of course). May be your problem comes from your software driver. For instance, the original BSD4.3 NP100 driver was bugged. You may ask Un. of Berkeley for the updated driver. -- Pierre LAFORGUE pierre@imag.imag.fr pierre@imag.UUCP uunet.uu.net!imag!pierre  -----------[000200][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 88 15:26:55 GMT From: snorthc@NSWC-G.ARPA To: comp.protocols.tcp-ip Subject: Re: BLAST?  BLAST stands for Blocked Asynch protocol (I think) it is usually done over serial lines. It is proprietary, but the company does have implementations for a bunch of HW. BLAST gives something on the order of ZMODEM file xfer rates, 2 - 3 times Kermits. The only way I can see to run BLAST over TCP/IP would be to establish [Da Telnet session and run it over that session. No matter what the problem, it wuld seem there is a better solution. Hope this helps Stephen Northcutt (snorthc@nswc-g.arpa) Standard disclaimer applies  -----------[000201][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 88 17:35:16 GMT From: paul@UXC.CSO.UIUC.EDU (Paul Pomes) To: comp.protocols.tcp-ip Subject: Interlan drops a byte?  I've also run into the problem using a Interlan 1010A card in a 4.3 BSD VAX 11/780 with Van's TCP fixes. Transfers kept coming up one byte short in transferring the X.V11R2 split files from expo.lcs.mit.edu to uxc.cso.uiuc.edu. It was not a constant problem. Retrying the transfer would usually get the complete file. One file did require six attempts before a 512,000 copy was obtained rather than 511,999. A cmp of the two files showed the difference to be at the very end of the file. Paul Pomes Univ of Ill, CSO  -----------[000202][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 88 18:38:06 GMT From: spp@zabriskie.uucp (Steve Pope) To: comp.protocols.tcp-ip Subject: Re: Serial TCP/IP - all the same?  >The justifications you gave explain why there must be SOME escape >convention (which should go without saying), but not why that >particular one was chosen. Why is this particular escape convention >better than the old "double the special characters" convention or >preceding a special character by the escape character? > >Barry Margolin Let me attempt an answer -- the SLIP frame-escape method has the property that the only place a FRAME_END character appears in the SLIP-encoded data is between packets, i.e. FRAME_END doesn't occur within a packet even in escaped form. Thus, transmitting SLIP's use one or more FRAME_ENDs to clear an idle channel, and a receiving slip always knows to reset itself if it gets a FRAME_END. This approach might have a slight robustness advantage. Other escape conventions might not provide the transmitting SLIP with a definite way of resetting the receiver if the receiver is in an unknown state. steve pope (spp@berkeley.EDU)  -----------[000203][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 88 18:49:58 GMT From: stjohns@BEAST.DDN.MIL (Mike St. Johns) To: comp.protocols.tcp-ip Subject: wanted - Nameserver binaries for an ULTRIX 2.0  The subject says it all - I've got the named/domaind stuff from Berkeley, but since I've got a binary only system - I've got some trouble even getting the libraries built! Is there anyone out there with a source-license Ultrix 2.0 who has built the nameserver libraries and is willing to give me a copy - binary? Umm - this is for a uVax II. Thanks, Mike  -----------[000204][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 88 20:13:14 GMT From: brunner@SPAM.ISTC.SRI.COM (Thomas Eric Brunner) To: comp.protocols.tcp-ip Subject: Re: Interlan drops a byte?  Dennis Bednar wrote asking for "ethernet sniffer" info, whether they (etherfind, tcpdump) ran on Unix boxes, PCs, was source available, etc. I've just gone through using two reasonable tools, the Network General "Sniffer", and the Exelan "LANalyser", both PC based for ethernet analysis, as well as using Van's Tcpdump (daily) and SMI's Etherfind (only where tcpdump is not available) for the purpose of determining why a diskless Sun fails under some conditions to boot when running the 4.0 release of the Sun OS. So I'll share what little I know. The "Sniffer" is a menu-driven package that runs on a PC, either lap-top or the usual notion of a PC. It only uses 2 bytes of a packet for filtering, so one's ability to form a reasonably complex "from/to/size/type" boolean is limited, though I personally didn't find this limitation a problem at all - having lived with "noisier" tools. Price, 19,000, 15,000 for the single-board PC. The "LANalyser" is less menu-oriented, also runs on a PC, either flavor, and uses more bytes for filtering. Price, 15,000. The LANalyser was the choice of SRI's link-level folks whos interest is mostly in connectivity diagnosis. The Sniffer was the choice of my own staff, whos interest is both connectivity and network-level and above diagnosis. With it we found that the diskless boot problem resulted from interactions between VMS hosts running TWG/SRI ip software and the Sun's broadcast boot request. Details available upon request. Tcpdump is not available in source form, one can either ftp it from any of the usual places, or if one is not able to ftp from say, lbl or ucbarpa, via tape from someone who is. It comes as an executable binary (Sun 3.x), with awk scripts for digestion of its output, in tar format. On a lan with a lot of hosts, getting a Sun just to run tcpdump seems very reasonable to me -- I've seen a quote for a 3/50 (used) for 850... I use it to catch the initiation of "hostile" and "questionable" events here - we've several scripts to wrap it which may be in our ftp area (spam) if either I or Tim remember to keep those versions current, and to diagnosis some really bad vendor cruft (line-at-a-time smtp, with a seperate cr/lf packet!), etc. Etherfind is available from SMI as part of their operating system release. It supports fewer of the boolean constructions than tcpdump, and I really avoid using it since Van's first release of tcpdump. Another possibility is SMI's traffic routine, which is visual, a nice intro to the activities on the wire, but little beyond that. Almost no filtering is possible. Each of these use the NIT interface, particular to SMI, which has bugs. For those sourced, putting metering into the device driver(s) is an equivalent approach. Others on this last can easily improve on this little note, in particular someone from Network General and Exelan on pricing, "protocol suite" software extra pricing, and capabilities. Happy lan-ing Dennis! Eric  -----------[000205][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 88 20:18:44 GMT From: bar@dpmizar.sw.Datapoint.COM (Brian Ruptash) To: comp.protocols.tcp-ip Subject: Test Specifications  According to USAF DDN PMO people, the NBS is working on a full suite DDN (DDN X.25, TCP/IP et al, FTP, TELNET, SMTP) reference test system, under contract for DCA. Apparently this system necessitates active responders in the host under test. Does anyone know of this system, and whether its specifications, and more importantly those for the responders, are available yet? -- Brian  -----------[000206][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 88 20:56:45 GMT From: schoff@BEAR-MOUNTAIN.NYSER.NET ("Marty Schoffstall") To: comp.protocols.tcp-ip Subject: Re: SGMP  The usual recommendation for SGMP is to talk to the folks at Nysernet. An initial implementation was done at RPI. It's more or less public (not public domain, but freely distributable). Nysernet cleaned it up a good deal, and is selling it for a minimal cost (not enough to make money -- just enough to cause everybody maximal administrative overhead). Actually we rewrote it from scratch and saved the "look and feel" of the applications. Additionally we added about 10 more applications including a BSD/UNIX agent/server. We followed the CMU model for Tektronix/VMS/TCP administratively, becaue we heard it worked, time will tell though. However we have distributed a LOT of university/ non-profit licenses (source) so far, and we release a new version about every quarter so its not an orphan. These are important due to the growing network management needs in terms of more complex and useful tools. (By the way, I don't know who to contact at these Nysernet or Berkeley, so please don't ask. At cisco, you might contact customer-service@mathom.cisco.com.) snmplisc@nisc.nyser.net does work for people who are interested. Marty  -----------[000207][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 88 21:26:44 GMT From: yeongw@C.NYSER.NET To: comp.protocols.tcp-ip Subject: Re: SGMP  For information on NYSERNet's SGMP distribution, please contact Edward Nadeau, NYSERNet Inc., 165 Jordan Road, Troy, NY 12180 nadeaut@nisc.nyser.net (518) 283-8860 Our SNMP (IDEA0011-02) distribution is not available for public distribution yet. Wengyik  -----------[000208][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 88 21:49:39 GMT From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville) To: comp.protocols.tcp-ip Subject: Re: BOF on SLIP at Interop 88 -- Thurs Sept 19th.  Well, having seen a plethora of "please add me" messages to ietf-ppp-interest@ucdavis.edu following my posting on this list about how one can (passively) follow developments on the SLIP working group, and feeling immensely guilty about it, I should restate that (as per age-old tradition), requests to be added to the list should be sent to: ietf-ppp-request@ucbdavis.edu asking to be added to the "interest" list. Please do NOT send requests directly to ietf-ppp-interest, or the whole readership will get a copy of your message. Thanks for your cooperation, -Philip  -----------[000209][next][prev][last][first]---------------------------------------------------- Date: 24 Aug 88 02:54:54 GMT From: vixie@decwrl.dec.com (Paul Vixie) To: comp.protocols.tcp-ip Subject: Re: Serial TCP/IP - all the same?  # Let me attempt an answer -- the SLIP frame-escape method has the # property that the only place a FRAME_END character appears in the # SLIP-encoded data is between packets, i.e. FRAME_END doesn't occur # within a packet even in escaped form. Now let _me_ list another reason why this is a Good Thing. There are quite a few smart serial devices in the world these days. Most of the time they don't use any of their smarts -- getting UNIX line editing into the serial board is something one can be quite proud of, if one can make it work at all. If you can help do SLIP by adding some logic to your serial card, you can get a nice performance bang for a small amount of effort: tell your serial card to collect bytes until a timeout, buffer overflow, or terminating character in the input. If you use a large enough timeout and buffer, your main CPU only has to deal with SLIP when a whole packet has arrived. If you don't have a smart serial card, you can still get a little bit of benefit from this down in the lowest levels of your input driver. But if you have a protocol that makes you keep track of state between input characters, it gets harder no matter where you are trying to optimize it, and you will probably end up not optimizing it. Yours for fewer interrupts, -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013  -----------[000210][next][prev][last][first]---------------------------------------------------- Date: 24 Aug 88 04:58:40 GMT From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) To: comp.protocols.tcp-ip Subject: Re: BLAST?  I remember getting a number of brochures (sp) several years ago on BLAST. My memory may be faulty; however, as I recall they were offering an ISO 1745 based protocol package using options A, B, and C. Option C being the transparent mode with a CRC for longitudinal integrity using either CRC-16 or CRC-CCITT (ISO 2145?). Basically, a souped up IBM Bisynchronous Serial Communications (BSC) protocol with a generic nameplate. It would be a good replacement for SLIP over a long haul, multi-drop, and/or store and foreward link--uses standard well-formed packets which can be supported by chips such as the 68521 rather than a roll your own home-brew protocol. Merton Campbell Crockett EATON Information Management Systems System Software Manager 31717 La Tienda Drive, Box 5009 AN/GYQ-21(V) Program Westlake Village, CA 91359 Internet: mcc@etn-wlv.EATON.COM Easynet: DECWRL::mcc@etn-wlv.EATON.COM  -----------[000211][next][prev][last][first]---------------------------------------------------- Date: 24 Aug 88 11:23:31 GMT From: steve@umiacs.UMD.EDU (Steven D. Miller) To: comp.protocols.tcp-ip Subject: Re: Interlan drops a byte?  The problem here is not in your Interlan card; I've had the same problem with my Sun-3/60. I did a packet spy once, and it seems that under certain circumstances, expo seems to send the FIN with a sequence number that is one too low. The spy I made of the problem is enclosed below, so that others more knowledgeable in the ways of TCP may check my reasoning. I think expo is running vanilla SunOS 3.4 TCP, but I'm by no means certain of that... -Steve Spoken: Steve Miller Domain: steve@mimsy.umd.edu UUCP: uunet!mimsy!steve Phone: +1-301-454-1808 USPS: UMIACS, Univ. of Maryland, College Park, MD 20742 pktnum 2483, timestamp 577459160 sec 410000 usec, len 54 Ethernet level: dst host 08:00:20:00:6f:74, src host 02:07:01:00:8a:17, type 800 IP header: version 4, header len 5, service 0, len 228, id 95c5, off 0, ttl 18, protocol 6, sum e, src 121e00d4, dst 80087803 TCP header: source port 14, dst port 477, <seq,ack> 1d52972,108d4e01 data off 5, flags=10<ACK> window 1000, sum 45a2, urgent 0 TCP data length 512 (0x200) bytes pktnum 2484, timestamp 577459160 sec 410000 usec, len 54 Ethernet level: dst host 02:07:01:00:8a:17, src host 08:00:20:00:6f:74, type 800 IP header: version 4, header len 5, service 0, len 28, id b6f9, off 0, ttl 1e, protocol 6, sum dad9, src 80087803, dst 121e00d4 TCP header: source port 477, dst port 14, <seq,ack> 108d4e01,1d52f72 data off 5, flags=10<ACK> window 2000, sum f076, urgent 0 TCP data length 0 (0x0) bytes pktnum 2485, timestamp 577459160 sec 530000 usec, len 54 Ethernet level: dst host 08:00:20:00:6f:74, src host 02:07:01:00:8a:17, type 800 IP header: version 4, header len 5, service 0, len 228, id 95c6, off 0, ttl 18, protocol 6, sum d, src 121e00d4, dst 80087803 TCP header: source port 14, dst port 477, <seq,ack> 1d52b72,108d4e01 data off 5, flags=10<ACK> window 1000, sum 81b0, urgent 0 TCP data length 512 (0x200) bytes pktnum 2486, timestamp 577459160 sec 530000 usec, len 54 Ethernet level: dst host 02:07:01:00:8a:17, src host 08:00:20:00:6f:74, type 800 IP header: version 4, header len 5, service 0, len 28, id b6fa, off 0, ttl 1e, protocol 6, sum dad8, src 80087803, dst 121e00d4 TCP header: source port 477, dst port 14, <seq,ack> 108d4e01,1d52f72 data off 5, flags=10<ACK> window 2000, sum f076, urgent 0 TCP data length 0 (0x0) bytes pktnum 2487, timestamp 577459160 sec 810000 usec, len 54 Ethernet level: dst host 08:00:20:00:6f:74, src host 02:07:01:00:8a:17, type 800 IP header: version 4, header len 5, service 0, len 228, id 95c7, off 0, ttl 18, protocol 6, sum c, src 121e00d4, dst 80087803 TCP header: source port 14, dst port 477, <seq,ack> 1d52d72,108d4e01 data off 5, flags=10<ACK> window 1000, sum 96d3, urgent 0 TCP data length 512 (0x200) bytes [expo sent 512 bytes after seq 1d52d72 ] pktnum 2488, timestamp 577459160 sec 810000 usec, len 54 Ethernet level: dst host 02:07:01:00:8a:17, src host 08:00:20:00:6f:74, type 800 IP header: version 4, header len 5, service 0, len 28, id b6fb, off 0, ttl 1e, protocol 6, sum dad7, src 80087803, dst 121e00d4 TCP header: source port 477, dst port 14, <seq,ack> 108d4e01,1d52f72 data off 5, flags=10<ACK> window 2000, sum f076, urgent 0 TCP data length 0 (0x0) bytes [fnord acks that] pktnum 2489, timestamp 577459160 sec 930000 usec, len 54 Ethernet level: dst host 08:00:20:00:6f:74, src host 02:07:01:00:8a:17, type 800 IP header: version 4, header len 5, service 0, len 1b8, id 95c8, off 0, ttl 18, protocol 6, sum 7b, src 121e00d4, dst 80087803 TCP header: source port 14, dst port 477, <seq,ack> 1d52f71,108d4e01 data off 5, flags=19<FIN,PUSH,ACK> window 1000, sum 2a8, urgent 0 TCP data length 400 (0x190) bytes [expo, whose sequence number was 1d52f72, now sends a FIN with the sequence number one too low.] pktnum 2490, timestamp 577459160 sec 930000 usec, len 54 Ethernet level: dst host 02:07:01:00:8a:17, src host 08:00:20:00:6f:74, type 800 IP header: version 4, header len 5, service 0, len 28, id b6fc, off 0, ttl 1e, protocol 6, sum dad6, src 80087803, dst 121e00d4 TCP header: source port 477, dst port 14, <seq,ack> 108d4e01,1d53102 data off 5, flags=10<ACK> window 1e71, sum f075, urgent 0 TCP data length 0 (0x0) bytes [fnord acks that] pktnum 2491, timestamp 577459161 sec 70000 usec, len 54 Ethernet level: dst host 02:07:01:00:8a:17, src host 08:00:20:00:6f:74, type 800 IP header: version 4, header len 5, service 0, len 28, id b6fe, off 0, ttl 1e, protocol 6, sum dad4, src 80087803, dst 121e00d4 TCP header: source port 477, dst port 14, <seq,ack> 108d4e01,1d53102 data off 5, flags=11<FIN,ACK> window 2000, sum eee5, urgent 0 TCP data length 0 (0x0) bytes [fnord sends its fin, with seq # 108d4e02] pktnum 2492, timestamp 577459161 sec 230000 usec, len 54 Ethernet level: dst host 08:00:20:00:6f:74, src host 02:07:01:00:8a:17, type 800 IP header: version 4, header len 5, service 0, len 28, id 95cb, off 0, ttl 18, protocol 6, sum 208, src 121e00d4, dst 80087803 TCP header: source port 14, dst port 477, <seq,ack> 1d53102,108d4e01 data off 5, flags=11<FIN,ACK> window 1000, sum fee5, urgent 0 TCP data length 0 (0x0) bytes pktnum 2493, timestamp 577459161 sec 250000 usec, len 54 Ethernet level: dst host 02:07:01:00:8a:17, src host 08:00:20:00:6f:74, type 800 IP header: version 4, header len 5, service 0, len 28, id b6ff, off 0, ttl 1e, protocol 6, sum dad3, src 80087803, dst 121e00d4 TCP header: source port 477, dst port 14, <seq,ack> 108d4e01,1d53103 data off 5, flags=11<FIN,ACK> window 2000, sum eee4, urgent 0 TCP data length 0 (0x0) bytes pktnum 2494, timestamp 577459161 sec 270000 usec, len 54 Ethernet level: dst host 08:00:20:00:6f:74, src host 02:07:01:00:8a:17, type 800 IP header: version 4, header len 5, service 0, len 28, id 95cc, off 0, ttl 18, protocol 6, sum 207, src 121e00d4, dst 80087803 TCP header: source port 14, dst port 477, <seq,ack> 1d53102,108d4e02 data off 5, flags=11<FIN,ACK> window 1000, sum fee4, urgent 0 TCP data length 0 (0x0) bytes pktnum 2495, timestamp 577459161 sec 410000 usec, len 54 Ethernet level: dst host 08:00:20:00:6f:74, src host 02:07:01:00:8a:17, type 800 IP header: version 4, header len 5, service 0, len 28, id 95cd, off 0, ttl 18, protocol 6, sum 206, src 121e00d4, dst 80087803 TCP header: source port 14, dst port 477, <seq,ack> 1d53103,108d4e02 data off 5, flags=10<ACK> window 1000, sum fee4, urgent 0 TCP data length 0 (0x0) bytes pktnum 2496, timestamp 577459161 sec 410000 usec, len 54 Ethernet level: dst host 02:07:01:00:8a:17, src host 08:00:20:00:6f:74, type 800 IP header: version 4, header len 5, service 0, len 28, id b700, off 0, ttl 1e, protocol 6, sum dad2, src 80087803, dst 121e00d4 TCP header: source port 477, dst port 14, <seq,ack> 108d4e02,0 data off 5, flags=4<RST> window 0, sum 41c9, urgent 0 TCP data length 0 (0x0) bytes  -----------[000212][next][prev][last][first]---------------------------------------------------- Date: 24 Aug 88 14:01:27 GMT From: rminnich@super.ORG (Ronald G Minnich) To: comp.protocols.tcp-ip Subject: Re: Serial TCP/IP - all the same?  In article <80@volition.dec.com> vixie@decwrl.dec.com (Paul Vixie) writes: >Now let _me_ list another reason why this is a Good Thing. There are quite >a few smart serial devices in the world these days. Most of the time they >don't use any of their smarts -- getting UNIX line editing into the serial Second the motion. Actually there have been quite a few systems over the years that support 'break sets' or 'tell me when you get this character or an overflow'. A few that come to mind: HP3000-supported 'tell me when you get a buffer terminated by x'- with timeout DG Eclipse with their smart ALM- supported programmable break sets. Commodore Amiga- supports 'tell me when you get a buffer terminated by x' Louie Mammakos' port of the Karn code uses the amiga's ability to suck up a bunch of characters 'til you get FRAME_END. This is a Good Thing. Saves the amiga OS a lot of work, and opens the possibility of letting a smart chip do the job. The 'two escape chars. in a row' seems like a good idea till you have to handle all the weird exception conditions... i had never really thought about why the way SLIP does it is such a good idea till now, but it sure is a good idea. ron  -----------[000213][next][prev][last][first]---------------------------------------------------- Date: 24 Aug 88 14:45:09 GMT From: jbvb@VAX.FTP.COM (James Van Bokkelen) To: comp.protocols.tcp-ip Subject: Less expensive network monitors  If you have less than 15K to spend, and already own a sufficiently IBM- compatible PC or AT, both the Lanalyzer and the Sniffer are available in do-it-yourself versions, where you get a card and software and install it in your machine. I believe the price range is 5K - 9K. Performance is comparable to the complete versions (which is necessarily lower than the HP monitor, because the Sniffer uses an existing PC Ethernet interface (3C505 in some versions, NP600 or other cards in others) to capture packets, and Excelan uses a specialized relative of their EXOS205 card, with a conventional LAN controller chip). If you don't have 5K, but do have a PC (or AT or PS/2), and particularly if you already own an Ethernet (or ProNET-10) card, you can either buy LANWatch (from us, 1200 quantity 1), or get the MIT/CMU PC-IP distribution, and use Netwatch (which is free). Both packages put the Ethernet interface in promiscuous mode, and capture as many of the passing packets as they can. Netwatch only runs on the interfaces supported by PC-IP (NI5010, 3C500 and P1300) which are all single-buffered, so you won't do too well on loaded networks. LANWatch supports lots of cards (including Proteon's P1340/1344 for monitoring 802.5 token rings), and many of these can do pretty well, particularly in a fast AT or PS/2. However, you are never going to capture all the traffic on a heavily-loaded network. LANWatch also has lots of neat features that Netwatch doesn't have, and you get enough source to change/enhance the packet parsing and filtering routines, as well as support. James VanBokkelen FTP Software Inc. (617) 868-4878 PS: LANWatch has a help hot key instead of menus, for those in a hurry...  -----------[000214][next][prev][last][first]---------------------------------------------------- Date: 24 Aug 88 20:29:09 GMT From: rfg@nsc.nsc.com (Ron Guilmette) To: comp.protocols.tcp-ip Subject: Does TCP/IP "comform" to ISO/OSI?  I'm sitting here looking at a document that says that "The XYZ implementation of TCP/IP comforms to the ISO/OSI reference model." I'm not really a networking kinda guy so I don't know if that's a lie or not. Is it? I seem to recall having heard once that TCP/IP is NOT COMFORMANT with ISO/OSI. -- Ron Guilmette National SemiConductor Internet: rfg@nsc.nsc.com or amdahl!nsc!rfg@ames.arc.nasa.gov Uucp: ...{pyramid,sun,amdahl,apple}!nsc!rfg  -----------[000215][next][prev][last][first]---------------------------------------------------- Date: 24 Aug 88 21:28:23 GMT From: dnwcv@dcatla.UUCP (William C. VerSteeg) To: comp.protocols.tcp-ip Subject: Test suite for IP based systems  Is there an application program written to test IP based systems ? Public domain code would be best, but I would consider paying for a good test suite. I recall that somebody was trying to start a firm for this purpose, but I never heard any hard facts about a test suite. What I am looking for is something that I can put on a private ethernet cable, do some minimal configuration (i.e give it some IP addresses and the applications that I want tested), and walk away from. I would like to come back and have a printout saying "Yes the target knows about redirects", "The target responds to the following Telnet negotiations properly", "The target can FTP a file at xxxxx Bytes/Sec",etc. I need this suite for regression testing of systems that I am modifying. It is so time consuming to make sure nothing breaks as I add new features to my code. If such a system doesn't exist, would anybody like to work with me to put one together? Bill VerSteeg Digital Communications Associates  -----------[000216][next][prev][last][first]---------------------------------------------------- Date: 24 Aug 88 22:52:35 GMT From: tait@versatc.UUCP (Tait Kirkham) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: RUNNING FTP IN BATCH MODE  Does anyone out there know if it is possible to run ftp in a "batch" mode? Specifically, I wish to be able to connect to a remote system and execute FTP commands from a batch file, rather than having to log in and type the commands in at the terminal. Does anyone know if this is possible? Currently I am running on a 286 PC, DOS, and Excelan software. I would appreciate any information you may have to offer. Thanks in advance Tait Kirkham -- {pyramid,uunet}!versatc!tait Tait Kirkham Versatec, 2805 Bowers Avenue, Santa Clara, Ca. 95051 (408)988-2800x5070  -----------[000217][next][prev][last][first]---------------------------------------------------- Date: 24 Aug 88 23:58:58 GMT From: kwang@bud.UUCP (Kwang Sung) To: comp.protocols.tcp-ip Subject: Layer 7 Protocol Converters, "Type of Service" Routing  Thanks everyone on the net for answering to my questions on STREAMS. I wish you can go and see my country KOREA for 1988 summer Olympics. As a matter of fact, Korea is the safest country like Israel. So, don't worry, and please go and see. I have another questions to someone on the network. 1. In order to migrate to OSI from DoD, I think, we need Layer 7 Protocol Converters to provide interoperability for coexistence. Is anybody working on, or has anybody worked on those Protocol Converters before ? Please give me the name of the product. 2. I would like to know which product has already included "Type of Service" routing. Thanks again, please reply to me. Kwang Sung Sr. Software Engineer ARIX Corp. UUCP: ...!sun!aeras!smaug!kwang  -----------[000218][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 88 00:27:57 GMT From: simpsong@ncoast.UUCP (Gregory R. Simpson @ The North Coast) To: comp.os.vms,comp.protocols.tcp-ip Subject: Interfacing HP Workstations to VMS (alternative methods/comments)  Hello, I'm interested in any first hand experience people might have with interfacing Unix Based Workstations with a VMS Decnet network. My specific situation is this: My employer is considering the purchase of several HP Workstations. However, for the purchase to be approved, they must interface cleanly with our large installed base of VMS machines. My approaches toward achieving this goal are: 1) TCP/IP interface... Probably the public domain CMU version. 2) NFS ... A commercial product 3) NS ... Hp's proprietary networking 4) NFS'ing the HP's to an Ultrix uVax and then running decnet between the uVax and the Vax Clusters... How good are the above solutions? Would someone on an HP be able to easily spool jobs to a printer on a VMS machine using one of the above approaches? Do you know of a better approach to achieving a high level of connectivity? Any and all comments are appreciated. Please mail results to me, and I will summarize if interest warrants it. I prefer mail to the address shown below, although other addresses are acceptable. Thanks for any insight, Greg (Prefered e-mail address: simpsong%ltd2.decnet@ge-crd.arpa) -- --- Gregory R. Simpson Prefered Internet: SIMPSONG%LTD2.decnet@ge-crd.arpa or Alternate Internet: necntc!ncoast!simpsong@harvard.HARVARD.EDU UUCP: <BACKBONE>!cbosgd!ncoast!simpsong UUCP: {ames,mit-eddie,harvard,talcott}!necntc!ncoast!simpsong  -----------[000219][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 88 00:58:46 GMT From: budden@tetra.NOSC.MIL (Rex A. Buddenberg) To: comp.protocols.tcp-ip Subject: Friendliness vs performance  For Dave Crocker. I would recast the question more in terms of capacity/throughput traded off against robustness/fault tolerance/survivability. Fair? Most users tend to underestimate the real fault tolerance needs. Once a network is put in place, it attracts applications like ants to a picnic. Before you can spell TCP/IP, the network has become so critical that it's failure becomes intolerable. I'm familiar with a few horror stories like one about a bank that lost its funds transfer net for several hours. The interest charges on the cash it had to borrow to keep afloat ranged into 8 figures. I have three very clear requirements where workstations and sensors on a LAN is clearly the best way to go. In all three cases, network loading is very modest -- one ridiculously so: in terms of dozens of bytes per day [!!]. But fault tolerance -- immunity against either damage or component failure -- is vital to all three. The curious technological development is that in the LAN world, this isn't a trade off. The only fault tolerant LAN architecture out there readily available is doubly linked rings. Discounting Proteon's proprietary products, this leaves FDDI -- somewhat higher performance than ether... Fault tolerance is a lot like paychecks -- most of us rather take them for granted. They come every couple weeks -- especially for us folks whose paychecks are provided by the taxpayers. And like LAN service -- expected to be there when we want to use it. Watch the fracas when your taken for granted paycheck or LAN fails. I'd suggest a caveat for a vendor: fault tolerance may not gain you lots of customers, but lack of it can lose a bunch. Rex Buddenberg  -----------[000220][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 88 10:39:00 PDT From: Dave Crocker <dcrocker@TWG.COM> To: tcp-ip <tcp-ip@sri-nic.arpa> Subject: Re: Friendliness vs. Performance It is quite heartening to have honest-to-goodness customers demanding robustness features. In a perhaps-overly-cautious attempt to avoid getting commercial in the discussion, I did not mention in my previous note that our VMS product was one of the -- maybe even THE -- first to be shipped to customers with Van & Co.'s congestion/slow-line features and the next releases of our Streams and DOS products will contain them. In other words, folks, please don't take my previous comments as suggesting that the robustness features should not be included. My concern was that the absolute assumption of its requirement be tempered somewhat by looking at actual customer requirements; in some percentage of cases, reasonable robustness and superb performance are more important than superb robustness and reasonable performance. Please note that standard implementations of TCP, using old-style congestion and retransmission algorithms, are significantly robust. In fact, we probably are missing the boat by using the term to refer to the recent improvements... The new capabilities do not alter data-loss with respect to the user. They alter packet-loss on the net, thereby reducing retransmission requirements. With or without the new features, users will get equivalent data transfer integrity at the receiving application. With the new code, however, successful COMPLETION of the transfer may be different. (I.e., if you get the bits, they will be correct.) In effect, I was going creating an artificial constraint, much like asking a person who they would save, if a parent and a spouse were drowning and they could save only one. On the other hand, there are limited development resources and prioritizing customer requirements is essential. Just because all you knowledgeable, demanding networkers have the priorities set one way -- which I agree with as someone who has suffered with Internet performance -- does not mean that it is correct for the masses. Long-term, it IS correct, since they will all be part of a global internet and will be subject to the phenomena that the new algorithms address. However, short-term, many of those networkers are isolated. Dave  -----------[000221][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 88 06:07:28 GMT From: hedrick@athos.rutgers.edu (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: Does TCP/IP "comform" to ISO/OSI?  Saying that something conforms to the OSI reference model is essentially meaningless, so yes, TCP/IP does conform. The reference model is the basic conceptual layering. You can use those layers to analyze just about any protocol suite. What you're thinking of is the ISO protocol suite. That's a specific set of protocols, and TCP/IP doesn't follow it. As far as I can tell, vendor statements that their (non-ISO) protocol follows the OSI reference model is almost entirely hype. At best it means that the design is close enough to ISO that eventual migration to the ISO protocols will be easier than with a protocol suite that is very different in philosophy.  -----------[000222][next][prev][last][first]---------------------------------------------------- Date: Thu, 25 Aug 88 11:57:06 CDT From: Mike Rackley <RACKLEY%MSSTATE.BITNET@CUNYVM.CUNY.EDU> To: <tcp-ip@sri-nic.arpa> Subject: named vs. bind SunOS4.0 documents the named daemon as providing internet domain name server capability. I have seen references on the net to porting bind to SunOS4.0 to provide the same capability. What are the differences in named and bind? Mike Rackley Mississippi State University  -----------[000223][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 1988 11:59-EDT From: CLYNN@G.BBN.COM To: steve@GRINCH.UMIACS.UMD.EDU Cc: paul@UXC.CSO.UIUC.EDU, tcp-ip@SRI-NIC.ARPA Subject: Re: Interlan drops a byte? Steve, It looks like another instance of the "have to retransmit a FIN, so better subtract one from the sequence #" bug. Note that the response (maybe to pktnum 2483, but possibly to an earlier packet since the timestamps on 2483 and 2484 are identical) in pktnum 2484 was to ack 1d52f72. Thus the receiver has already received the data being retransmitted in pktnums 2485, 2487 and 2489. [Clearly useless retransmissions -- maybe (the timestamps are all very close) an instance of the "retransmit all unacked data on a retransmission timeout" algorithm, or (the timestamps are not exactly equal) a "retransmit on ack before updating/processing send-left & processing the retransmit queue" design deficiency]. It would have been nice if the trace began earlier, say on the first transmission of the packet containing sequence number 1d53100; was a FIN sent at the "same" time? [Note [fnord sends its fin, with seq # 108d4e02] you mean 108d4e01. Also, notice that in pktnum 2492, a FIN is being (re)transmitted at a different sequence number, 1d53102, than it was in pktnum 2489, 1d53101 = 1d52f71+190.] Charlie  -----------[000224][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 88 10:22:44 GMT From: rcdswal@dutrun.UUCP (Guus van der Wal) To: comp.protocols.tcp-ip Subject: KA9Q with MOCOM NI5010  This must have been asked many times before, but I began to use Ethernet only recently. I have a MICOM interlan NI5010 ethernet adapter in my IBM pc/at. I also have Phil Karn's KA9Q TCP-IP software. The KA9Q docs only talk about the 3COM 3C500 ethernet card. Is there anybody out ther who has (made) KA9Q working with MICOM ?? Thanks in advance Guus -- Guus van der Wal Computing Centre Technical University Delft USEnet: rcdswal@dutrun BITnet: rcdswal@hdetud1  -----------[000225][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 88 12:51:00 GMT From: monty@hcx1.SSD.HARRIS.COM To: comp.protocols.tcp-ip Subject: Re: BLAST?  There is a product called BLAST (and BLAST II) sold by Communications Research Group (800-242-5278 or 504-923-0888). It is an asynchronous file transfer package akin to XMODEM and Kermit. Their literature claims it is far more robust ("error-free" read error correction) and higher performance than either of the above. It is full duplex and uses a sliding window protocol and one spot in their literature says it is X.25 and ISO compatible so maybe the sliding window stuff is borrowed from X.25. I don't think it has anything to do with TCP/IP at all although you could probably run it over a Telnet or Rlogin connection. Our company sells it on our Un*x boxes, I personally have never used it so cannot verify or deny its functionality or performance. Hope this helps. Monty.  -----------[000226][next][prev][last][first]---------------------------------------------------- Date: Thu, 25 Aug 88 17:22:52 EDT From: Alex McKenzie <mckenzie@LABS-N.BBN.COM> To: Ron Guilmette <nsc!rfg@HPLABS.HP.COM> Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Does TCP/IP "comform" to ISO/OSI? It is my personal understanding (as an active participant in some of the ISO groups) that the Reference Model was developed by ISO as a guide to how ISO should think about the functional decomposition of service/protocol standardization. This is something of concern to ISO internally; not something of external concern. Thus there is no Conformance Statement clause in the Reference Model standard, and (consequently) no objective way to evaluate the claim that something does or doesn't "conform to the reference model". Rather, the Reference Model was made an International Standard so the world outside ISO could see and understand (perhaps not agree with) the rules which were to govern the development of standards for particular services and protocols by ISO. Regards, Alex McKenzie  -----------[000227][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 88 15:59:00 GMT From: CLYNN@G.BBN.COM To: comp.protocols.tcp-ip Subject: Re: Interlan drops a byte?  Steve, It looks like another instance of the "have to retransmit a FIN, so better subtract one from the sequence #" bug. Note that the response (maybe to pktnum 2483, but possibly to an earlier packet since the timestamps on 2483 and 2484 are identical) in pktnum 2484 was to ack 1d52f72. Thus the receiver has already received the data being retransmitted in pktnums 2485, 2487 and 2489. [Clearly useless retransmissions -- maybe (the timestamps are all very close) an instance of the "retransmit all unacked data on a retransmission timeout" algorithm, or (the timestamps are not exactly equal) a "retransmit on ack before updating/processing send-left & processing the retransmit queue" design deficiency]. It would have been nice if the trace began earlier, say on the first transmission of the packet containing sequence number 1d53100; was a FIN sent at the "same" time? [Note [fnord sends its fin, with seq # 108d4e02] you mean 108d4e01. Also, notice that in pktnum 2492, a FIN is being (re)transmitted at a different sequence number, 1d53102, than it was in pktnum 2489, 1d53101 = 1d52f71+190.] Charlie  -----------[000228][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 88 16:10:01 GMT From: jgh@root.co.uk (Jeremy G Harris) To: comp.protocols.tcp-ip Subject: Call queueing  The BSD listen(2) syscall (on a socket) provides for the specification of a queue of pending connection requests. So does the TLI T_LISTEN function. What are the pros and cons of this functionality? Is it merely a matter of the cost of copying a protocol control block versus the cost of opening and initialising one? Or is there also a functional benefit? Jeremy. -- Jeremy Harris jgh@root.co.uk  -----------[000229][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 88 20:17:00 EDT From: <enger@gburg.scc.com> To: "dcrocker" <dcrocker@twg.com> Cc: <tcp-ip@sri-nic.arpa> Subject: Friendliness vs. Performance: Performance can provide two WINS I do not mean to diminish the importance of the Friendliness aspects of Van's work. Indeed, I am a user of WIN/TCP 3.2 and thus enjoy the benefits. Van's header-prediction / code-streamlining work can however provide two improvements for the user. First, given the proper underlying network(s), the user can see improvements in transfer speed. More importantly, regardless of the underlying network(s), the user will enjoy a REDUCTION in the amount of CPU utilization. Thus, Van's work could be thought of as efficiency improvements. Everyone wants faster computers; Van has done something to help. Van Jacobson for President! Cheers, Bob Enger  -----------[000230][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 88 16:46:41 GMT From: john@uw-nsr.UUCP (John Sambrook) To: comp.protocols.tcp-ip Subject: Hanging FTP sessions  I've run into a problem with ftp(1) and would appreciate some advice. I would like to move some files via anonymous FTP from one system to another. The systems in questions are Data General MV/10000 systems running DG/UX 3.11 and DG/UX TCP/IP 2.02. I am, of course, able to login to the remote system as user "anonymous", password "guest". If I then do an "ls" command I get a listing of the three directories (bin, etc, pub) in ~ftp, as I expect. So far, nothing unusual. Now, if I try to get a long list, with "ls -l", the connection seems to hang. Believe me, I have waited for periods of thirty minutes but have never gotten past this hang condition. I have the same problem if I try to copy the files I want from ~ftp/pub. The connection is established as expected, with the "PORT" and "Opening data connection" messages printed on our end, but no data ever flows. I have hash mark printing on. I have tried several different systems locally (including VMS, AOS/VS, 4.3BSD) to fetch the files but I still have the hang condition. I don't know if it is related, but when I do "stat" on our local ftp(1) system it prints the page size of both "ftp-user" and "ftp-daemon" as 2048 bytes. Is it possible that this is too long and that some type of fragmentation is occuring? Sorry I can't be more concrete; I don't have a lot of experience debugging TCP/IP problems, and even fewer tools for doing so. Please feel free to send mail; I'll post a summary of responses. If you would rather post a response that's fine too, though I doubt many other people have this problem. Thank you very much, John Sambrook Internet: john@nsr.bioeng.washington.edu University of Washington RC-05 UUCP: uw-nsr!john Seattle, Washington 98195 Dial: (206) 548-4386 -- John Sambrook Internet: john@nsr.bioeng.washington.edu University of Washington RC-05 UUCP: uw-nsr!john Seattle, Washington 98195 Dial: (206) 548-4386  -----------[000231][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 88 16:57:06 GMT From: RACKLEY@MSSTATE.BITNET (Mike Rackley) To: comp.protocols.tcp-ip Subject: named vs. bind  SunOS4.0 documents the named daemon as providing internet domain name server capability. I have seen references on the net to porting bind to SunOS4.0 to provide the same capability. What are the differences in named and bind? Mike Rackley Mississippi State University  -----------[000232][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 88 17:14:17 GMT From: jbvb@VAX.FTP.COM (James Van Bokkelen) To: comp.protocols.tcp-ip Subject: 4.3 networking bugs  The "FIN bit with incorrect sequence number" problem appeared in some early 4.3 tapes. There is a fix for it, which I think has been circulated on comp.bugs.4bsd, and may be available for FTP from ucbarpa. If not, I have a copy (pub/fin_bug.43) on vax.ftp.com. If you don't have source, bitch at your vendor (the fix first circulated last summer). Depending on the vintage of your 4.3, there are a number of other bugs which appear in TCP output, or cause network-related crashes. I know of 9 of these, there may be more. There is another bug, which I just saw: The Van Jacobsen 4.3 code which was made public domain a few months ago sends ICMP Source Quench messages with random values in the "code" field. I asked a friend with source, and he says that the field is not initialized (it should always be 0). James VanBokkelen FTP Software Inc.  -----------[000233][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 88 17:39:00 GMT From: dcrocker@TWG.COM (Dave Crocker) To: comp.protocols.tcp-ip Subject: Re: Friendliness vs. Performance  It is quite heartening to have honest-to-goodness customers demanding robustness features. In a perhaps-overly-cautious attempt to avoid getting commercial in the discussion, I did not mention in my previous note that our VMS product was one of the -- maybe even THE -- first to be shipped to customers with Van & Co.'s congestion/slow-line features and the next releases of our Streams and DOS products will contain them. In other words, folks, please don't take my previous comments as suggesting that the robustness features should not be included. My concern was that the absolute assumption of its requirement be tempered somewhat by looking at actual customer requirements; in some percentage of cases, reasonable robustness and superb performance are more important than superb robustness and reasonable performance. Please note that standard implementations of TCP, using old-style congestion and retransmission algorithms, are significantly robust. In fact, we probably are missing the boat by using the term to refer to the recent improvements... The new capabilities do not alter data-loss with respect to the user. They alter packet-loss on the net, thereby reducing retransmission requirements. With or without the new features, users will get equivalent data transfer integrity at the receiving application. With the new code, however, successful COMPLETION of the transfer may be different. (I.e., if you get the bits, they will be correct.) In effect, I was going creating an artificial constraint, much like asking a person who they would save, if a parent and a spouse were drowning and they could save only one. On the other hand, there are limited development resources and prioritizing customer requirements is essential. Just because all you knowledgeable, demanding networkers have the priorities set one way -- which I agree with as someone who has suffered with Internet performance -- does not mean that it is correct for the masses. Long-term, it IS correct, since they will all be part of a global internet and will be subject to the phenomena that the new algorithms address. However, short-term, many of those networkers are isolated. Dave  -----------[000234][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 88 17:49:28 GMT From: edward@csvaxa.UUCP (Edward Wilkinson) To: comp.bugs.4bsd,comp.unix.wizards,comp.protocols.tcp-ip Subject: Re: Interlan drops a byte? -- NOW: ethernet sniffer tools  In article <978@rlgvax.UUCP> dennis@rlgvax.UUCP (Dennis.Bednar) writes: )In article <3210@cs.utexas.edu>, fletcher@cs.utexas.edu (Fletcher Mattox) writes: )) )) If you look at a packet on the wire, say, with etherfind or tcpdump, )) ... ) )Say, these "ethernet sniffer" tools sound like very useful tools. )Do these tools run on the UNIX machine, or on a PC? Is source )available? Tell me more about them. Thanks. Same here, please! These sound very useful, especially for those debugging ethernet programs. Post the info as it would probably be of use to many. Thanks in advance, Ed -- Ed Wilkinson @ Computer Centre, Massey University, Palmerston North, NZ uucp: {uunet,watmath!cantuar}!vuwcomp!csvaxa!edward DTE: 530163000005 Janet/Greybook: E.Wilkinson@nz.ac.massey Phone: +64 63 69099 x8587 CSnet/ACSnet/Internet: E.Wilkinson@massey.ac.nz New Zealand = GMT+12  -----------[000235][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 88 18:46:15 GMT From: kenk@algedi.UUCP (Ken Koster N7IPB) To: comp.sys.ibm.pc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Networking PC's with VMS , UNIX and Mac's running TOPS  Sundstrand is in the process of choosing a network package that is capable of handling our diverse collection of systems. We currently have a large number of MSDOS pc's (AT,XT,PS-2's,etc.) and 1 AT running uPort UNIX (My machine) that are not networked. We also have a number of VAX running VMS that are networked with DECNET and 30-40 MAC's that are networked with TOPS. I have been asked to submit a list outlining the networking requirements for the engineering department. I would appreciate comments from anyone who has experience either setting up or using various products in this kind of environment. All comments and suggestions would be greatly appreciated. PLEASE - PLEASE - Email direct to me I WILL summerize for the net. Thanks in advance.-- Ken Koster Work: uport SYSV uunet!pilchuck!algedi!kenk A lone Unix-pc Home: Amiga uunet!pilchuck!algedi!kkamie!kenk in the MSDOS swamp Packet Radio: N7IPB@KE7OM  -----------[000236][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 88 21:22:52 GMT From: mckenzie@LABS-N.BBN.COM (Alex McKenzie) To: comp.protocols.tcp-ip Subject: Re: Does TCP/IP "comform" to ISO/OSI?  It is my personal understanding (as an active participant in some of the ISO groups) that the Reference Model was developed by ISO as a guide to how ISO should think about the functional decomposition of service/protocol standardization. This is something of concern to ISO internally; not something of external concern. Thus there is no Conformance Statement clause in the Reference Model standard, and (consequently) no objective way to evaluate the claim that something does or doesn't "conform to the reference model". Rather, the Reference Model was made an International Standard so the world outside ISO could see and understand (perhaps not agree with) the rules which were to govern the development of standards for particular services and protocols by ISO. Regards, Alex McKenzie  -----------[000237][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 88 22:25:46 GMT From: LYNCH@A.ISI.EDU (Dan Lynch) To: comp.protocols.tcp-ip Subject: Re: Does TCP/IP "comform" to ISO/OSI?  Ron, The OSI model is intended to be a reference model for discussing and describing computer to computer communications. It is an idealization of how that communications should take place. It was developed in the late 70's. It has a sevenlayer description that rather clearly describers what should happen on each computer and with their communications devices. TCP/IP when looked at from that model perspective has 4 or 5 layers distinctly differentiated. (Of ocurse, TCP/IP does all of the work, it just does it with a different number of layers -- if you like cake, who cares if it is 5 or 7 layers?) But, TCP/IP does not interoperate with the ISO implementations of OSI. Saying that would be very "confusing". I have seen IBM and DEC and Apple documents that all compare their proprietary protocols to the OSI model They all essentially say they conform to the OSI model. They do, as does TCP/IP. It just does not mean much. What matters is "can the two computers send meaningful traffic back and forth?" Dan -------  -----------[000238][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 88 22:39:11 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: Re: Does TCP/IP "comform" to ISO/OSI?  The question is: Does OSI conform to ARM? The answer is: No. Phil Wood, cpw@lanl.gov  -----------[000239][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 88 00:17:00 GMT From: enger@GBURG.SCC.COM To: comp.protocols.tcp-ip Subject: Friendliness vs. Performance: Performance can provide two WINS  I do not mean to diminish the importance of the Friendliness aspects of Van's work. Indeed, I am a user of WIN/TCP 3.2 and thus enjoy the benefits. Van's header-prediction / code-streamlining work can however provide two improvements for the user. First, given the proper underlying network(s), the user can see improvements in transfer speed. More importantly, regardless of the underlying network(s), the user will enjoy a REDUCTION in the amount of CPU utilization. Thus, Van's work could be thought of as efficiency improvements. Everyone wants faster computers; Van has done something to help. Van Jacobson for President! Cheers, Bob Enger  -----------[000240][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 88 00:49:52 GMT From: hedrick@athos.rutgers.edu (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: Friendliness vs. Performance  It's hard to make guesses as to what will sell. But aside from occasional tests in the PC-compatible area, there isn't a lot of benchmarking hysteria in the TCP/IP world. So I'd think vendors would not be under the sort of pressure to get performance at all costs that they are in some other markets. From the point of view of a manager I can tell you that I get lots of calls about inability to get mail through to distant sites, and broken telnet connections. By and large our users do not carefully time their FTP's and call me when their throughput is only 100 kbits/sec. I have conducted various reviews of Internet performance at the IETF meetings, where we asked an assemblage of network managers what problems they were seeing. Again, it's clear that everytime somebody gets a "connection broken" message, their network manager gets an irate call, but I don't see signs of irate users demanding 20% more speed. (Gross slowdowns are another thing, of course.) So if there were really a speed/robustness tradeoff, I'd strongly recommend that vendors favor robustness. But I'm not even convinced that there is. The only case I know of where using Van's recommendations would slow you down is where by not using them you manage to get more than your fair share of a gateway. It's clear that this isn't a stable situation: only one person can do this at a time, and you can't guarantee that he will be able to do it consistently. Furthermore, you're going to start seeing gateways that defend themselves against this sort of thing. This is not just a concern of us wierdos on the Internet either. There are lots of big corporate networks being built, and they typically have lots of serial lines carefully spec'ed to have no more bandwidth than necessary.  -----------[000241][next][prev][last][first]---------------------------------------------------- Date: Fri, 26 Aug 88 09:37:06 PDT From: postel@venera.isi.edu To: vsi1!versatc!tait@ames.arc.nasa.gov Cc: tcp-ip@sri-nic.arpa Subject: RUNNING FTP IN BATCH MODE  See RFC-1068. --jon.  -----------[000242][next][prev][last][first]---------------------------------------------------- Date: Fri, 26 Aug 88 07:03:22 edt From: snorthc@nswc-g.ARPA To: tcp-ip@sri-nic.arpa, vsi1!versatc!tait@ames.arc.nasa.gov Subject: Re: RUNNING FTP IN BATCH MODE FTP SW has a script facility for their FTP that will allow you to automate login/send/receives. They also have drivers of the excelan card. Now the only question is, did I beat JVB to the punch. :-) Stephen Northcutt (snorthc@nswc-g.arpa) My only relationship with FTP SW is as a user of their products!  -----------[000243][next][prev][last][first]---------------------------------------------------- Date: Fri, 26 Aug 88 18:39:29 -0700 From: Keith McCloghrie <kzm@TWG.COM> To: tcp-ip@sri-nic.arpa Cc: kzm@TWG.COM Subject: Re: SGMP  There is some question about how long SGMP will be around. It is being replaced by SNMP, the specification for which has just been published as RFC 1067. Yesterday's official annoucement (from Jon Postel/Joyce Reynolds) stated : "This memo specifies a draft standard for the Internet community. TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification." The concept of a "draft" standard is new to the Internet community, but the latter sentence leaves no room for doubt about what conformant TCP/IP vendors must do. Note that whereas SGMP (as its name implies) was aimed at managing IP gateways, SNMP uses the set of variables (called the MIB - the Management Information Base) specified by RFC-1065/1066. This set not only includes just about all the gateway-specific and common variables of SGMP, but also adds an initial set of host-specific variables (e.g. TCP and UDP objects). As a result, many more vendors are already implementing SNMP for gateways and for hosts, than ever implemented SGMP. Keith.  -----------[000244][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 88 11:03:22 GMT From: snorthc@NSWC-G.ARPA To: comp.protocols.tcp-ip Subject: Re: RUNNING FTP IN BATCH MODE  FTP SW has a script facility for their FTP that will allow you to automate login/send/receives. They also have drivers of the excelan card. Now the only question is, did I beat JVB to the punch. :-) Stephen Northcutt (snorthc@nswc-g.arpa) My only relationship with FTP SW is as a user of their products!  -----------[000245][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 88 13:13:23 GMT From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) To: comp.protocols.tcp-ip Subject: Re: Does TCP/IP "comform" to ISO/OSI?  Dan: You were absolutely right when you stated, "...TCP/IP does not interoperate with the ISO implementations of OSI. Saying that would be very "confusing"." It is confusing! What *is* an ISO implementation of OSI. OSI is merely a architectural reference model. It is not a protocol nor is it a protocol suite. I have written networking software ten (10) years ago that is con- formant to the OSI model. I doubt that you can find any software suite that allows two (2) or more computer systems to exchange information that is not conformant to the OSI model. The model is a formalized statement of the logical process to establish a communication link and exchange information. Now if you had said that IP/TCP is not interoperable with the ISO IP/T4 protocols or the Internet protocol suite is not interoperable with the DECNet protocol suite. That would be less "confusing". Merton  -----------[000246][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 88 14:00:31 GMT From: mankin@GATEWAY.MITRE.ORG To: comp.protocols.tcp-ip Subject: Re: 4.3 networking bugs  The unitialized code field for ICMP source quench goes back to the original 4.3, Van's code just inherited it.  -----------[000247][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 88 14:32:58 GMT From: nancy@ftp.COM (Nancy Connor) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: RUNNING FTP IN BATCH MODE  You can execute FTP commands from a batch file on some systems. I don't know if Excelan's version of TCP/IP on the PC does this, but some do. In particular, FTP Software's PC/TCP product does this via "take files". Our FTP client will allow you to specify your login name, password and the name of a file on the command line and will then execute commands from the batch file you've specified. If you want more information on PC/TCP, send me mail, but I can't help with Excelan's product. -Nancy Connor FTP Software ...!harvard!ftp!nancy nancy@ftp.com  -----------[000248][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 88 17:11:52 GMT From: auerbach@CSL.SRI.COM (Karl Auerbach) To: comp.protocols.tcp-ip Subject: Re: SGMP  My company, Epilogue Technology, is developing a set of tools for SNMP (the sucessor to SGMP). These include a complete SNMP agent which is both highly portable and small. The same tools could support an SNMP management station. Target date for completion is September 15. These tools have been updated to conform to RFC1065/1066/1067. For further information, please contact Epilogue Technology at 415/594-1141. --karl--  -----------[000249][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 88 18:01:27 GMT From: neil@FLORA.WUSTL.EDU (Gurudatta Parulkar) To: comp.protocols.tcp-ip Subject: References  Dear Sir/Madam: I am looking for discussions/references that happened approximately 1 - 3 years ago that debated the pros and cons of using a fixed Vs variable packet length in high speed packet switches. In particular I am interested in their effect on switch to switch synchronization and also the implications on queue/buffer sizes. References or text including those debates would be greatly appreciated. Neil Barrett Washington University in Saint Louis Computer and Communication Research Center St. Louis, Mo 63130 Net Address: neil@flora.wustl.edu neil%flora.wustl.edu@uunet.uu.net neil%flora.wustl.edu@cunyvm.cuny.edu  -----------[000250][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 88 18:24:48 GMT From: andy@ocsmd.uucp (Andy Liwen) To: comp.protocols.tcp-ip Subject: TCP/IP for big, big Blue  We are looking for _high speed_ connections to an IBM, big iron, type main frame, via TCP/IP / EtherNet, from a SUN or like processor. The data we need to transfer must move faster than the 56Kb rate available to the majority of "line" type connections we have found. Either vanilla ethernet or token-ring seem to be the fastest connections viable for the big blue beast. What we are seeking help on is software TCP/IP access from the big blue iron and hardware alternatives. We have only confirmed IBM (gag) token ring availability on the blue end. We would like to consider ethernet alternatives for blue also. If any one has leads, connections, or products in this area, e-mail replys would really be appreciated. //Andy Liwen ______________________________________________________________________________ uucp : ..uunet!ocsmd!andy bitnet : andy%ocsmd@uunet.uu.net snail : Online Computer Systems internet : andy@ocsmd.uu.net 20251 Century Blvd.  -----------[000251][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 88 20:06:49 GMT From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) To: comp.protocols.tcp-ip Subject: Re: Does TCP/IP "comform" to ISO/OSI?  If there were a Supreme Court of Science (and if it hadn't been packed), I'd be delighted to accept a case which held that the protocol sub-suite consisting of TCP-or-UDP-over-IP is a more appropriate realization of stated "OSI" "Reference Model" principles than is the protocol sub-suite consisting of X.25-and-X.75, on a contingency fee basis. However, since as Charles Hedrick rightly observes, "TCP/IP" isn't in the set of International Standards Organization-sanctioned protocols, and since "conform to OSI" really ought to connote "interoperate with other protocols/ protocol interpeters in the ISO-sanctioned set", if there were a Supreme Court of Semantics, I daresay I'd only be willing to attempt to defend your XYZ Corp.'s blurb on a win-lose-or-draw flat fee basis-- and that a large enough one to be able to retire comfortably on. (And if I won, I'd be sure that that court was packed.) Or, if legal metaphors are not to your taste, a fair way of answering your question is, "Not in any practical sense, even though a sufficiently subtle protocol theologian could probably have a lot of fun with it." cheers, map P.S. In case the reference to the "ARM" in Phil Wood's message was not familiar, it stands for the ARPANET Reference Model, which preexists the ISO/OSI RM in fact, though not on paper (i.e., the ARM didn't get written up [or down] until some years after it had been "invented" ... and used). -------  -----------[000252][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 88 20:07:34 GMT From: msa@clinet.FI (Markku Savela) To: comp.protocols.tcp-ip Subject: CMU TCP/IP and APOLLO ACCESS package  Apollo have a package (ACCESS?), which makes the files on the VMS visible on the Apollo work station (kind of NFS). I guess there is no hope of getting it work under CMU TCP/IP? (Officially it seems to function only with Wollongong and Excelan TCP/IP packages on the VMS). I was brave enough to try starting ACCESS on VAX/VMS running CMU TCP/IP and was revarded by a nice "FATAL BUG CHECK ..." :-) Never expected it to work, but some people win in lotteries, too... -- Markku Savela, msa@clinet.fi  -----------[000253][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 88 20:27:00 GMT From: msa@clinet.FI (Markku Savela) To: comp.protocols.tcp-ip Subject: CMU TCP/IP problem?  This question would belong to some CMU TCP/IP mailing list, but I cannot subscribe (I have to pay for received private mail). We have a CMU TCP/IP version 6.2 on VMS (micro VAX). There seems to be something wrong in closing FTP file transfer connections. They seem seem hang around in some WAIT-state for several seconds after the transfer is completed. This causes problems with MSEND/MPUT -commands, if there are several short files. IP ACP runs out of connections after 20 or 30 files... Perhaps I should order the next version 6.3? Or is this a serious case of RTFM?. Being no wizard on TCP/IP, I installed the package almost with all defaults... Another minor inconvenience is, that it looks like I couldn't FTP files from VMS, unless user has directly access rights to the files. If access rights are given through ACL's, CMU TCP/IP does not seem to notice and refuses the transfer (specifically: user has been granted an "access identifier" and files have a specific ACL entry for this identifier giving access to the owners). Another case of RTFM? :-) --- Markku Savela, msa@clinet.fi  -----------[000254][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 88 21:32:34 GMT From: LYNCH@A.ISI.EDU (Dan Lynch) To: comp.protocols.tcp-ip Subject: Re: Test suite for IP based systems  Bill, I know of no such wonderful regression test suite. DCA has developed (via a contractor) a whole set of tests for TCP/IP and the three applications that does what you want, but it requires putting a lot of probe points in the tested system. The software is available from NBS now. Dan -------  -----------[000255][next][prev][last][first]---------------------------------------------------- Date: 27 Aug 88 01:39:29 GMT From: kzm@TWG.COM (Keith McCloghrie) To: comp.protocols.tcp-ip Subject: Re: SGMP  There is some question about how long SGMP will be around. It is being replaced by SNMP, the specification for which has just been published as RFC 1067. Yesterday's official annoucement (from Jon Postel/Joyce Reynolds) stated : "This memo specifies a draft standard for the Internet community. TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification." The concept of a "draft" standard is new to the Internet community, but the latter sentence leaves no room for doubt about what conformant TCP/IP vendors must do. Note that whereas SGMP (as its name implies) was aimed at managing IP gateways, SNMP uses the set of variables (called the MIB - the Management Information Base) specified by RFC-1065/1066. This set not only includes just about all the gateway-specific and common variables of SGMP, but also adds an initial set of host-specific variables (e.g. TCP and UDP objects). As a result, many more vendors are already implementing SNMP for gateways and for hosts, than ever implemented SGMP. Keith.  -----------[000256][next][prev][last][first]---------------------------------------------------- Date: Sat, 27 Aug 88 19:35:37 -0400 From: Mike Brescia <brescia@PARK-STREET.BBN.COM> To: Martin Holland <mcvax!ukc!stc!idec!prlhp1!hollandm@UUNET.UU.NET> Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Multiple TCP/IP servers on one Host.  How can I add a second server without giving it a different name and internet number so the user will not have to try each server in turn to find a vacant port? I could imagine designing a solution based on the fact that the MICOMs are connected on an ethernet, and they could cooperate, using the same IP address (and, by the way, the same ethernet address, preferably a 'multicast' one). Address recognition in a particular one of the boxes would have to include the IP protocol (TCP), and the TCP port (corresponding to the terminal port.) I know of no such design being implemented, nor how you would invent one that would work on a non-promiscuous net. Perhaps you can trade your box in for one with more ports. Good hunting, Mike  -----------[000257][next][prev][last][first]---------------------------------------------------- Date: 27 Aug 88 16:42:06 GMT From: spock!a3bee2!omega!grzesiak@yale-bulldog.arpa (John L Grzesiak) To: tcp-ip@sri-nic.arpa Subject: Net Help Hello: I have an implementation I'd like to try and have little idea about how to go about it. I have a few UNIX boxes , two of which are CADMUS 9000's . I have Network cards and drivers for these systems. The cards I have are: 3com ethernet and Excelan EXOS 203 (a pair of each). What I'd like to know is: A) Which of these is a better install? (Ease of install , reliable , versatile ,etc) B) Can these cards be cheated and how? ( Can they be used point to point without tranceivers because all I need from them is remote disk mount capability) C) If these cards can't be cheated , where can I get thin ethernet tranceivers and equipment for these? Any help is appreciated - Thank you in advance..... John Grzesiak Omega Dynamics 47 Spring Street Wallingford Ct 06492. (203) 284-8530 voice (203) 289-9300 work (9-5 Eastern) (203) 284-3776 guest:guest (computer) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  -----------[000258][next][prev][last][first]---------------------------------------------------- Date: 27 Aug 88 21:55:22 GMT From: hedrick@aramis.rutgers.edu (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: named vs. bind  Named and bind are sort of the same thing. Named is the name of the name daemon program. Bind seems to be the name of the package as a whole, which includes named and the resolver. However people sometimes say they are bringing up bind when they mean named and visa versa. Sun includes bind as part of 4.0. However there are reasons why somebody might want to start with the current Berkeley source and reinstall it: - they might want the very latest version of named - they might want to build the resolver into libc Let me explain. In case you're not familiar with the terms: the name daemon is a program that keeps a database of all hosts known to your machine. When other programs want to look up a name, they send a message to your name daemon. If it doesn't already know, the name daemon asks other servers around the net, and eventually comes up with an answer, which it sends back to your program. The reason for sending all requests through a single name daemon rather than having each program talk to the network for itself is that this allows the name daemon to build up a cache of known names, so that it normally doesn't have to go out to the network. Individual application programs typically don't last very long, so any cache they built up wouldn't do much good. You need not run the name daemon on each machine. You can put it just on a few servers and point the other systems to them. The resolver is simply a set of subroutines used to send questions to the name daemon, and get back the responses. The most commonly used subroutine is a replacement for gethostbyname. It looks to the caller like the gethostbyname supplied by Sun, but instead of looking things up in the host table or YP, it asks the name daemon. Now, for why somebody might want to port bind to Sun 4.0. Sun supplies named (possibly called in.named). It's slightly out of date, though there's an update package you can get from Sun with the newest one. Sun also supplies the resolver routines in a library libresolv.a. However that only helps you if you have source, since you have to load your programs with -lresolv. Sun's version of telnet, ftp, etc., is not loaded with the resolver, so they will not talk to named. Their idea is that programs should use YP, and YP should talk to named if the name isn't in the YP database. Unfortunately, the interface from YP to named doesn't work. There's an update package you can get from Sun to fix that. However even if it worked, some of us don't like having to go through two different daemons to look up names. Also, the Berkeley resolver lets users define their own abbreviations for host names, and if you put the requests through YP, that mechanism doesn't work. So some of us want to rebuild the sharable library, /usr/lib/libc.so.1.x, so that it has the resolver instead of the YP-based gethostbyname and gethostbyaddr. Because of the way sharable libraries work, this will instantly fix telnet, ftp, etc. If you don't do much Arpanet traffic, it's probably good enough to get the bind update package from Sun, which has the newest named and the fixed version of ypserv that knows how to talk to named. However if you do a lot of network traffic, you'll want to talk to your Sun representative and ask them to create a version of libc with the resolver in it.  -----------[000259][next][prev][last][first]---------------------------------------------------- Date: 27 Aug 88 22:32:15 GMT From: fletcher@cs.utexas.edu (Fletcher Mattox) To: comp.bugs.4bsd,comp.unix.wizards,comp.protocols.tcp-ip Subject: Re: Interlan drops a byte?  In article <3334@imag.imag.fr> pierre@imag.UUCP (Pierre LAFORGUE) writes: >In article <3210@cs.utexas.edu> fletcher@cs.utexas.edu (Fletcher Mattox) writes: >>Has anybody else seen a 4.3BSD VAX with an Interlan Ethernet interface >>drop a byte of data? Well, that's what we're seeing. >>For example, if you >> % rsh remotehost cat 183_byte_file >>and the remotehost is a 4.3/Interlan host, the rsh will fail. > >Your report is not very accurate; Well, no. The report is quite accurate. Maybe it's not as complete as it could have been, though. :-) card: Interlan BD-N11010, rev C, assy rev A, S.N A-103. transceiver: Interlan NA1010 driver: @(#)if_de.c 7.1 (Berkeley) 6/5/86 It does appear that nobody else has seen this, so I'm still a little puzzled. Someone did mention that Interlan shipped some bad cards about five years ago which had a similar problem. Our card is at least that old. Anyway, I've quite worrying about it and just replaced it with a DEUNA, since we have plenty of those. Thanks to all who responded. Fletcher  -----------[000260][next][prev][last][first]---------------------------------------------------- Date: 27 Aug 88 23:35:37 GMT From: brescia@PARK-STREET.BBN.COM (Mike Brescia) To: comp.protocols.tcp-ip Subject: Re: Multiple TCP/IP servers on one Host.  How can I add a second server without giving it a different name and internet number so the user will not have to try each server in turn to find a vacant port? I could imagine designing a solution based on the fact that the MICOMs are connected on an ethernet, and they could cooperate, using the same IP address (and, by the way, the same ethernet address, preferably a 'multicast' one). Address recognition in a particular one of the boxes would have to include the IP protocol (TCP), and the TCP port (corresponding to the terminal port.) I know of no such design being implemented, nor how you would invent one that would work on a non-promiscuous net. Perhaps you can trade your box in for one with more ports. Good hunting, Mike  -----------[000261][next][prev][last][first]---------------------------------------------------- Date: 28 Aug 88 03:45:59 GMT From: romkey@asylum.UUCP (John Romkey) To: comp.protocols.tcp-ip Subject: Re: Call queueing  jgh@root.co.uk asked about why listen(2) allows a queue of pending connection requests. Under the BSD networking model, when you want to listen() for a connection, you first get a socket and then listen() on it. When a connection is opened, you do an accept() (which gets you a new socket) to actually get ahold of the connection. A server which wants to be able to handle more than one connection at a time normally fork()s, and the child process does the actual work while the parent goes back to listen()ing. If you don't allow a queue of pending requests, then from the time when the listen() completes to the time when the server issues a new listen(), there is no one listening. Any incoming requests will then get a reset. The window of time is probably pretty small, on the order of milliseconds, but you want it to be 0. So you need listen() to be able to handle more than one incoming request. And you have to tell listen() how many to handle so that the kernel can allocate appropriate resources. - john romkey  -----------[000262][next][prev][last][first]---------------------------------------------------- Date: 28 Aug 88 03:48:54 GMT From: aglew%vger@XENURUS.GOULD.COM (Andy-Krazy-Glew) To: comp.protocols.tcp-ip Subject: SGMP  ..> Software for SGMP monitoring My wife wrote some stuff to collect statistics from SGMP gateways working for the University of Illinois' CSO. I'm forwarding your note to her, and you can send her email at irvan@uxc.cso.uiuc.edu. Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801 aglew@gould.com - preferred, if you have nameserver aglew@gswd-vms.gould.com - if you don't aglew@gswd-vms.arpa - if you use DoD hosttable aglew%mycroft@gswd-vms.arpa - domains are supposed to make things easier? My opinions are my own, and are not the opinions of my employer, or any other organisation. I indicate my company only so that the reader may account for any possible bias I may have towards our products.  -----------[000263][next][prev][last][first]---------------------------------------------------- Date: 28 Aug 88 03:50:38 GMT From: casey@admin.cognet.ucla.edu (Casey Leedom) To: comp.bugs.4bsd,comp.unix.wizards,comp.protocols.tcp-ip Subject: Re: Interlan drops a byte?  In article <3237@cs.utexas.edu> fletcher@cs.utexas.edu (Fletcher Mattox) writes: > card: Interlan BD-N11010, rev C, assy rev A, S.N A-103. > transceiver: Interlan NA1010 > driver: @(#)if_de.c 7.1 (Berkeley) 6/5/86 Well, I think you're going to have an enormous amount of difficulty trying to use if_de.c with your Interlan. Why don't you try if_il.c? And as someone mentioned earlier, you should grab the latest copy of that driver since there were some significant bugs in the copy distributed with 4.3BSD. Casey  -----------[000264][next][prev][last][first]---------------------------------------------------- Date: 28 Aug 88 06:48:11 GMT From: sung@june.cs.washington.edu (Sung Kwon Chung) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: RUNNING FTP IN BATCH MODE  Here are two quick solutions to do batch-mode ftp. They are written in shell script, that means they are of no use for some of you who don't have the shell, sorry. The first one (ftp1.sh) is for simple ftp'ing. It works fine for small number of files. The limit depends on the command buffer size of mget' and some other factors unknow to me :-) Is is used like, % ftp1.sh host pub a b c d e f g to get file a, b, ..., g on host:pub. The second one (doftp) is a bit more complicated, but versatile (and extensible if you want). doftp uses other two shell scripts (ftp.sh and waitfor). It requires a file which contains the names of the files to be ftp'ed. Each line in the file contains one file name. If files.list' contains wanted file names on host:pub, % doftp host pub files.list will transfer all of them (of course, if everything goes right). I used it to bring over 70 odd (irregularly selected) files from an archive site. To use them, extract the scripts to their names and do "chmod +x" them. Please see the notes at the end of this message before trying them. ========================= ftp1.sh ========================= #!/bin/sh # # simple ftp # Usage: ftp1.sh host direcrory file1 file2 file3 ..... # host=1; directory=2; shift; shift; ftp -n -i host << ___EOF___ user anonymous guest cd directory mget * bye ___EOF___ exit ? ------------------------------------------------------------ The following three files are for the doftp'. ========================= doftp ========================= #!/bin/sh # Usage: doftp host directory namelistfile # needs ftp.sh and waitfor # Set up the pipes and temp files, and invoke ftp and its command feeder # ftp-out$$ : conversation during the job, feed-back to ftp.sh
#     ftp-log$$: just for logging the commands # sung@cs.washinton.edu, 8/22/88 if test "#" != "3" then echo "doftp host directory namelistfile" 1>&2 exit 1 fi oldmask=umask # umask 077 # if we need to make the conversation unreadable cat >ftp-out$$ </dev/null
cat >ftp-log$$</dev/null umask oldmask ( ftp.sh 2 3 <ftp-out$$) |
tee ftp-log$$| ( ftp -v -n 1 >ftp-out$$ 2>&1 )
------------------------------------------------------------
========================= ftp.sh =========================
#!/bin/sh
# ftp.sh: ftp command feeder
#
# Uage: (sleep 1; ftp.sh dir namelistfile <ftp-out) |
#					 (ftp -v -n host-name >ftp-out)
# See doftp' and waitfor'
#	sung@cs.washington.edu, 8/22/88

if test "$#" != "2" then echo " Uage: (sleep 1; ftp.sh dir namelistfile <ftp-out) | (ftp -v -n host-name >ftp-out)" 1>&2 exit 2 fi echo "user anonymous guest" # login result=waitfor "230" # okay? if test "$result" = "ERROR"
then exit 1
fi

echo "cd $1" result=waitfor "250" # 250 CWD successful if test "$result" = "ERROR"
then exit 1
fi

# other FTP commands here, if needed

for f in cat $2 # main loop do destName=$f	# file name change may be used here.  a:b.c --> a-b.c
if test ! -f $destName # get it, only when it is not there then echo "get$f $destName" result=waitfor "226" # 226 Transfer complete case "$result" in
"OK") echo "got $f" 1>&2 ;; "ERROR") echo "failed getting$f, abort the job" 1>&2;
exit 1;;
# other cases may need to be considered here
esac
fi
done
exit 0
------------------------------------------------------------
========================= waitfor ==========================
#!/bin/sh
# Usage: result=waitfor string
#    wait for given string from std input while monitoring error messages
#    Usually, string' is an expected message number (e.g., 250).  It
#    detects 5xx error messages.
#	sung@cs.washington.edu, 8/22/88
while true
do
if  test "$aLine" != "" then case "$aLine" in
"$1"*) echo "OK"; exit 0 ;; *'timed out'*) echo "ERROR"; exit 1 ;; # timeed out message 5*) echo "ERROR"; exit 1 ;; # 5XX error msg *) ; esac else sleep 3 fi done ------------------------------------------------------------ The scripts are for anonymous login. For non-anonymous login, you can change the user' command line. (Be sure to set proper file protection in this case.) Or you can use .netrc file and auto-login feature. In this case, '-n' option is in doftp' should be removed. There is much room for improvement especially for error message handling, and retrial in the case of partial fairlure. So please feel free to make further extensions or modifications as needed. Hope this helps some of you. Sung K. Chung | sung@cs.washington.edu Dept. of Computer Science, FR-35 | {decvax,ucbvax}!uw-beaver!uw-june!sung University of Washington | Seattle, WA 98195 |  -----------[000265][next][prev][last][first]---------------------------------------------------- Date: 28 Aug 1988 18:59-EDT From: CERF@A.ISI.EDU To: craig@NNSC.NSF.NET Cc: tcp-ip@SRI-NIC.ARPA Subject: SIGCOMM Membership SIGCOMM also allows affiliate membership. If you are a member of any of the AFIPS organizations, IEEE, etc., you can become an affiliate member of SIGCOMM without necessarily being a member of ACM. I don't have the dues information at hand, but it costs more that way than if you are already a member of ACM, but possibly less if you don't plan to become a member of ACM because you are already a member of, say, IEEE Computer or Communication Societies. I'll check the$ figures and post to TCP/IP.

Vint

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 88 15:14:41 GMT
From:      fletcher@cs.utexas.edu (Fletcher Mattox)
To:        comp.bugs.4bsd,comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Interlan drops a byte?

>>	driver:		@(#)if_de.c     7.1 (Berkeley) 6/5/86

Um, make that:

driver:		@(#)if_il.c     7.1 (Berkeley) 6/5/86


-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 1988 22:55-EDT
From:      CERF@A.ISI.EDU
To:        nsc!rfg@HPLABS.HP.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?
Just about anything that is layered can be claimed to be conformant.
The TCP/IP protocols don't necessarily include all layers of OSI
(e.g., there isn't a distinct session or presentation layer, for
instance).

I don't think there is much advantage in conformance to the
reference model - the great advantages come from having a
set of compatible and interoperable protocols supported by
many vendors. This is certainly the case for the bulk of the
TCP/IP implementations and will presumably be the case, some day,
for many of the OSI implementations also.

Vint Cerf

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 88 22:59:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   SIGCOMM Membership

SIGCOMM also allows affiliate membership. If you are a member of
any of the AFIPS organizations, IEEE, etc., you can become an
affiliate member of SIGCOMM without necessarily being a member of ACM.

I don't have the dues information at hand, but it costs more that
way than if you are already a member of ACM, but possibly less if
you don't plan to become a member of ACM because you are already a
member of, say, IEEE Computer or Communication Societies.

I'll check the \$ figures and post to TCP/IP.

Vint


-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 88 23:00:52 GMT
To:        comp.bugs.4bsd,comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Interlan drops a byte?

In article <15566@shemp.CS.UCLA.EDU> (casey@cs.ucla.edu) I write:
>   Well, I think you're going to have an enormous amount of difficulty
> trying to use if_de.c with your Interlan.  Why don't you try if_il.c?
> And as someone mentioned earlier, you should grab the latest copy of that
> driver since there were some significant bugs in the copy distributed
> with 4.3BSD.

> From: Chris Torek <chris@gyre.umd.edu>
> Apparently Interlan makes a DEUNA-style board.  Also, the major bugs
> were in if_np.c, not if_il.c ...

Opps!  I should know better too.  Thanks for the correction.

Casey


-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 88 02:55:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Just about anything that is layered can be claimed to be conformant.
The TCP/IP protocols don't necessarily include all layers of OSI
(e.g., there isn't a distinct session or presentation layer, for
instance).

I don't think there is much advantage in conformance to the
reference model - the great advantages come from having a
set of compatible and interoperable protocols supported by
many vendors. This is certainly the case for the bulk of the
TCP/IP implementations and will presumably be the case, some day,
for many of the OSI implementations also.

Vint Cerf


-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Aug 88 10:58:42 EDT
To:        tcp-ip@sri-nic.arpa
Subject:   TDR function of Micom NI5210 card
Has anyone ever gotten the TDR function of the Micom NI5210 card to work?

I've tried it using both thinwire and transceiver connections, opens, shorts
and good connections (plus disconnected xcver cable) and the TDR status
returned is always    87FF

which is , ethernet OK.

Anyone have any ideas?

bkc@omnigate.clarkson.edu

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 1988 11:18-EDT
From:      CLYNN@G.BBN.COM
To:        tcp-ip-request@SRI-NIC.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Call queueing
Jeremy,
As John pointed out, the call queueing is used to reduce the
probability that a SYN arrives during a window where there is no listening
connection to bind it to, thus causing a RESET to be returned.  Queueing
can only reduce it, since it is always possible for there to be more
arriving SYNs than there are remaining free queue slots.  However, I reguard
specifying the size to the kernel to be more for the purpose of "limiting"
resources (such as processes [from the forks] and cpu cycles) than for
"allocating" them.
one of the "minuses" with the BSD implementation is that not only does the
listen cause the arriving SYN to be accepted and bound to a new TCP connection
block, but that the protocol machine is also started.  Thus a connection may
proceed to the ESTABLISHED state and accept/ACKnowledge (usually 4K bytes of)
data before the application-level peer (process) is even created.  This
prevents the process from:
1) examining the IP-address identity of the caller before deciding
ACKnowledge the SYN vs. send a RESET,
What if X were to place a "collect" call to such an implementation
and send 4K data; then the receiver process start up and decides
it doesn't want to accept the call.  Who pays for the 4K bytes?
(The receiver COULD make the 4K available to the appliaction.)
2) checking its routing tables and applying administratively specified
3) selecting initialization parters based on IP-level parameters such as
TOS and options, or
Maybe local system has a method for setting the TCP MSS (which
the spec says has to be in the SYN packet).
4) specifying initial TCP-level options, etc.

Charlie

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 88 08:35:20 GMT
From:      hulsebos@philmds.UUCP (Rob Hulsebos)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   ftp/rcp can't copy devices

When I use the 'ftp' or 'rcp' command, and want to copy a disk-partition
(accessed via /dev/rdsk/*) to the other end, both utilities
complain: "not a plain file".

Of course, the manual doesn't mention that only plain files can be
transferred. Does anybody know why ftp and rcp behave this way?

Suprisingly, copying _to_ a device is allowed. An ftp-command like
"put /unix /dev/null" works fine, and is a nice trick to test the overhead
incurred by the filesystem on the receiving end.

------------------------------------------------------------------------------
R.A. Hulsebos                                       ...!mcvax!philmds!hulsebos
Philips I&E Automation Modules                            phone: +31-40-785723
Building TQ-III-1, room 11
Eindhoven, The Netherlands                                # cc -O disclaimer.c
------------------------------------------------------------------------------


-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Aug 88  14:28:19 EDT
From:      "Roger Fajman" <RAF%NIHCU.BITNET@CUNYVM.CUNY.EDU>
To:        ocsmd!andy@UUNET.UU.NET
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  TCP/IP for big, big Blue
Check out ACC, Advintech, Fibronics, and Network Solutions for TCP/IP
for IBM mainframes running the MVS and MVS/XA operating systems.  For
VM, your best bet is probably the IBM TCP/IP for VM package.  They all
should be listed in the SRI-NIC vendors guide.

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 88 14:11:50 GMT
From:      kdb@lts.UUCP (Kurt D. Baumann)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP under RTX on a PDP-11


Does anyone have any information where I might obtain a copy of
TCP/IP running under RTX on a pdp-11?  I have someone who is
interested getting a copy running on his pdp-11.  Thanks...

Please send mail to me concerning the above if you have any leads as
to where I might be able to find a RTX version of TCP/IP.

By the way, we did not know, that posting to what we thought
(wrongly it seems) was a usenet only group, that our message would
get put onto the arpanet.  Sorry about that, we had no intention of

Thanks!

Kurt Baumann
uunet!lts!kdb


-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 88 14:58:42 GMT
To:        comp.protocols.tcp-ip
Subject:   TDR function of Micom NI5210 card

Has anyone ever gotten the TDR function of the Micom NI5210 card to work?

I've tried it using both thinwire and transceiver connections, opens, shorts
and good connections (plus disconnected xcver cable) and the TDR status
returned is always    87FF

which is , ethernet OK.

Anyone have any ideas?

bkc@omnigate.clarkson.edu


-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 88 15:18:00 GMT
From:      CLYNN@G.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Call queueing

Jeremy,
As John pointed out, the call queueing is used to reduce the
probability that a SYN arrives during a window where there is no listening
connection to bind it to, thus causing a RESET to be returned.  Queueing
can only reduce it, since it is always possible for there to be more
arriving SYNs than there are remaining free queue slots.  However, I reguard
specifying the size to the kernel to be more for the purpose of "limiting"
resources (such as processes [from the forks] and cpu cycles) than for
"allocating" them.
one of the "minuses" with the BSD implementation is that not only does the
listen cause the arriving SYN to be accepted and bound to a new TCP connection
block, but that the protocol machine is also started.  Thus a connection may
proceed to the ESTABLISHED state and accept/ACKnowledge (usually 4K bytes of)
data before the application-level peer (process) is even created.  This
prevents the process from:
1) examining the IP-address identity of the caller before deciding
ACKnowledge the SYN vs. send a RESET,
What if X were to place a "collect" call to such an implementation
and send 4K data; then the receiver process start up and decides
it doesn't want to accept the call.  Who pays for the 4K bytes?
(The receiver COULD make the 4K available to the appliaction.)
2) checking its routing tables and applying administratively specified
3) selecting initialization parters based on IP-level parameters such as
TOS and options, or
Maybe local system has a method for setting the TCP MSS (which
the spec says has to be in the SYN packet).
4) specifying initial TCP-level options, etc.

Charlie


-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 88 15:48:02 GMT
From:      dougm@violet.ICO.ISC.COM ("Doug McCallum")
To:        comp.protocols.tcp-ip
Subject:   Re: Call queueing

-------
> The BSD listen(2) syscall (on a socket) provides for the specification
> of a queue of pending connection requests.  So does the TLI T_LISTEN function.

> What are the pros and cons of this functionality?  Is it merely a matter
> of the cost of copying a protocol control block versus the cost of opening
> and initialising one?  Or is there also a functional benefit?

The reason you want to allow for queueing of incoming connection requests is
that you want to buffer them while an application is processing a previous
one.  The alternative is to reject the connections until the application is
there will be cases where multiple connection requests arrive back-to-back
from the network.  You don't want to reject these so you queue them until
there is time to properly respond.

In the BSD systems, the queued connection requests get accepted
automatically.  In the TLI mechanism, it is possible that the connection
request has not been responded to giving the application final say on
whether to accept or reject the request.

One minor clarification, the TLI indication to queue connection requests is
in the t_bind call and not the t_listen.  T_listen is not the same as the
socket listen.  t_listen waits for an incoming connection request and
returns that to the application.  The information in the connection request
is then given to the t_accept call if the connection is to be accepted or
the t_snddis call if the connection is to be rejected.


-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 88 17:57:35 GMT
From:      jja@tut.fi (Ahola Jari)
To:        comp.dcom.lans,comp.sys.hp,misc.wanted,comp.protocols.tcp-ip
Subject:   TCP/IP for HP 3000/935 and associated questions


Hello there,

I'd like to hear comments from those of you who are familiar
with the software (hardware?) from the Wollongong Group for
the HP 3000 series, if such a thing even exists. The problem
is that we should connect tens of HP's Vectra series PCs, a Sun
workstation to serve the PCs and then the problem: we should also
get the 3000/935 from HP connected to this mess (preferably via Sun).

Question: Has the Wollongong group anything to offer (or some other
party) to provide the following services between Sun/HP 3000 ?

Regular TCP/IP services
Other Goodies

Any information would be greatly appreciated.

-jja

--
Jari 'jja' Ahola	| Tampere University of Technology, CS dept.
Opiskelijankatu 16 A 12 | P.O. Box 527, 33101 Tampere, Finland
33720 Tampere 		| Tel (intl) 358 31 162708 (work)/358 31 174009 (home)
Finland. Puh. 931-174009| Net address: jja@tut (UUCP)  AHOLA@FINTUTA (BITNET)


-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 88 18:24:23 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   Looking for more complete FTP implementations

Here at Sirius Systems we have just about completed our new FTP server and
are looking for others with whom we might exchange files at the upcoming
Interop-88 show.  At the show we expect to have the following features:

Modes:		Stream, Block, and Compressed
Structure:	File and Record
Type:		ASCII and Image
Format:		Noprint, TELNET, and Control (ASA)

We are not going to do structure page since we do not run on
DECSystem-20's.  Neither are we going to support type EBCDIC since the
hosts speak ASCII.  We are also not going to implement the following FTP
commands since they would serve no function on our hosts:

ALLO, ACCT, CDUP, SMNT

In addition to the above we plan to implement the ability to restart a
failed transfer from a checkpoint.  For those of you who care, we use
5120 octets (bytes) as our checkpoint interval (unless someone else can
give us a good reason to use some other value or formula).

If you have an FTP that can do more than the minimum defined
implementation we would like to hear from you.  Thanks.

Brian Lloyd
Sirius Systems, Inc.
P.O. Box 2202
Petersburg, VA 23804
(804) 733-7944
brian@wb6rqn.uucp
Share and enjoy!


-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 88 18:28:19 GMT
From:      RAF@NIHCU.BITNET ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP for big, big Blue

Check out ACC, Advintech, Fibronics, and Network Solutions for TCP/IP
for IBM mainframes running the MVS and MVS/XA operating systems.  For
VM, your best bet is probably the IBM TCP/IP for VM package.  They all
should be listed in the SRI-NIC vendors guide.


-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Aug 88 00:30 EDT
From:      PMDF Mail Server <Postmaster%CC.UMONTREAL.CA@CORNELLC.CCS.CORNELL.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Undeliverable mail
Your message could not be delivered to:

WARD

Your message has been enqueued and undeliverable for 3 days.
The mail system will continue to try to deliver your message

The beginning of your message follows:


-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 88 23:45:54 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TDR function of MICOM NI5210 card

PC/TCP's NI5210 driver implements the TDR function, and I've tested it,
so the hardware is there.  Check your code carefully against the Intel
handbook for the 82586.  I don't think it has anything to do with
jumpers on the card.

James VanBokkelen
FTP Software Inc.


-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 00:05:08 GMT
From:      chris@mimsy.UUCP (Chris Torek)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   Re: ftp/rcp can't copy devices

In article <779@philmds.UUCP> hulsebos@philmds.UUCP (Rob Hulsebos) writes:
>When I use the 'ftp' or 'rcp' command, and want to copy a disk-partition
>(accessed via /dev/rdsk/*) to the other end, both utilities
>complain: "not a plain file".
>
>Of course, the manual doesn't mention that only plain files can be
>transferred. Does anybody know why ftp and rcp behave this way?

Both attempt to determine the size of the file before sending it.
(Only rcp's protocol actually requires this.)  There is no way to
find the size of a special file without reading it, and in the process
the data may vanish (e.g., reading /dev/tty or a socket).
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris


-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 02:25:29 GMT
From:      scottr@CSC-LONS.ARPA (Scott W. Rogers)
To:        comp.protocols.tcp-ip
Subject:   In search of resolver for EXCELAN under XENIX and/or DOS...

In search of a Domain Name Resolver for EXCELAN TCP/IP		8/29/88
I am in search of a domain name resolver (source preferred, binary ok)
for the Excelan TCP/IP under XENIX (8011-04) and/or for Excelan TCP/IP
for DOS (8051 or something like that).  A name Server would also be
necessary, but not required as we have a SUN and a VAX running named.

Excelan TCP/IP (for DOS and XENIX) is based on 4.1BSD sockets (yeach).
If anyone has or knows of any ports for Excelan TCP/IP, please let me
know directly via E-MAIL at "scottr@csc-lons.arpa".  I WILL summarize
to the net.

------------------------------------------------------------------------
Scott W. Rogers		Computer Sciences Corporation - Systems Division
AT&T: (703) 876-1363	3160 Fairview Park Dr. - Falls Church, VA 22152
Fax:  (703) 876-4072	Internet: scottr@csc-lons.ARPA
------------------------------------------------------------------------


-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 04:03:28 GMT
From:      dupuy@douglass.columbia.edu (Alexander Dupuy)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   Re: ftp/rcp can't copy devices


Actually, it is possible to copy from a device, using a somewhat obscurely
documented feature of ftp.  You can specify a shell command as the source or
destination of a tranfer - the command runs on the local machine in either
case.  An example which I used just a few weeks ago:

% ftp another_machine
ftp> send "|dd if=/dev/rst8" somefile.tar
# silly messages from dd and ftp deleted
ftp> bye
%

You don't need the quotes if the command is one word.  This can be quite useful
for spooling dumps to a remote machine which doesn't support /etc/rmt - a big
IBM mainframe with _lots_ of disk space is ideal.  By creating a ~/.netrc file,
you can even have ftp batch jobs to spool your dumps.

As Chris Torek noted, the rcp protocol requires that the size of the file be
known, which is not possible in general for devices.  There is no equivalent
feature (that I know of) in rcp to allow sending from programs.

@alex

--
inet: dupuy@columbia.edu
uucp: ...!rutgers!columbia!dupuy


-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 14:27:03 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: KA9Q with MOCOM NI5010

In article <362@dutrun.UUCP> rcdswal@dutrun.UUCP (Guus van der Wal) writes:

I have a MICOM interlan NI5010 ethernet adapter in my IBM pc/at.
I also have Phil Karn's KA9Q TCP-IP software. The KA9Q docs
only talk about the 3COM 3C500 ethernet card.

Is there anybody out ther who has (made) KA9Q working with MICOM ??

Ha!  Interesting that you should ask that question, since I have recently
ported Bill Doster's NI5010 driver from C (to be compiled in) to a packet
driver.  This is not tested, however.  You (and in fact, anyone who is
interested) can either debug it yourself or wait until I get a NI5010
loaned to me from another department, which may take as long as two weeks.
I'll mail a copy to anyone who's really hot to get a copy...
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
Shuzan held out his short staff and said, "If you call this a short staff,
you oppose its reality.  If you do not call it a short staff, you ignore the
facts.  Now, what do you wish to call it?"


-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 16:15:44 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

>I'd be delighted to accept a case which held that the protocol sub-suite
>consisting of TCP-or-UDP-over-IP is a more appropriate realization of
>stated "OSI" "Reference Model" principles than is the protocol sub-suite
>consisting of X.25-and-X.75

Seems to me this argument of "OSI implies X.25 and X.75" is a little
obsolete.  In the US, I don't expect to have to run OSI protocols over
virtual circuit networks, but rather that future OSI-IP internetworks
will be "equivalent" to the Internet, that is, a connectionless,
datagram network.  In fact, I am looking forward to running OSI
applications, like directory service, on top of tcp/ip protocols.

Of course, in Europe (except UK) the situation is different.

Kent England, Boston University


-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 17:41:21 GMT
From:      keith@tarantula.spider.co.UK (Keith Mitchell)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple TCP/IP servers on one Host.


In <605@prlhp1.prl.philips.co.uk>, Martin Holland raises the issue of how
to get several terminal servers acting in "milking machine" mode to the same
host, to appear as one to other nodes on the network. I could suggest
upgrading to a SpiderPort, which has 10 lines to the NTS100's 8, but I don't
think this is really a terribly helpful solution.

This is an interesting problem, and while there are a number of possible
approaches to solving which fit in with the TCP/IP archectiture, none are
completely satisfactory, particularly if the requirement is for a scheme
which is transparent to the incoming (Telnet client) caller.

One approach could be to use the Telnet Reconnection option (NIC 15391). Here
the connection would be established to a Telnet server which knows when
all the ports on one server were full, and could then tell the client
to try connecting to a different server on another Internet address. However,
this requires the Reconnection option to be implemented on all possible
clients. Since I have never heard of any implementations of this with TCP, I
suspect this approach is a non-starter. Has anyone used the Telnet
Reconnection option over TCP for this sort of thing anywhere ?

There is also an issue here of who does the redirect - should there be a
central server which everybody connects to intially, and which keeps track
of everyone's resources so it knows where to redirect to, or should one
server simply redirect to another when it knows it is full ? The issue
of who knows what ports are free is something which generally needs to be
addressed for various schemes like this. For example, the ARP-based scheme
proposed by Mike Brescia <brescia@park-street.bbn.com>.

Another way is to fudge name lookup in some way. If a name server could be
got at, it could return a different address in response to the same user
string depending on how loaded the telnet servers are. This is not very nice
as it blurs functional boundaries between name servers, and what one could
call "resource location servers". This suggests another approach, where the
client sends a request out to find out what server(s) have free ports, and
uses the information returned to decide who to actually connect to (cf
BOOTP). Resource Location Protocol (RFC 887) might be a possibility here.

A cleaner scheme for exploiting the name lookup mechanism as a solution is
to have an alias-on-fail arrangement. For example if a given hostname fails,
prepend a "&" and try again. The host table would then look something like:

spport1		192.35.138.1
&spport1	192.35.138.2
spport2		192.35.138.3

The disadvantages with this are again it requires non-standard client
software, and the cumulative time-out delay could get quite large towards
the end of the list (eg. &&&spport1 ).

Clearly with all these schemes there is a trade-off between cleanness of
approach, and how transparent it is to existing hosts. If one approach could
be standardised on as best, then I think some progress towards solving

Keith Mitchell

Spider Systems Ltd.		keith@spider.co.uk
Edinburgh, Scotland		keith%spider.co.uk@uunet.uu.net
+44 31-554 9424			...!uunet!ukc!spider!keith


-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 20:03:21 GMT
From:      tomc@oakhill.UUCP (Tom Cunningham)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   CMU TCP/IP and Micom NI1010A


From what I gather, CMU TCP/IP does not support the Micom NI1010A Ethernet
interface.  Has anyone modified the code so that it does?

Tom Cunningham  Motorola Inc.  Austin TX
uunet!mnetor!oakhill!tomc
cs.utexas.edu!oakhill!tomc
--
Tom Cunningham  Motorola Inc.  Austin TX
uunet!mnetor!oakhill!tomc
cs.utexas.edu!oakhill!tomc


-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 20:12:35 GMT
From:      OLE@CSLI.STANFORD.EDU (Ole J. Jacobsen)
To:        comp.protocols.tcp-ip
Subject:   NVLAP information


For informationon NVLAP, contact

John L. Donaldson
Manager, Laboratory Accreditation
National Institute of Standards and Technology  (formerly NBS)
Gaithersburg, MD 20899
(301) 975-4016

Ole
-------


-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 20:52:34 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: KA9Q with MOCOM NI5010

> Is there anybody out ther who has (made) KA9Q working with MICOM ??

I have recently added support for FTP Software's Packet Driver
interface. This allows the code to use any packet driver that follows
the spec. Several people have so far contributed drivers for the following
boards:

TRW PC-2000
NI5010
WD8003

and others are on the way (SLIP, 3C501). A major revision of the package
should be out in a month or so; watch for it.

Phil


-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 21:16:56 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

> 	Does OSI conform to ARM?
>
> 	No.

And, of course, one might ask the question: "Do the 'OSI Protocols'

But even if you limit the discussion to reference models, the "OSI
Model" is hopelessly out of date. By the time you delete the unnecessary
layers (e.g., Session), combine distinct layers that really shouldn't be
separate (e.g., Application and Presentation), create the sublayers
required by modern concepts like internetworking (the Internet and
Subnet Layer) and multiple access networks (e.g., the Media Access
Layer), about the only morsel you'd still have left from the original
OSI model is that "Layering is often a useful tool in building
networks".

Then when you add Postel and Cohen's paper showing how a fixed number of
layers is simply unworkable in the real world, what you finally end up
with looks remarkably like the ARPANET Reference Model (ARM).

But does ISO ever revise its preconceived ideas and admit its mistakes?
Of course not.  It just covers them over with even more paper and ad
hype.

"No Need for XYZ, Just TCP!"   --Seen on a British billboard

Phil


-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 22:36:03 GMT
From:      kwe@bu-cs.bu.edu  (kwe@bu-it.bu.edu (Kent W. England))
To:        tcp-ip@sri-nic.arpa
Subject:   Telnet Options Commonly Supported

I am trying to find a list of the most commonly supported
Telnet options that would be useful for a terminal server or other
implementation to support on the Internet.  I am not interested in
MILnet specific options, unless they are likely to be adopted in the
Internet.

Is this list reasonably complete and well defined?

Original rfc854 characters supported:
interrupt (^C)
abort (^C, ^X?)
hello (Are You There?)
erase character (<BS> or <DEL>)
erase line (^U)
new line character(s) (<CR><LF> or <CR>)
bell (^G)
tab, vt, lf, ff

Commonly supported options:
binary mode
echo control (remote and local, mostly remote)
suppress Go Ahead (not needed for ansi-style terminals)
status (confirm status of telnet options)
terminal type character string
telnet 3270 data streams (tn3270)

I have glanced over rfc1053 and the X.3 terminal handling and
transmission control parameters look quite interesting, but I suspect
it's too early to expect anyone to have any implementations of this.
Have I omitted any widely supported options or included any
widely unsupported options in the above list?
Is there a document that goes into more detail summarizing the
state of telnet options as of a recent date?

Kent England, Boston University

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 23:08:37 GMT
From:      BILLY@VENERA.ISI.EDU ("Billy Brackenridge")
To:        comp.protocols.tcp-ip
Subject:   Microsoft 3Comm MAC Spec available via FTP

I now have an on-line copy of the Microsoft / 3Comm Media ACcess
(MAC) protocol specification.

This specification is the Microsoft 3Comm proposed standard for low
level networking under MS-DOS and OS/2. If you make any kind of
network hardware for IBM-PC or AT machines or write transport layer
protocols, you should look at this specification.

This file can be obtained via FTP from VENERA.ISI.EDU with the
password GUEST. cd to the directory pub and retrieve the file.

The file is 225K bytes long. No I won't mail it to you unless
exceptional conditions warrant exceptional behavior.

This version is dated 5/14/88. There are minor changes since the last
version I distributed.

Feel free to copy this document. Microsoft has assured me they are
interested in the widest possible distribution.

In the past networking code for the PC has been incompatible. The
various TCP/IP packages have been unable to operate resident in a PC
with the commercial proprietary network packages. If this standard is
adopted by the industry, users should have a wider choice of
interoperating protocol stacks and network hardware.

I would like to assume that part of Microsoft's and 3Comm's
motivation for publishing this specification is to get feedback from
the network community. Unfortunately the specification has leaked out
slowly and in a form that appears to be "take it of leave it". There
have been many objections to portions of this specification. Like
"The Last Temptation of Christ" many of those who cry the loudest
haven't read or comprehended the specification. I have corresponded
with others actually attempting to implement this specification who
have serious reservations and suggestions for improvement.

John Romkey will be running a PC special interest group session at
Interop '88. Many people have expressed an interest in discussing
this specification at that session. Everyone with whom I have
corresponded has expressed an interest in seeing a Microsoft and/or
3Comm representative at Interop '88 who can answer technical
-------


-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 23:32:51 GMT
From:      auerbach@CSL.SRI.COM (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: TDR function of MICOM NI5210 card

Recently I put together a driver for an Ether-board that uses the Intel
82586 controller.  As part of the software initialization I had it do
a TDR check.  It was useful for testing the cable, and more importantly,
the drop cable and connectors.

However, there were circumstances where the TDR check failed -- mainly
on broadband networks and over-extended Ethernets.

If you do the TDR it would probably be useful to add an option to bypass
the test for those nets on which it fails but not as a result of an error.

--karl--


-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 88 08:35:00 PDT
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re:  Multiple TCP/IP servers on one host
You have a basic question to ask:  Is the solution to your problem constrained
to use existing mechanisms or do you have freedom to implement additional
capabilities?  If you must use only existing products, then you are unlikely
to find a solution.

In general, Keith Mitchell's set of alternative is reasonable, if you
can build your own mechanisms.  (There are some interesting problems
involved with having the different milking machines know about each other
and each other's availability, but most of this is surmountable.)

Probably the minimum amount of effort -- even having a minute chance of
working without any development -- is to use the ability of the Domain
Name Service to list multiple addresses for a host.  Here's how it goes:

1.  For management purposes, list each milking machine by a unique name.
Then, you can access specific ones, when you need to.

2.  Choose a generic name, under which you list all of the milking machines'

3.  When you need to do an access, use the generic name to do a DNS lookup
and get the list of addresses.

4.  Choose an address from the list.  If you want to attemp load-leveling,
throw a random number, to select the first address.

(Sorry, but true, empirically-derived load-leveling does not work
without all of the inter-milking machine communication mentioned above.)

5.  Pray that the milking machine product sends a reasonable rejection when
all of its lines are full.

6.  When receiving such an error, try the next address.

The reason that you may be able to use this scheme without software development
is that there may be some telnet implementations out there that do step 6

Dave Crocker
The Wollongong Group


-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 88 02:22:20 GMT
From:      efb@suned1.UUCP (Everett F. Batey II)
To:        comp.protocols.tcp-ip
Subject:   Sun netstat traffic for DECNet

Is there any experience using Sun network tools, traffic, netstat, etc to
monitor and diagnose DECNET or DEC LAT, DEC PCSA?  Do any of the Sun
services know how to identify the DEC protos?

--
suned1!efb@elroy.JPL.Nasa.Gov   sun!tsunami!suned1!efb   efbatey@NSWSES.ARPA
Any statements / opinions made here are mine, alone, not those of the
United States, the DoD, the Navy, the Congress, the Judiciary, nor ...


-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 88 14:14:05 GMT
From:      messing@MCL.UNISYS.COM (Judy Messing)
To:        comp.protocols.tcp-ip
Subject:   Re: Test suite for IP based systems

Bill,
The DCA Upper Level Test System, the DCA system referred to by Dan Lynch, is
available through NTIS (National Technical Information Service).  It does not
require any tuning of your protocol implementation.  It does however
require simple application programs (specifications for which are also
available from NTIS) which act as the upper level user of your protocol.
The Test System refers to this programs as remote drivers. Currently,
the Test System runs using Ultrix 1.1.  I believe DCA has plans to port
the system to other operating systems.

We developed this system for DCA and often used the test suites in regression
testing as we tried to ensure that adding new capabilities did not break
things that formerly worked. If you have further questions, I'll be glad

Judy Messing
Unisys


-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 88 14:31:47 GMT
From:      hlg%columbia-pdn@ACC-SB-UNIX.ARPA (Howard Goodman acc_gnsc)
To:        comp.protocols.tcp-ip
Subject:   PING w/source route option


I am looking for a version of PING which supports the source-route option.
If anyone has such an animal, would they please respond to me directly.
The versions I am looking for run on a Vax 750/Unix and a 3B System V.
Thank you.
---------

Howard Goodman
hlg%columbia-pdn@acc-sb-unix.arpa


-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 88 14:46:00 GMT
From:      watt-alan@yale.UUCP
To:        comp.protocols.tcp-ip
Subject:   ANNEX II Terminal Server Experiences?

From: "Alan S. Watt" <watt-alan>

I just received a technical blurb on the "ANNEX II" terminal server
by Encore Computer Corp.  What is especially interesting about it
is you can configure any number of the ports for SL/IP.  The blurb
doesn't mention whether it does proxy ARP, but does say it has
"Full support of 4.3 bsd TCP/IP including Subnets", and "Complete
implementaiton of IP routing".

Question:
Does anyone out there have any experience using this machine
with SL/IP, and if so would they share them, either by
follow-up or E-mail?

- Alan S. Watt
High Speed Networking, Science and Engineering Computing Facility
Dunham 232; (203) 432-4243,4007
watt-alan@cs.yale.edu


-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 88 15:00:21 GMT
From:      scott@h-three.UUCP (scott)
To:        comp.bugs.4bsd,comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Interlan drops a byte?

In article <3210@cs.utexas.edu> fletcher@cs.utexas.edu (Fletcher Mattox) writes:
>Has anybody else seen a 4.3BSD VAX with an Interlan Ethernet interface
>drop a byte of data?  Well, that's what we're seeing.

I've seen Micom/Interlan Ethernet controllers drop bytes. I've seen
them loose a bit, left shifting subsequent data by a bit. Somehow, these
errors were not caught by any of their protocol error checking.

Micom/Interlan claims that fixes are/were in the works. BTW, this was
observed on a Multibus I board.

--
Scott H. Crenshaw			scott%h-three@uunet.uu.net
h-three Systems Corporation             uunet!h-three!scott
POB 12557				100 Park Drive Suite 204
Research Triangle Park, NC 27607	(919) 549-8334


-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 88 15:35:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  Multiple TCP/IP servers on one host

You have a basic question to ask:  Is the solution to your problem constrained
to use existing mechanisms or do you have freedom to implement additional
capabilities?  If you must use only existing products, then you are unlikely
to find a solution.

In general, Keith Mitchell's set of alternative is reasonable, if you
can build your own mechanisms.  (There are some interesting problems
involved with having the different milking machines know about each other
and each other's availability, but most of this is surmountable.)

Probably the minimum amount of effort -- even having a minute chance of
working without any development -- is to use the ability of the Domain
Name Service to list multiple addresses for a host.  Here's how it goes:

1.  For management purposes, list each milking machine by a unique name.
Then, you can access specific ones, when you need to.

2.  Choose a generic name, under which you list all of the milking machines'

3.  When you need to do an access, use the generic name to do a DNS lookup
and get the list of addresses.

4.  Choose an address from the list.  If you want to attemp load-leveling,
throw a random number, to select the first address.

(Sorry, but true, empirically-derived load-leveling does not work
without all of the inter-milking machine communication mentioned above.)

5.  Pray that the milking machine product sends a reasonable rejection when
all of its lines are full.

6.  When receiving such an error, try the next address.

The reason that you may be able to use this scheme without software development
is that there may be some telnet implementations out there that do step 6

Dave Crocker
The Wollongong Group


-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 88 16:55:26 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple TCP/IP servers on one Host.

In article <16115.8808301546@brahma.cs.hw.ac.uk>
> keith@tarantula.spider.co.UK (Keith Mitchell) writes:
>
>In <605@prlhp1.prl.philips.co.uk>, Martin Holland raises the issue of how
>to get several terminal servers acting in "milking machine" mode to the same
>host, to appear as one to other nodes on the network.
>
There are actually two problems: How to assign multiple
rotaries (telco terminology) to one box and how to assign multiple
boxes to one rotary.  It seems to me the solutions to both problems are
related and require particular capabilities of both client and host
server telnet implementations.

>This is an interesting problem, and while there are a number of possible
>approaches to solving which fit in with the TCP/IP archectiture, none are
>completely satisfactory, particularly if the requirement is for a scheme
>which is transparent to the incoming (Telnet client) caller.
>
Seems to me that name server lookup can handle this
transparently, so long as the resolver in the client telnet takes
reasonable actions on the response received.
>
>Another way is to fudge name lookup in some way. If a name server could be
>got at, it could return a different address in response to the same user
>string depending on how loaded the telnet servers are.

This is the same situation as a multi-homed host and I believe
the name server is set up to handle this with multiple records for a
single host.  Just substitute the concept of "multi-box rotary" for
"multi-homed host".  Name servers return all addresses listed for a
given name.  The resolver on the telnet client would need to be smart
enough to try all returned names before giving up on the connection
request.  So the problem becomes one for the client (ie terminal)
server and not the host (ie, milking machine) server.  If the client
server simply tries the first address returned and drops others, then
this approach fails.

The other situation is different.  The host server must be
able to associate a subset of its ports to one IP address, possibly
down to one IP address per port.  Then the client telnet requests
service by name and receives either the single IP address that the
host server will associate to, say, three serial ports, or it receives
three separate responses corresponding to the three separate ports of
that rotary.  In the first case, the client only has to try one
connection and the host server handles port contention itself.  The
second case is the same as the multi-box rotary problem above and the
client server must be able to try multiple addresses in sequence
before aborting the attempt and reporting back to the user.

So it seems to me that the solution is partly in client telnet
(try all addresses in sequence) and partly in the host telnet
(associate one or more ports to one IP address for efficiency).

Kent England, Boston University


-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 88 18:24:24 GMT
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Kent England:

Just for the  record, it seems to ME that there's no connection whatsoever
between my observation that TCP/UDP-IP is philosophically closer to the
"Reference Model" than X.25-X.75 and "this argument of 'OSI implies X.25
and X.75'" you mention.  If anything, the observation is more reasonably
misconstruable as a suggestion that OSI precludes X.25-X.75 than that it
implies 'em, although it doesn't say that either.

Of more interest, however, is whether you'll actually be able to satisfy
your stated expectation that you won't "have to run OSI protocols over
virtual circuit networks " "[i]n the US":  As long as DDN and GOSIP mandate
X.25, neither ARPA nor ISO IP users will be able to avoid paying (in one or
more senses) for unasked-for subnet functionality, in the long haul, as it
were.  Are you, perhaps, counting on ISDN to save the day?  (For that
matter, does anybody out there know for sure whether ISDN, unlike X.25, WILL
offer datagram service, and, unlike X.75, dynamic/"real" alternate routing?)
If so, you'd be better advised to argue with the proprietors of DDN and
the propounders of GOSIP about the non-OSIness of X.25, not with me, since
the bold-face line in the middle of p.154 of _The Elements of Networking
Style_ (Prentice-Hall, 1985) proves that I haven't lumped OSI and X.25 for
several years--even if I'll never forgive the panacea pedlars who had
tricked me into lumping them previously.

cheers, map
-------


-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 88 22:55:50 GMT
From:      mrose@TWG.COM (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Phil, you make me sad.  But now I will make you angry!

Neither you nor I are unbiased observers.  In as much as you have given
your slanted view (i.e., no need for session, presentation should be
application-specific, etc.), I might as well give my slanted views.

The problem with you TCP/IP extremists is that you only have one tool, a
hammer.  It's a nice stainless steel hammer which gets the job done
quite handily.  But it is still a hammer.  As such, every problem to you
guys looks like a nail.  (In fairness, OSI extremists are the same way).
Although at the lower layers, OSI (levels 3&4) is still quite silly at times;
at the upper layers, I think the TCP/IP community could learn quite a
few things.  Some of which you might even find useful.

I won't bother launching into an assault on TCP/IP at this point, for
two reasons: 1) you wouldn't appreciate it, and 2) I'm using it to get
things done today.

The problem is that you snipe at the parts you don't like, rather than
trying to appreciate the entire picture.  On the whole, OSI has a lot of
good points going for it, even though some of the actual parts are
pretty lousy.

/mtr



END OF DOCUMENT