The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 89 06:07:24 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  World record furthest telnet: Australia -> Sweden

Hans,

Unless you tinker with the velocity of light, you are you can't wind around
the world in less than 141 milliseconds, and considerably more if you do
it in real cables or satellites. If you are managing 22K miles in 80 ms,
stop right there and file a "Believe It or Not" claim.

Dave

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 89 14:34:11 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   ultrix 2.2TCP problem


We are having trouble reaching a canadian site from some of our
machines - it's only Ultrix 2.2 ones, not earlier (1.2) or later (3.0)
or suns, hps, xeroxes, RTs, pyramids etc...they can all get throough
fine.

The symptom is odd: we send a SYN, and their (ultrix 3.0) never
replies, else they send a SYN, and we never reply - the packets look fine
by tcpdump; anyone got any clues...(cannot be filtering, coz we can
ping them with any packet sizes...)

thanks

jon 

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 89 16:43:41 GMT
From:      mrose@cheetah.nyser.net (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: X.xxx protocols?

> Perhaps another question worth asking: Can one implement X.400 stds on top
> of what is essentially a TCP/IP environment? Or do we even want to try?
> This probably sounds like a stupid question

RFC1006 defines a method for hosting just about any OSI application on
top of a TCP/IP environment.  As far as X.400 over TCP/IP goes, there is
already an implementation that does in the UK this written by the University
College London and University of Nottingham.  The code is going to alpha
in July.  Look for an openly available release by the end of the year.

/mtr

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Sat, 01 Jul 89 15:34:11 +0100
From:      Jon Crowcroft <J.Crowcroft@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   ultrix 2.2TCP problem

We are having trouble reaching a canadian site from some of our
machines - it's only Ultrix 2.2 ones, not earlier (1.2) or later (3.0)
or suns, hps, xeroxes, RTs, pyramids etc...they can all get throough
fine.

The symptom is odd: we send a SYN, and their (ultrix 3.0) never
replies, else they send a SYN, and we never reply - the packets look fine
by tcpdump; anyone got any clues...(cannot be filtering, coz we can
ping them with any packet sizes...)

thanks

jon 
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 89 01:28:09 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain Name Screaming

In article <8906292105.AA07216@fornax.ece.cmu.edu>, mathis@FORNAX.ECE.CMU.EDU (Matt Mathis) writes:
> Does anybody have a description of the bug (and fix) of the interaction
> between Yellow Pages and the Domain Name System?  This bug causes some
> systems to send DNS requests at high rates for sustained periods in response
> to remote DNS server or network failures.   High rates means typically 20
> per second for workstations.   I have clocked some at as much as 100 pps!
> Needless to say this is hard on gateways, and disaster to people behind
> 56k links.

If this is not what you are talking about, please excuse me.

repeat by:
  1) some program decides to do gethostbyname(foo.bar) or 
	gethostbyaddr(1.2.3.4), checks with portmap & ypbind, and sends 
	an rpc request to the correct ypserv.
  2) ypserv gets the request, fails to find the key in the YP map, and
	since YP-to-DNS is turned on, forks a child which does an
	DNS lookup.
  3) the link to the DNS root or correct authorative server is down or
	congested, so the child does not get an answer for a while.
  4) meanwhile, the original program in step #1 is waiting for the answer.
	If step #3 takes long enough, the original program does a normal
	YP-rpc timeout, retries, and everything is repeated from step #1

This is worse than it looks because the time-out in step #4 is less than
the one in used by the child in step #3.  One can get large numbers of
children of ypserv, all asking the local DNS server for the same answer.

Some programs, ypmatch may be one, seem to try forever.  This would generate
an unbounded, linearly increasing amount of DNS traffic, except that one
usually runs out of resources for the local nameserver and ypserv parent.

The Internet link to sgi.sgi.com is only 9.6b/s.  When this happens here,
it is noticed.

One version of ypserv from Sun adjusted the time the parent waits for its
children to reduce the number of children.  That helped.

We've taken to doing more.  First, our ypserv limits the number of children
it has outstanding.  Second, it keeps track of what its children are asking
and does not start new ones while old ones are asking the same DNS
question.  Third, it caches both negative answers and time-outs from
children, and responds immediately rather making a new child to ask DNS.

Caveats:  Least bad values for the cache aging are not obvious to me.
	We've been running the sum of these fixes for a short time, and
		cannot be certain they are sufficent.
	Not all of these fixes are yet in currently shipping SGI products.


Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 89 02:00:43 GMT
From:      karn@ka9q.bellcore.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP Multiple Echo Replies


Here's one conceivable cause of the multiple echo phenomenon that I don't
think anybody has suggested yet. How about mismatched versions of Ethernet
between a host and a transceiver at some point along the path? Since IEEE
802.3 calls for a collision presence test signal to be generated by the
transceiver after each packet while controllers designed for Ethernet
version 1.0 have never heard of such a thing, is it possible that some
controllers might treat this as a collision even when the packet has been
sent successfully?

Let's hear it for standards bodies making gratuitous changes to established
de-facto standards. (You didn't think I'd resist the opportunity to say
this, did you?)

Pil

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 89 04:15:00 GMT
From:      david@ms.uky.edu (David Herron -- One of the vertebrae)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP Multiple Echo Replies

an anecdote for which I don't have much evidence.

I started noticing repeated ICMP Echo Replies after a change in
our local network.  Now, I'm not 100% certain that we weren't getting
them before this change, but I was surprised to see them happening
afterward.

The change?  The campus backbone is an Ungermann Bass broadband
system.  We were using UB buffered repeaters to attach our local net a
channel on the broadband.  But the campus is converting to using the
Chipcom Ethermodem III with Lanbridge 100.  Our local net has Sun 3's,
a Sequent, uVaxII's with DELQA's and a variety of uVax workstations,
and some 3b2's and 3b1's.  There may be some mismatching of ethernet
versions in there like Phil suggested.
-- 
<- David Herron; an MMDF guy                              <david@ms.uky.edu>
<- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-
<- New word for the day: Obnoxity -- an act of obnoxiousness

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 89 11:11:08 GMT
From:      vixie@decwrl.dec.com (Paul A Vixie)
To:        comp.protocols.tcp-ip
Subject:   DECWRL missing from HOSTS.TXT

So, here I am using comp.protocols.tcp-ip as a news distribution medium.
I'm afraid I have to take back all the nasty things I've thought about
other people who couldn't think of any other way to reach the IP community.
Apologies to all; I don't know how else to get this message out to the
folks who might need to hear it.

The NIC and I seem to have had a miscommunication; in the process of adding
DECWRL's net 16 addresses to the core NS records they keep for us, they
seem to have deleted our HOST entry from the latest (29-June) HOSTS.TXT.

Since there are apparently still a lot of hosts out there who don't know
about the DNS, I can only shudder to think of how much mail is being bounced.

Our address is still "128.45.9.1, 16.1.0.1".  Though the next HOSTS.TXT
will hopefully contain this information, it may be a good idea for
administrators of hosts still using HOSTS.TXT to add decwrl manually -- I
don't know how long it will take for the NIC to publish the next revision.

Again, please accept my apologies for this intrusion.  We now return
control of your display device to the debate over TCP keepalives, which,
IMHO, are a bad idea.

Paul Vixie
DEC WRL
--
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 89 18:47:11 GMT
From:      dennis@gpu.utcs.utoronto.ca (Dennis Ferguson)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP Multiple Echo Replies

Without implying that it is necessarily a cause of duplicated
datagrams, I note that a receiver on a busy HDLC link can receive
duplicate copies of the same frame quite often if the error rate
is high and link-level retransmissions are being done.

The acknowlegement-retransmission scheme HDLC uses requires that the
transmitter resend not only a frame which was received in error, but
also all subsequent frames that were sent before the acknowledgement
indicating a frame was lost arrives.  If the transmitter is busy this
means that not only will the lost frame be retransmitted but almost
certainly the frame following the one in error and perhaps several
more as well.

Thus the receiver may often receive one or more frames following
an error twice.  According to the spec the receiver is supposed to
drop all frames until the errant frame is received successfully.  If
I were implementing this scheme, however, and knew the link was only
going to be used for IP and protocols equally unaffected by out of
order delivery, I would be very tempted to hedge my bets by sending
on everything that arrived without error regardless, this allowing me
to lie a little bit and keep the window advancing if an error occured
in the retransmission of a frame I got right the first time.

Then again, maybe not.  What I have observed is that when our link to
the NSFnet (30-some kbps, between Proteon routers) becomes loaded it
will produce an occasional duplicated packet.  I'm pretty sure this
isn't an ethernet problem since the frequency of occurance seems to
be intimately related to the load on the slow link.  I always wondered
why this happened.  The above seemed a plausible guess.

Dennis Ferguson
University of Toronto

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 89 19:41:18 GMT
From:      cpj@ENG.SUN.COM (Chuck Jerian)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain Name Screaming

I've made about the same changes to a version of yp but never
put them into a release, and have a newer version that does positive
and negative caching, and never forks, its based on a new
asynchronous resolver interface. 
What it does is record that a request is outstanding
and start up the asynchronous resolver,
this is recorded, and any further yp requests for this question
are dropped until the asynchronous resolver succeeds or fails,
the success or failure is cached and used to answer subsequent
requests for some lifetime.
I've also overloaded the  no_more_keys response to be soft error,
for hosts by name, and have arranged for multiple ip addreses 
to be returned by  returning a yp response of the form:

"bogus.com  1.2.3.4\nbogus.com 1.5.4.1"

I've also changed rpc to use exponential backoff at all times,
this eliminates the close spacing of the rpc requests.
			--cpj

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 89 23:01:36 GMT
From:      medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain Name Screaming


This is silly.  Either the DNS is fully authoritative or it isn't.  This
is like checking hosttable information and if not there, asking the nameserver
to take a crack at it.  This may seem sensible on the surface, but if you
think about it a bit, it's a lose.

Say the YP domain has more info than the DNS.  In this case, people outside
the YP domain will get back incorrect or incomplete information, since they
don't have access to the YP information.

Say the DNS has more info than the YP system.  In this case, you can get into a
case where the YP system returns one thing and the DNS returns something
different.  There is of course the issue of who is right, but more important 
is that it's different.  Once you get things consistent, it's a lot easier to
make sure it's saying the correct thing.

The only case where you win is where the DNS and the YP system are totally
consistent with each other, in which case you could have used straight DNS
all along, and not have gone through this mess.  

The implementation issue is orthogonal to the issue of which system is more
authoritative.  Even if YP had the concept of a 'soft-err', you still
have the consistency issue to deal with.  The YP hostinfo architecture works
fine in an environment where you don't have any reason to talk to the
DNS.  If you're connected to the Internet and want to interoperate, then
you have a problem trying to make things play together.

What we have done since 3.5 is rebuild the libc.a library after replacing
the YP hostinfo code completely with DNS resolver equivalents.  This has
worked very well, though under 3.X meant you had to relink the 3.5
utilities, which was a bit difficult since SUN didn't ship you the .o
files.  Under 4.X, it's much easier, as the hostent structures are consistent
with 4.3 BSD, and all you need to do is rebuild the shared libc library, and
all those dynamically linked utilities automagically work fine.  The stuff
that's left (rcp, arp, etc...) can be rebuilt with 4.3 code or SUN source.  

The kind folks at SUN have even gone so far as to do this for you and make
it available for FTP from uunet.uu.net.  They are even handing out the -pic
.o archives (the .o's just before the are linked into the shared libc),
so you can replace whatever pieces you like.  I even hear these things
will be shipped as a standard part of 4.1.  So SUN at least is trying
to do the right thing (backwards compatibility can really be painful
sometimes).  

Note that I've talked about replacing just the YP hostinfo code.  The rest of
the YP system is left intact (so automounter and the rest work fine) to
use if you want...   

					Thanks,
					    Milo

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Mon, 03 Jul 89 13:21:34 -0700
From:      Marshall Rose <mrose@cheetah.nyser.net>
To:        tcp-ip@sri-nic.ARPA, iso@sri-nic.ARPA, isode@sri-nic.ARPA
Cc:        others.;@nisc.nyser.net
Subject:   Communications Week article of July 3, 1989
Hi.  By now you may have read the lead article in Communications Week
about "Internet Advances OSI" by Kelly Jackson.  Whilst I rather like the
article as a whole, there are two subtle mis-quotes and one bit of
mis-information that I thought I should clear up.  I am writing this
"pre-emptively" hoping to avoid a massive flame attack since the two
mis-quotes are mine!

1. The story is about a White Pages pilot project NYSERnet is going to be
running.  It is based on the OSI X.500 protocols.  The article notes
that

	"The Internet currently uses a centralized directory service..."

Please note that this is a reference to WHOIS and **NOT** the DNS.

2. There is a statement about the anticipated size of the pilot and "That
dwarfs the 70,000 entries in the existing Internet directory, most of
which are outdated, said Marshall Rose".  I didn't say *most* of the
entries are outdate.  Merely that some of them are.  That is true of any
white pages service, including the phone book sitting on your desk.  It
should also be noted that I am a proponent of WHOIS, as it is a really
useful service that a lot of people still use daily.

3. There is a statement "Whether the White Pages service actually will
replace the Internet directory service depends on the outcome of the
trial, Rose said."  I didn't say this.  I said "that the success of the
pilot, and whether we would offer it as a production service would be
determined at the end of the trial."  That is, at no time did I say
anything about replacing WHOIS, DNS, or anything else.  And, just for the
record, the pilot project is specifically avoiding doing DNS-like things
simply because I do not believe Directory technology to be currently
competitive to the DNS in this regard.  Some of the more pure-OSI'ists,
may disagree with me.  The focus of the pilot project is more on human
information.

Please understand that from a non-technical perspective, you can see how
what I said got subtly changed into print.  I really can't fault the
article's author for this, though it is somewhat unfortunate.

Anyway, before I get thoroughly hosed/flamed/nuked/whatever, I thought
I'd better come clean.  More denials later, as the need arises (-:

/mtr

ps: If you want more information on the white pages pilot, let me know,
privately (to cut down on netmail).  I can send you a postscript files
containing a little white paper on it.
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 89 06:15:52 GMT
From:      jparnas@larouch.UUCP (Jacob Parnas)
To:        comp.unix.wizards,comp.dcom.modems,comp.protocols.tcp-ip
Subject:   SLIP compression...

I recently got SLIP going (4.3BSD), and while pleased with its function,
I still long for better performance even with V.32 modems.  The obvious
thing to do is add compression.  I knnow there should be a version of SLIP
with header compression coming soon, but I am wondering if anybody has
thought about compressing the contents of the packets as well as the headers.

Has anyone out there implemented or thought about implemeting this?  If
you have, I'd appreciate it if you would drop me a note.

Also, does anybody know if a modem doing MNP level 9 compression in hardware
would help?  (such as the Microcom QX/V.32c)

Also, if one were  add compression to SLIP, where should it be added?
Would it be best to add it to if_sl.c?  

Thanks for any thoughts.

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

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 89 09:32:29 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: World record furthest telnet: Australia -> Sweden



 >The radius of the Earth is about 4000 miles, which gives a
 >circumference of about 25000 miles.  The speed of light is about
 >186000 miles per second, so the lower bound for going around the world
 >is 25000/186000 == 0.13 seconds or so.

 Jeff 

why do we have to go round - right frequency signalling (say
neutrino's) and we could go thru - this gives

4000/186000 = .021 seconds, or 21 msecs :-) 

 jon

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 89 09:37:51 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: World record furthest telnet: Australia -> Sweden



 >In article <8906281206.aa05174@huey.udel.edu>, Mills@UDEL.EDU writes:
 >> Might I interest you in coming up network time (NTP) on those antipodal
 >> hosts and claim the DX award for time synchronization.
 
 >We've done that already ... in fact, that one of the first things we
 >got going (there were some people here sick of clocks that never keep
 >quite the right time - keeping them in sync with each other was fine,
 >but only of marginal interest when that meant they all showed the wrong time).

want to try peering with UCL - we will have a rugby clock up in the
next couple of weeks ...

b.t.w we used to have the longest bridge between two LANs - we did
protocol conversion in an LSI to get from BSP to TCP, but becuase of
the lack of sensible loopback in the LSI, we bounced the bits off a
satellite - the rings concerned were collocated in the basement here -
to ftp from 2 pdp 11/44s in the same room, the fiels had to go
36000km...

jon

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Mon, 03 Jul 89 10:32:29 +0100
From:      Jon Crowcroft <J.Crowcroft@Cs.Ucl.AC.UK>
To:        Jeff Makey <logicon.arpa!Makey@trout.nosc.mil>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: World record furthest telnet: Australia -> Sweden


 >The radius of the Earth is about 4000 miles, which gives a
 >circumference of about 25000 miles.  The speed of light is about
 >186000 miles per second, so the lower bound for going around the world
 >is 25000/186000 == 0.13 seconds or so.

 Jeff 

why do we have to go round - right frequency signalling (say
neutrino's) and we could go thru - this gives

4000/186000 = .021 seconds, or 21 msecs :-) 

 jon

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Mon, 03 Jul 89 10:37:51 +0100
From:      Jon Crowcroft <J.Crowcroft@Cs.Ucl.AC.UK>
To:        Robert Elz <murtoa.cs.mu.oz.au!munnari.oz.au!cs.mu.oz.au!kre@uunet.uu.net>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: World record furthest telnet: Australia -> Sweden


 >In article <8906281206.aa05174@huey.udel.edu>, Mills@UDEL.EDU writes:
 >> Might I interest you in coming up network time (NTP) on those antipodal
 >> hosts and claim the DX award for time synchronization.

 >We've done that already ... in fact, that one of the first things we
 >got going (there were some people here sick of clocks that never keep
 >quite the right time - keeping them in sync with each other was fine,
 >but only of marginal interest when that meant they all showed the wrong time).

want to try peering with UCL - we will have a rugby clock up in the
next couple of weeks ...

b.t.w we used to have the longest bridge between two LANs - we did
protocol conversion in an LSI to get from BSP to TCP, but becuase of
the lack of sensible loopback in the LSI, we bounced the bits off a
satellite - the rings concerned were collocated in the basement here -
to ftp from 2 pdp 11/44s in the same room, the fiels had to go
36000km...

jon
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 89 14:34:23 GMT
From:      amanda@intercon.uu.net (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 on PC/3C503

In article <8906302007.AA08573@vax.ftp.com>, jbvb@VAX.FTP.COM (James Van Bokkelen) writes:
> These are all the DOS tn3270s I know of.
> 
> James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
> FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

Our DOS product supports both TN3270 and "normal" telnet (VT220).  It runs
over a bunch of different Ethernet and LocalTalk boards.  Send mail to
Kurt Baumann <kdb@intercon.uu.net> or me if you want more information.

--
Amanda Walker  <amanda@intercon.uu.net>
InterCon Systems Corporation
--
"Those preachers are right--there's more in these songs
than meets the eye..."  --Arlo Guthrie

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 89 15:09:22 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re: World recort furthest telnet: Australia -> Sweden

As 80 msec around the world seems to be out of the question, how about making
it 80 seconds by adding in congestion and a few source quenches--probably
should add in a few redirects for good measure.  Now all we need is an Internet
node for the Royal Society and an account for Phileas Fogg.  Maybe we should
also have an unauthorized electronics fund transfer from the Bank of England
at about the same time.

Merton

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 89 16:59:59 GMT
From:      nbires!dwm@ucbvax.Berkeley.EDU  (Dave Maclennan)
To:        tcp-ip@sri-nic.arpa
Subject:   In search of info on IBM RSCS and UREP protocols.

I need to find a source for UREP - a protocol/package that I know some folks
at the University of Pennsylvania did some work on back when.  I'm not sure 
exactly how this interoperates with the IBM RSCS protocol, but I know they 
can (must?) be tied together.

Does anyone know of such a package - either commercially available or in
Public Domain that I might be able to lay my hands on (or do you know names
of contacts who might be useful)?  Please mail me if you do.
-- 

Dave W. Maclennan		
NBI Inc., Boulder, CO		dwm@nbires.UUCP or dwm@nbires.NBI.COM
(303) 938-2968 
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 89 18:26:58 GMT
From:      martillo@cpoint.UUCP (Joachim Carlo Santos Martillo)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Token Ring Patent

In article <2377@cpoint.UUCP> martillo@cpoint.UUCP (Joachim Carlo Santos Martillo) writes:

I saw the following article a few weeks ago in comp.protocols.tcp-ip.

>          Unfortunately, I know quite a bit about the Soderblom
>          patent. It was first issued in the fall of 1981 after much
>          consideration at the Patent Office. The senior patent in
>          this area is Farmer and Newhall (AT&T). During the '70's,
>          there were several interferences between the claims of
>          Soderblom and those of Farmer and Newhall.  The Farmer and
>          Newhall design, patented in 1971, was used by Dave Farber to
>          help in the creation of the UC Irvine Ring (If I'm wrong,
>          Dave, Please correct me). Then, Jerry Saltzer, Dave Clark,
>          Ken Pogren and a bunch of people here at Proteon used the UC
>          Irvine Ring to help in the creation of ProNET-10.
 
>          Proteon never expected patent problems. In fact, in 1982, I
>          presented details of our design at IEEE Headquarters in NYC
>          to many AT&T employees including Bob Lucky. We joked about
>          the fact that I was using BSTJ figures for my presentation,
>          thus bringing new meaning to the phrase "not invented here".
>          The Soderblom patent applied to systems which consisted of a
>          master and a plurality of terminals. Farmer and Newhall was
>          the senior patent when it came to closed loop operations.
 
>          In 1983 or maybe 84, Soderblom presented at IEEE802.5. We
>          were well aware of the Soderblom position. IEEE staff were
>          also involved. We went ahead on the basis that Soderblom
>          would provide licenses in a nondiscriminatory way. We also
>          had a good idea of the probable terms for such a license.
 
>          Since that time, the Patent Office has allowed a reissue of
>          the Soderblom patent. The reissue has much more general
>          claims. Many organizations filed objections which were
>          brushed aside by the patent Office. That's why he has
>          general coverage of a 1967 idea until 1998. His patents have
>          run out elsewhere in the world. Don't blame Olaf.
 
>          Many of us object to the whole procedure. That is, Was the
>          token ring a new concept or an" old combination" in 1967?
>          Many of us object to the details of the legal rangling.
>          Nonetheless many of us have signed up simply because the
>          patent office has spoken. In all cases, the exact terms of
>          the license are covered by a non disclosure clause.
 
>          It is also clear that some have chosen not to sign a
>          license with Soberblom. It is expected that someone will
>          take this to court for resolution.  Time will tell.
 
>          Howard Salwen, Chairman-Founder
>          Proteon, Inc.
>          hs@relay.proteon.com


I looked up the patent abstract in the Patent Office Official Gazette
of October 6, 1981.  The engineering library at MIT has a
subscription. On page 420 is found patent number 4,293,948, Data
Transmission System, whose abstract follows.

1.  Apparatus for the transmission of data characters in pulse form
from a plurality of terminal units to a master unit comprising in 
combination:

	pulse input and pulse output means for each said terminal
	unit and for said master unit,

	a single series loop connecting said terminal units in
	series along said loop between the pulse output means
	and pulse input means of said master unit and over which
	pulses originating either with said master unit or any
	terminal unit are transmitted always in the same
	predetermined direction,

	each said terminal unit including:

	(a) pulse responsive means connected to said pulse input means
	for receiving pulses appearing at said pulse input means,

	(b) decoding means distinctively responsive to pulses
	received by said pulse responsive means,

	(c) and logic means responsive to said decoding means for
	normally interconnecting said pulse input and pulse output
	means to thereby complete the loop at said terminal, unit,

	(d) said logic means in response to a distinctive pattern
	of said pulses appearing at the associated pulse input
	means interrupting the loop between said pulse input and
	pulse output means of stored data of arbitrary variable 
	length as required by said terminal unit for transmission
	over the loop to said master unit,

	(e) said logic means being effective upon the opening of 
	said at the first upstream terminal unit having data to
	send for inhibiting the receipt at any downstream terminal
	unit of pulses otherwise effective to control said downstream
	terminal unit to transmit data.

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

As usual, the language is totally obscure, and if the actual patent
is similarly written, I would feel that the patent officer would have
been negligent not to have rejected the application on those grounds
alone.  I wrote away for the complete patent (it only costs a $1.50)
but if this abstract contains the key elements of the patent, the
issue of whether the token ring was a new concept or an old
combination in 1967 seems totally irrelevant.

From the abstract, Soderblum seems to have patented a circuit which
is an intelligent unidirectional digital repeater/transceiver.  The
intelligence involves the ability to become a transmitter of queued
data upon reception of signals (a packet) on the receive input.
Clearly, the 802.5 MAU is such an intelligent unidirectional digital
repeater/transceiver.  Likewise, the FDDI MAU contains two
intelligent unidirectional digital repeater/transceivers.  However, I
doubt either MAU has any circuits borrowed from the Soderblom
circuit.

Now, I would consider the following scenario analogous to what
Soderblom has achieved at the patent office.

It is 1890 and I build the first electric stove which I patent.
After I start selling my electric stove, other people begin selling
electric stoves.  However, their heating elements, control elements
and insulation are completely different.  In fact, other
manufacturers begin manufacturing toasters and perculators and other
devices which cook or prepare food using heat generated by
electricity.

I then go off and accuse all of these other manufacturers of patent
infringement.  I would hope that the court would find my claims
gratuitous except in the case of a stove manufacturer who had copied
my original electric stove down to the nuts and bolts.

In other words, I would have rights to my own design and that's all.
Purporting to owning the concept of cooking with
electrically-generated heat would seem a bit presumptuous.

The Soderblum patent is equally presumptuous.  Unidirectional digital
repeaters have been around since the 50s.  Adding a circuit so that a
digital repeater receiving a signal from the receive input could
become a transmitter is a nice little modification, and it might even
have been slightly difficult using 1967 hardware logic and it may
even be reasonable to give Soderblum a patent for that specific 1967
circuit which no one in their right mind would ever use today.
However, the trend to make relative dumb repeating, amplifying and
filtering devices ever more intelligent through the addition of
interpretive or program-type logic has existed in electronics since
the first electronics engineers began working at the job and
certainly has increased with the availability of microcontroller
chips, PLAs and PLDs. 

There is no obvious justification in granting patent rights over all
circuits which constitute a class distinguished from a pre-existing
class of circuits simply through minor extensions to enable some
interpretation of incoming data with the result that the behavior of
the circuits might be altered on the basis of interpretation.

Joachim Martillo



	

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 89 18:30:14 GMT
From:      martillo@cpoint.UUCP (Joachim Carlo Santos Martillo)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Token Ring Patent

In article <2413@cpoint.UUCP> martillo@cpoint.UUCP (Joachim Carlo Santos Martillo) writes:
>In article <2377@cpoint.UUCP> martillo@cpoint.UUCP (Joachim Carlo Santos Martillo) writes:
>
>I saw the following article a few weeks ago in comp.protocols.tcp-ip.
>
>>          Unfortunately, I know quite a bit about the Soderblom
>>          patent. It was first issued in the fall of 1981 after much
>>          consideration at the Patent Office. The senior patent in
>>          this area is Farmer and Newhall (AT&T). During the '70's,
>>          there were several interferences between the claims of
>>          Soderblom and those of Farmer and Newhall.  The Farmer and
>>          Newhall design, patented in 1971, was used by Dave Farber to
>>          help in the creation of the UC Irvine Ring (If I'm wrong,
>>          Dave, Please correct me). Then, Jerry Saltzer, Dave Clark,
>>          Ken Pogren and a bunch of people here at Proteon used the UC
>>          Irvine Ring to help in the creation of ProNET-10.
 
>>          Proteon never expected patent problems. In fact, in 1982, I
>>          presented details of our design at IEEE Headquarters in NYC
>>          to many AT&T employees including Bob Lucky. We joked about
>>          the fact that I was using BSTJ figures for my presentation,
>>          thus bringing new meaning to the phrase "not invented here".
>>          The Soderblom patent applied to systems which consisted of a
>>          master and a plurality of terminals. Farmer and Newhall was
>>          the senior patent when it came to closed loop operations.
 
>>          In 1983 or maybe 84, Soderblom presented at IEEE802.5. We
>>          were well aware of the Soderblom position. IEEE staff were
>>          also involved. We went ahead on the basis that Soderblom
>>          would provide licenses in a nondiscriminatory way. We also
>>          had a good idea of the probable terms for such a license.
 
>>          Since that time, the Patent Office has allowed a reissue of
>>          the Soderblom patent. The reissue has much more general
>>          claims. Many organizations filed objections which were
>>          brushed aside by the patent Office. That's why he has
>>          general coverage of a 1967 idea until 1998. His patents have
>>          run out elsewhere in the world. Don't blame Olaf.
 
>>          Many of us object to the whole procedure. That is, Was the
>>          token ring a new concept or an" old combination" in 1967?
>>          Many of us object to the details of the legal rangling.
>>          Nonetheless many of us have signed up simply because the
>>          patent office has spoken. In all cases, the exact terms of
>>          the license are covered by a non disclosure clause.
 
>>          It is also clear that some have chosen not to sign a
>>          license with Soberblom. It is expected that someone will
>>          take this to court for resolution.  Time will tell.
 
>>          Howard Salwen, Chairman-Founder
>>          Proteon, Inc.
>>          hs@relay.proteon.com
>
>
>I looked up the patent abstract in the Patent Office Official Gazette
>of October 6, 1981.  The engineering library at MIT has a
>subscription. On page 420 is found patent number 4,293,948, Data
>Transmission System, whose abstract follows.
>
>1.  Apparatus for the transmission of data characters in pulse form
>from a plurality of terminal units to a master unit comprising in 
>combination:
>
>	pulse input and pulse output means for each said terminal
>	unit and for said master unit,
>
>	a single series loop connecting said terminal units in
>	series along said loop between the pulse output means
>	and pulse input means of said master unit and over which
>	pulses originating either with said master unit or any
>	terminal unit are transmitted always in the same
>	predetermined direction,
>
>	each said terminal unit including:
>
>	(a) pulse responsive means connected to said pulse input means
>	for receiving pulses appearing at said pulse input means,
>
>	(b) decoding means distinctively responsive to pulses
>	received by said pulse responsive means,
>
>	(c) and logic means responsive to said decoding means for
>	normally interconnecting said pulse input and pulse output
>	means to thereby complete the loop at said terminal, unit,
>
>	(d) said logic means in response to a distinctive pattern
>	of said pulses appearing at the associated pulse input
>	means interrupting the loop between said pulse input and
>	pulse output means of stored data of arbitrary variable 
>	length as required by said terminal unit for transmission
>	over the loop to said master unit,
>
>	(e) said logic means being effective upon the opening of 
>	said at the first upstream terminal unit having data to
>	send for inhibiting the receipt at any downstream terminal
>	unit of pulses otherwise effective to control said downstream
>	terminal unit to transmit data.
>
>---------------------------------------------------------------------
>
>As usual, the language is totally obscure, and if the actual patent
>is similarly written, I would feel that the patent officer would have
>been negligent not to have rejected the application on those grounds
>alone.  I wrote away for the complete patent (it only costs a $1.50)
>but if this abstract contains the key elements of the patent, the
>issue of whether the token ring was a new concept or an old
>combination in 1967 seems totally irrelevant.
>
>From the abstract, Soderblum seems to have patented a circuit which
>is an intelligent unidirectional digital repeater/transceiver.  The
>intelligence involves the ability to become a transmitter of queued
>data upon reception of signals (a packet) on the receive input.
>Clearly, the 802.5 MAU is such an intelligent unidirectional digital
>repeater/transceiver.  Likewise, the FDDI MAU contains two
>intelligent unidirectional digital repeater/transceivers.  However, I
>doubt either MAU has any circuits borrowed from the Soderblom
>circuit.
>
>Now, I would consider the following scenario analogous to what
>Soderblom has achieved at the patent office.
>
>It is 1890 and I build the first electric stove which I patent.
>After I start selling my electric stove, other people begin selling
>electric stoves.  However, their heating elements, control elements
>and insulation are completely different.  In fact, other
>manufacturers begin manufacturing toasters and perculators and other
>devices which cook or prepare food using heat generated by
>electricity.
>
>I then go off and accuse all of these other manufacturers of patent
>infringement.  I would hope that the court would find my claims
>gratuitous except in the case of a stove manufacturer who had copied
>my original electric stove down to the nuts and bolts.
>
>In other words, I would have rights to my own design and that's all.
>Purporting to owning the concept of cooking with
>electrically-generated heat would seem a bit presumptuous.
>
>The Soderblum patent is equally presumptuous.  Unidirectional digital
>repeaters have been around since the 50s.  Adding a circuit so that a
>digital repeater receiving a signal from the receive input could
>become a transmitter is a nice little modification, and it might even
>have been slightly difficult using 1967 hardware logic and it may
>even be reasonable to give Soderblum a patent for that specific 1967
>circuit which no one in their right mind would ever use today.
>However, the trend to make relative dumb repeating, amplifying and
>filtering devices ever more intelligent through the addition of
>interpretive or program-type logic has existed in electronics since
>the first electronics engineers began working at the job and
>certainly has increased with the availability of microcontroller
>chips, PLAs and PLDs. 
>
>There is no obvious justification in granting patent rights over all
>circuits which constitute a class distinguished from a pre-existing
>class of circuits simply through minor extensions to enable some
>interpretation of incoming data with the result that the behavior of
>the circuits might be altered on the basis of interpretation.
>
>Joachim Martillo
>
>
>
>	
>
>

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 89 19:17:09 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain Name Screaming

In article <8907022301.AA01289@erendira.arc.nasa.gov>, medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) writes:
> 
> This is silly.  Either the DNS is fully authoritative or it isn't...
> 
> Note that I've talked about replacing just the YP hostinfo code.  The rest of
> the YP system is left intact (so automounter and the rest work fine) to
> use if you want...   

This is reasonable, but there is a minor hassle.  The named stuff I know
about is not nearly as easy to set up in a small site as YP.  There is more
typing, and room for choice with 4.3+ named configuration files.  Given
that DNS is more powerful, one would be surprised if it were otherwise.  In
its current state, named is more appropriate for sites such as ours with
network hacks who like to fiddle with resolv.conf's, named.boot's, .rev
files, and so on.  Is there an alternative to a resolv.conf listing the
servers on each client?  The broadcast RPC of YP is insecure, but it is
easier to reassign servers.  Named is also a bit unforgiving--ever notice
what happens if you happen to put a period after a host address in a
database file?  You define a name=-1.  Don't forget the fun chaos one can
make with resolver loops.

Obviously, most of these are characteristics of the 4.3 implementation and
not DNS itself.  Many (but not all) of the well known bad parts of YP are
implementation shortcomings rather than protocol botches.

Notice that the vast majority of all workstations do not have access to the
Internet, are on very small networks, and do not have an a priori need for
DNS.

Always relying on either DNS or YP is an incomplete answer.  It is
sometimes necessary to have your own, private extensions to the central
government's data.  For example, imagine that you do not have root
passwords for the DNS/YP server(s), and that you want to use rcp to a host
which is not correctly in the databases--maybe one of central governments
has not processed the paper work needed before adding a new hostname, or
made a mistake.


Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 89 20:21:34 GMT
From:      mrose@CHEETAH.NYSER.NET (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Communications Week article of July 3, 1989

Hi.  By now you may have read the lead article in Communications Week
about "Internet Advances OSI" by Kelly Jackson.  Whilst I rather like the
article as a whole, there are two subtle mis-quotes and one bit of
mis-information that I thought I should clear up.  I am writing this
"pre-emptively" hoping to avoid a massive flame attack since the two
mis-quotes are mine!

1. The story is about a White Pages pilot project NYSERnet is going to be
running.  It is based on the OSI X.500 protocols.  The article notes
that

    "The Internet currently uses a centralized directory service..."

Please note that this is a reference to WHOIS and **NOT** the DNS.

2. There is a statement about the anticipated size of the pilot and "That
dwarfs the 70,000 entries in the existing Internet directory, most of
which are outdated, said Marshall Rose".  I didn't say *most* of the
entries are outdate.  Merely that some of them are.  That is true of any
white pages service, including the phone book sitting on your desk.  It
should also be noted that I am a proponent of WHOIS, as it is a really
useful service that a lot of people still use daily.

3. There is a statement "Whether the White Pages service actually will
replace the Internet directory service depends on the outcome of the
trial, Rose said."  I didn't say this.  I said "that the success of the
pilot, and whether we would offer it as a production service would be
determined at the end of the trial."  That is, at no time did I say
anything about replacing WHOIS, DNS, or anything else.  And, just for the
record, the pilot project is specifically avoiding doing DNS-like things
simply because I do not believe Directory technology to be currently
competitive to the DNS in this regard.  Some of the more pure-OSI'ists,
may disagree with me.  The focus of the pilot project is more on human
information.

Please understand that from a non-technical perspective, you can see how
what I said got subtly changed into print.  I really can't fault the
article's author for this, though it is somewhat unfortunate.

Anyway, before I get thoroughly hosed/flamed/nuked/whatever, I thought
I'd better come clean.  More denials later, as the need arises (-:

/mtr

ps: If you want more information on the white pages pilot, let me know,
privately (to cut down on netmail).  I can send you a postscript files
containing a little white paper on it.

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 89 22:13:09 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain Name Screaming



I accept your justification for providing the option to use pure YP to
handle host names.  What I think people are complaining about is the
combination of YP and DNS.  If people are on a self-contained network
that doesn't use the DNS, by all means let them use YP.  However if
they need the DNS, they should use it directly -- not frontended by
YP.  Having two different sources for the same information is asking
for trouble, and having systems as complex as YP and the DNS interact,
particularly with caches in between, is going to make problem
diagnosis a nightmare.  If somebody is using the mixed YP/DNS, they're
going to have to learn how to set up the DNS anyway.  You haven't
gained them anything by mixing the two.  You've just made their setup
a lot more complex.  Sun's approach of providing different versions of
the sharable libc is a good one.  (So is providing libc_pic.a, since
it lets me replace the resolver with the newest Berkeley one.)  Even
easier would be an approach where gethostbyname checks for some
file (e.g. /etc/resolv.conf) to see which approach to use.  That
way they'd only have to distribute one binary.  Pyramid checks
for /etc/nameserver.  It's a file whose contents don't matter.  If
it is present, their gethostbyname talks to the DNS rather than the
host table.

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 89 22:23:07 GMT
From:      geoff@FERNWOOD.MPK.CA.US (the terminal of Geoff Goodfellow)
To:        comp.protocols.tcp-ip
Subject:   Internet Advances OSI (Users To Test X.500 Service)

is the front page headline of COMMUNICATIONSWEEK, July 3, 1989 by
Kelly Jackson:

NEW YORK -- NYSERNet Inc. this week will begin the industry's largest pilot
of a global directory service based on Open Systems Interconnection
protocols, COMMUNICATIONSWEEK has learned.
   The OSI X.500 Directory Services test, which will run through May 1990,
will feature the emerging X.500 standard protocol for a distributed user
directory running over the TCP/IP-based Internet research-and-development
network. 
   The test could have implications for all users of Transmission Control
Protocol/Internet Protocol-based networks.  It will demonstrate how ISO
Application Layer protocols can run across existing communications
protocols, such as TCP/IP.  Such a model of coexistence between OSI and
TCP/IP is crucial for users planning to migrate from TCP/IP to OSI, the
emerging standard for internetworking, industry experts said.
   The trial service is expsted to encompass more than 100 Internet sites
nationwide by the end of the year.
...
   The Internet currently uses a centralized directory service, which is
updated manually by technicians at the Internet Network Information Center
at SRI International Inc., Menlo Park, Calif.  That directory includes
entries of users and computers on the network.  The White Pages being
tested are a more modern version of that directory service.
   "It's about time we made the Internet Directory work," said Danial
Lynch, president of Advanced Computing Environments, a Mountian View,
Calif., consulting and education firm.  "The old one got too big and too
outdated."
   The more comprehensive White Pages directory service, which is expected
to replace the existing directory by the late 1990s, will free
participating Internet users from the backlogs and space constraints
characteristic of a centralized directory, industry experts said.
   For the test, NYSERNet plans to accumulate 2 million directory entries
consisting of users and organizations.  That dwarfs the 70,000 entries in
the existing Internet directory, most of which are outdated, said Marshall
Rose, a senior scientist at NYSERNet.

Feature Combination

   "We wrote the software on top of X.500 that supports a name-based
architecture.  That's a more natural way for users" to look up other users
on the Internet, said Rose.  With the X.500 protocol, the White Pages
directory eventually will combine electronic messaging and facismile
functions with basic directory queries, Rose said.
...
   The new White Pages system is based on Version 5.2 of the International
Organization for Standardization Development Environment (ISODE) software,
a programming tool developed by Rose and his former counterparts at
Northrop Corp.'s Research and Technology Center in Los Angeles.
...
   To participate in the pilot, users first must load the White Pages
database with their user data.  Once that data is entered, the program
assists users in maintaining their directories by sending occasional
electronic messages reminding them to update database information.
   Whether the White Pages service actually will replace the Internet
directory service depends on the outcome of the trial, Rose said.  NYSERNet
technicians will determine whether the X.500-based directory can handle the
volume of entries. and whether users can maintain their own portions of the
directory, Rose said.
   NYSERNet will demonstrate the White Pages service at the INTEROP '89
conference, which will be held in San Jose, Calif., in October.

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 89 22:42:22 GMT
From:      morrison@accuvax.nwu.edu (Vance Morrison )
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Super Cheap IP router ($800) Software Ver 2.0 now beta testing


               Call for Beta Testers from PCroute 2.0


Hello All,

I have written debugged, and alpha-tested the next version of the
PCrouter software.  For those of you who don't know what PCroute is,
it is a piece of software can turn an old XT or AT into an IP router.

The best part of all of this is due to the low cost of and XT clone and
ethernet cards, you can make an IP router for under $800.  Not bad since
A Cisco router doing the same thing cost $8000.   (granted, Cisco is
a higher performance machine, but I think you will be pleasantly supprised
by the throughput of this software, we do a fair amount of NFS and FTP
and really don't notice the difference).

I have been testing this code for about 3 weeks now in 9 PCrouters here
at Northwestern and they seem to be operating properly.  But before I
schedule an 'official' release (3 - 4 Weeks), I would like to get some
other people trying PCroute in situation we simply don't have here at
Northwestern.

The software itself as well as the source code can be found on 
accuvax.nwu.edu (129.105.49.1) in pub/pcroute.  The source code is
compressed, and both the source and the software has been 'tarred'.

Please don't go modifying the code until the official release comes out
in several weeks, then you can make LOCAL modifications to your hearts
content. I Reserve the right to be the SOLE person to make modifications
to PCroute that span organizational boundaries.  My motive is simple,
I want there to be only a single varient of PCroute.  If you have a good
idea you want incorporated let me know and I will probably put it in.

People that aren't on the internet, be patient, in a couple of weeks I
will ask UUNET and other UUCP archives to keep a copy, then you can get
it yourself. 

Here are some of the highlights of Version 2.0 (beta)

                      PCroute  Version 2.0

    PCroute, the software that can convert a PC into a IP router for
about $500, is now in its second major Version. As with version 1 
PCroute supports

        1) Western Digital WD8003 Ethernet and Starlan boards.
        2) Static IP routing (up to 250 routes).
        3) IP subneting
        4) ICMP Ping

    But in addition Version 2.0 also supports

        1) Up to 6 networks interfaces
        2) Localtalk interfaces (MacTCP compatable)
        3) SLIP (coming soon)
        4) ICMP TTL, Redirect, Unreachable 
        5) Fragmentation where necessary
        6) RIP dynamic routing protocol
        7) Error loging using BSD syslog
        8) PROXY ARP (if desired)
        9) Bootp forwarding


Vance
morrison@accuvax.nwu.edu

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 89 01:17:45 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re:  World record furthest telnet: Australia -> Sweden

In article <8907010207.aa04823@huey.udel.edu> Mills@UDEL.EDU writes:
> Unless you tinker with the velocity of light, you are you can't wind around
> the world in less than 141 milliseconds

	Depends on whether you constrain yourself to great circle routes or
not.  You should be able to knock the 141 ms down by a factor of pi if you
go the more direct route.  Of course, you might get bogged down in red tape
arranging the right-of-ways. :-)
-- 
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 89 03:16:38 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Communications Week article of July 3, 1989

Marshall:

Shoot!  I'm confused!  I thought it was just last year that you suggested that
one shouldn't talk to the press as they have a tendency to use "editorial
license" to create a smoothly flowing article--accuracy not being an essential
element of the "smoothing function".

Of course, one shouldn't be surprised by such actions.  DoD runs a six (6)
month course for Program and Proposal Managers which produces the same results
as a four (4) year degree in Journalism.  I still wonder why they grant a
Bachelor of Arts rather than a Bachelor of Science for Journalism--the latter
seems so much more appropriate and accurate.

Merton

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 89 05:24:50 GMT
From:      mrose@cheetah.nyser.net (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: Communications Week article of July 3, 1989

Well, maybe you are confused! (-:  I can't recall ever saying "don't
talk to the press."  I thought I said "be careful".

/mtr

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 89 06:17:48 GMT
From:      lars@salt.acc.com (Lars J Poulsen)
To:        comp.protocols.tcp-ip,comp.dcom.lans,misc.legal
Subject:   Re: Token Ring Patent

In article <2414@cpoint.UUCP> and <2413@cpoint.UUCP> and <2377@cpoint.UUCP>,
martillo@cpoint.UUCP (Joachim Carlo Santos Martillo) writes:

>>As usual, the language is totally obscure, and if the actual patent
>>is similarly written, I would feel that the patent officer would have
>>been negligent not to have rejected the application on those grounds
>>alone. 

The abstract quoted seems unusually clear. This covers the idea of a
token ring.

>>However, I doubt either MAU has any circuits borrowed from the
>>Soderblom circuit.

The patent does not appear to cover a specific circuit implementation,
but rather, it covers the abstract notion of a token ring.

>>Now, I would consider the following scenario analogous to what
>>Soderblom has achieved at the patent office.
>>
>>It is 1890 and I build the first electric stove which I patent.
>>...
>>Purporting to owning the concept of cooking with
>>electrically-generated heat would seem a bit presumptuous.
This is what the patent process is supposed to do !!

>>There is no obvious justification in granting patent rights over all
>>circuits which constitute a class distinguished from a pre-existing
>>class of circuits simply through minor extensions 

The idea of patents is to encourage inventions by allowing the inventor
sole rights to a new idea for a limited time, provided he publishes the
idea, so (a) everybody can use it now if they pay the inventor, and (b)
everybody can use it later, and can build on it.

The best patents are always sweeping ideas with many applications. If
yoiu can't come up with any such, you may be able to invent process
improvements or applications.

----
Oh, there I did it; I let myself get baited into an argument with Martillo
(:-(. At least I've redirected followups.

/ Lars Poulsen <lars@salt.acc.com>     (800) 222-7308  or (805) 963-9431 ext 358
  ACC Customer Service                Affiliation stated for identification only
                  My employer probably would not agree if he knew what I said !!

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 89 06:23:46 GMT
From:      pvo3366@OCE.ORST.EDU (Paul O'Neill)
To:        comp.protocols.tcp-ip
Subject:   Re: Token Ring Patent

Thanks for tracing these details down.  However, your conclutions are all 
wrong.

> Purporting to owning the concept of cooking with
> electrically-generated heat would seem a bit presumptuous.

No, you're presuming it to be presumptuous. :-)  It's actually the makings of a
good patent.  That's what the good ones are all about.  Nailing down a concept.

Take, for instance, Texaco's patent on the use of vacuum tubes in geophysical
prospecting.  It didn't matter *what* circuit you invented, or used.  If it
had a vacuum tube in it and you used it for geophysics, you had to get Texaco's
permission!  Great patent! 

Remember this next time you have a good idea.  Patent the concept.

Paul O'Neill                 pvo@oce.orst.edu
Coastal Imaging Lab
OSU--Oceanography
Corvallis, OR  97331         503-754-3251

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 89 10:20:52 GMT
From:      lindberg@cs.chalmers.se (Gunnar Lindberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain Name Screaming

In article <37409@sgi.SGI.COM> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> ...
>Always relying on either DNS or YP is an incomplete answer.  It is
>sometimes necessary to have your own, private extensions to the central
>government's data...

Yes, isn't the answer "lets have both"? We've tried to get around most
problems with a "gethostbyname()" that uses an algorithm like:

    if (index(host, '.'))	/* with '.', use DNS first	*/
    {
	if ( ! (hp = get_ns_hostbyname(host)))
	    hp = get_yp_hostbyname(host);
    }
    else			/* no '.', assume local YP	*/
    {
	if ( ! (hp = get_yp_hostbyname(host)))
	    hp = get_ns_hostbyname(host);
    }

This way we can use short names for hosts within several domains
(yes I know I'm lazy, :-) and catch them via YP, while real domain
names always get resolved by DNS (of course without "ypserv -i").
Possibly one could argue against at all using YP for names which
contains a '.' - personally I don't think that does anything bad.

We haven't tried this in "sharable libc" yet, but I would guess that's
rather straight forward. If anyone wants the changes theyr're available
for "ftp chalmers.se [129.16.1.1], get ucb/named-4.8-cth.shar".

	Gunnar Lindberg

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 89 13:42:16 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain Name Screaming

In <Jul.3.18.13.06.1989.7187@geneva.rutgers.edu> hedrick@geneva.rutgers.edu
(Charles Hedrick) writes:
> What I think people are complaining about is the combination of YP and
> DNS. [...]  If somebody is using the mixed YP/DNS, they're going to have
> to learn how to set up the DNS anyway.  You haven't gained them anything
> by mixing the two.  You've just made their setup a lot more complex.

	For companies distributing complete operating systems, I probably
agree with Charles.  But, what about for somebody like me who is trying to
get an MX-groking sendmail to run under an originally YP-based system like
SunOS-3.5?  Sendmail needs to talk directly to the DNS system because it
has to get at MX records.  But for the zillions of other programs that have
to do name translation, YP works just fine, and Sun's idea of having YP
hand off to DNS any query it can't resolve itself seems logical.  You don't
really expect me to recompile *every* program that calls gethostbyname() do
you?

	Besides, for all it's grossness (and there is plenty) YP still
provides a reasonably convenient way to share files with local additions.
For example, all our suns share /etc/printcap using YP.  Every machine that
has direct control of a printer has a local /etc/printcap for that printer.
The printcap parsing routines were written to read the local file first and
only go to YP if the name can't be resolved there.  Show me a way to do
that that's easier than YP.

	Yes, for some applications, YP is a big loose and you need to go
full-frontal DNS.  But just because a new and better tool comes along
doesn't mean you should completely throw out the old ones; for some
applications they might actually be better.
-- 
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 89 14:25:58 GMT
From:      david@ms.uky.edu (David Herron -- One of the vertebrae)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain Name Screaming

The latest Ultrix has an interesting file called /etc/svcorder.  It
contains lines telling which name service to consult in what order
when looking up names.  Like

	local
	bind

"local" means /etc/hosts, in which we list information for our local
machines and is generated from the same file which the nameserver
information comes from.  The person who administers that file isn't as
trusting of BIND as I am ...  :-)

The point is that you can mix & match as you please and even use yp.
There aren't any dire warnings in the Ultrix manuals about possibly un-
debuggable situations arising from mixing bind and yp.  Oh well.
Nor anything about authoratative -vs- non-authoratative information
(i.e. generating both "views" from the same file).

In any case, I happen to like this particular way of specifying
this behaviour.

Now, I fail to see all but the most incidental connection to TCP/IP
in this discussion.  A better newsgroup to discuss this in is
comp.protocols.tcp-ip.domains.
-- 
<- David Herron; an MMDF guy                              <david@ms.uky.edu>
<- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-
<- New word for the day: Obnoxity -- an act of obnoxiousness

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 89 19:22:54 GMT
From:      cpj@ENG.SUN.COM (Chuck Jerian)
To:        comp.protocols.tcp-ip
Subject:   in re:quipu as X.500 server

I took a large list of names, and set up the QUIPU server discussed
in the earlier item.  This name server used over 1K of memeory per
name in the list, so that to store the large list of people and machines
that I made of everyone at Su, it used over 16M of virtual memory.
It seemed to reference almost 32M making this list, but freed 
about half of the total.  The data is organized as a giant linked list
within a level of the directory.  A search of the directory using the
ISO search mechanism which allows for 'x*y*z' causes the server to
violently page trash, as it references every page of this giant list.
An answer is sometimes forthecoming in a minute.  The QUIPU server
is better behaved for small sets of names.  

On the other hand gnu-grep can always scan this same list of data
using arbitrary regular expressions which are more powerful than 
those in X.500 in less than .3 seconds on a Sun4/260 with the
data represented as a text file.

This suggests to me that the most important issue in searching name
servers is the organization of data and the choice of algorithms,
those in QUIPU are terrible, much worse than text files and gnu-grep.
					--cpj

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 89 22:40:43 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain Name Screaming

| From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
| 
|   1) some program decides to do gethostbyname(foo.bar) or
| 	gethostbyaddr(1.2.3.4), checks with portmap & ypbind, and sends
| 	an rpc request to the correct ypserv.
|   2) ypserv gets the request, fails to find the key in the YP map, and
| 	since YP-to-DNS is turned on, forks a child which does an DNS
| 	lookup.
|   3) the link to the DNS root or correct authorative server is down or
| 	congested, so the child does not get an answer for a while.
|   4) meanwhile, the original program in step #1 is waiting for the answer.
| 	If step #3 takes long enough, the original program does a normal
| 	YP-rpc timeout, retries, and everything is repeated from step #1
| 
| This is worse than it looks because the time-out in step #4 is less than
| the one in used by the child in step #3.  One can get large numbers of
| children of ypserv, all asking the local DNS server for the same answer.
| 
| Some programs, ypmatch may be one, seem to try forever.  This would
| generate an unbounded, linearly increasing amount of DNS traffic, except
| that one usually runs out of resources for the local nameserver and
| ypserv parent.

  Vernon has described the situation accurately.  Most of the time the
application in question is telnet, ftp or some other user instigated
application.  When this happens the user usually gets tired of waiting
after a while and aborts.  This causes a minor transient load on the
network and the machine running the YP server, but usually nothing you
couldn't live through.

  One application in particular doesn't get tired though: sendmail.  For
every piece of mail you have queued up, there will be a sendmail waiting
for address resolution.  In the stock versions of the Sun OS 3.X,
sendmail will hang forever.  (Note that it really isn't sendmail, but
rather the gethostbyXXXX(3) library routines.)

  In any case, when I ran into this problem in November of 1987 I talked
to Bill Nowicki at Sun about it who was their current sendmail guru (and
probably still is) and he gave me two new sendmail binaries.  Either one
solves the problem described above.

  The first binary is pretty much identical to the standard sendmail
binary, but includes timeouts around all the gethostbyXXXX calls.  He set
the timeout to 90 seconds which I think is way too long, but it gets the
job done.  If a timeout occurs, sendmail just leaves the mail queued up
assuming a temporary delivery failure.  It will return the mail after the
normal three days of trying if it can't deliver it in that time.

  The second binary is much more interesting however.  It completely
bypasses YP and goes directly for the name server itself.  Thus, you get
MX support!  The only thing you have to do to run the MX sendmail is
include the file /etc/resolv.conf if the name server isn't running on the
local host.

  If anyone wants, I have both Sun2 binaries for SUN OS 3.X.  (The
binaries will run fine on a Sun3 - trust me, I've been running them for a
year and a half now.)  They are available via anonymous ftp from
lll-crg.llnl.gov under llnl/named/sun:

% ls -l ~ftp/llnl/named/sun
total 461
-r--r--r-- 1 root   1214 Jan  3 1989 nslookup.help
-rw-r--r-- 1 root    786 Dec  1 1987 sun.rc.local.diff
-rwxr-xr-x 1 ftp  172032 Dec  1 1988 sun2.sendmail*
-rwxr-xr-x 1 ftp  196608 Dec  1 1988 sun2.sendmail.mx*
-rwxr-xr-x 1 root  81920 Jan  3 1989 sun3.nslookup*
lrwxr-xr-x 1 root     13 Dec 24 1988 sun3.sendmail@ -> sun2.sendmail
lrwxr-xr-x 1 root     16 Dec 24 1988 sun3.sendmail.mx@ -> sun2.sendmail.mx

Casey

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 89 04:08:36 GMT
From:      cpj@ENG.SUN.COM (Chuck Jerian)
To:        comp.protocols.tcp-ip
Subject:   in re yp is insecure because it uses broadcast binding.

The use of broadcast binding in yp makes it no more or less secure than
ip in general.  Ip uses the arp protocol over ethernet, and similar
protocols on broadcast/multicast capable media to locate the machine with
a given ip address.  In this regard the holder of any ip address is
as suspect as a putative yp server.  To authenticate any server of a given
service to a client, encryption is required.  The server must possess
some secret key.  Either a mutual authentication algorithm can be used,
such as Diffie Hellman, where the client also requires a secret key,
and a session can be created by using a conversation key based on the
combination of the Pa Sb == Sa Pb, or a certificate can be used from
RSA which only requires a public key for the server, or some private
key scheme can be used with a Needham Schroder authentication server,
(e.g. Kerberos).

Whatever scheme is used, the client can know that he is talking to 
the server who possess the appropriate secret key.

Scheme based on unecrypted addresses provide only the illusion of security.

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 89 04:56:51 GMT
From:      medin@NSIPO.ARC.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain Name Screaming



	 This is reasonable, but there is a minor hassle.  The named stuff I know
	 about is not nearly as easy to set up in a small site as YP.  There is more
	 typing, and room for choice with 4.3+ named configuration files.  Given
	 that DNS is more powerful, one would be surprised if it were otherwise.  In
	 its current state, named is more appropriate for sites such as ours with
	 network hacks who like to fiddle with resolv.conf's, named.boot's, .rev
	 files, and so on.  Is there an alternative to a resolv.conf listing the
	 servers on each client?  The broadcast RPC of YP is insecure, but it is
	 easier to reassign servers.  Named is also a bit unforgiving--ever notice
	 what happens if you happen to put a period after a host address in a
	 database file?  You define a name=-1.  Don't forget the fun chaos one can
	 make with resolver loops.


If you ran named on the clients and told them about the root servers
they could figure out everything else from there.  Of course you could
always broadcast named queries (ugly, but possibly useful for finding
things initially).

If you went to as much effort in making the user interface to BIND as nice
as YP, you'd have it capable of being run more easily in small non-connected
islands as well as in the Internet.  In addition, there are available awk or
perl scripts that take a hosttable as input and output a set of DNS 
files to feed to named.  Sendmail is complicated too, but people didn't
throw it away and write something more friendly.  They put time and effort
into making configuration easier.  It's also a lot more robust than it used
to be.  

	 Obviously, most of these are characteristics of the 4.3 implementation and
	 not DNS itself.  Many (but not all) of the well known bad parts of YP are
	 implementation shortcomings rather than protocol botches.

Agreed.  It's too bad people reject protocol architectures because of 
implementation issues as opposed to fundamental problems with the architecture.
That's why we have ugliness like Appletalk in the world... :-(

	 Notice that the vast majority of all workstations do not have access to the
	 Internet, are on very small networks, and do not have an a priori need for
	 DNS.

How many times have we seen nets of small organizations winding up
connected to the Internet?  Also don't forget that DNS has things like 
multiple address per hostname and MX record support.  YP doesn't.  Even
in a small organization, these things can be useful.  It's much easier 
grwoing if you treat small systems the same way as big ones, rather
than coming up with different solutions.  Look what happens when you get
a large pile of PC's running some brand X proprietary LAN software 
package and then you have to connect to a set of heterogeneous 
systems (like mini's or workstations).  Here you throw away the PC oriented
approach and go with something more standard.  Besides, small systems 
and small networks have a strong tendency to get bigger, because of
technology issues.

	 Always relying on either DNS or YP is an incomplete answer.  It is
	 sometimes necessary to have your own, private extensions to the central
	 government's data.  For example, imagine that you do not have root
	 passwords for the DNS/YP server(s), and that you want to use rcp to a host
	 which is not correctly in the databases--maybe one of central governments
	 has not processed the paper work needed before adding a new hostname, or
	 made a mistake.

Most utilities let you use numbers rather than names.  The fact that rcp
and rlogin don't is an artifact of the implementation.  That is, no one
has bothered to fix it.  In your example, I'd just use FTP.  You will 
always get mistakes that break things, whether it's YP or DNS systems.  
Depending on how the YP space is set up, you may not be any better off
than the DNS case in your example.  There are many organizations (like 
Apple) who have private DNS data that doesn't escape to the outside.  That
isn't an argument for YP, it's an argument for knobs to BIND to make 
that easier.  Remember, the DNS is a protocol architecture, and not
BIND.

Maybe what you're saying is that sometimes YP is the right answer and 
sometimes DNS is.  I buy that, especially given certain implementation
issues.  But trying to get them to work together is a problem.  That's
my main argument anyway.  I'm arguing for consistency.  If YP is what
you want, that's fine, just don't try and mix it up DNS information.  

	 Vernon Schryver
	 Silicon Graphics
	 vjs@sgi.com


					Thanks,
					    Milo

PS Usual disclaimers apply of course...

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 89 09:26:35 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: ultrix 2.2TCP and furthest TCP?



 >We are having trouble reaching a canadian site from some of our
 >machines - it's only Ultrix 2.2 ones, not earlier (1.2) or later (3.0)
 >or suns, hps, xeroxes, RTs, pyramids etc...they can all get throough
 >fine.

It turns out that pre ultrix 3 sets TTL from TCP to 15. Our ultrix one
machines are on the US side of a local gateway, and 15 hops from
canada, so the packets made it with theur last gasp.
Our ultrix 2 machines are 16 hops, so never made it.

Everything (BSDish) else seems to set TTL to 30 or 60, so is fine (but
for how long?).

On a more general note, how come we're getting so many hops? - surely
the internet is evolving tree structured, so we'd expect 
log base Gateway/BackBoneFanout(#nets) to set the max hop count 
(with a bit of random permutation here and there) -
and...
should local (say subnet) routers decrement TTL? Since they dont
participate in global routing, so cannot be part of a global loop?
(ok, except they should decrement TTL on time instead of hop, so as to
bound TCP segment lifetimes)...

 jon

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Wed, 05 Jul 89 10:26:35 +0100
From:      Jon Crowcroft <J.Crowcroft@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: ultrix 2.2TCP and furthest TCP?


 >We are having trouble reaching a canadian site from some of our
 >machines - it's only Ultrix 2.2 ones, not earlier (1.2) or later (3.0)
 >or suns, hps, xeroxes, RTs, pyramids etc...they can all get throough
 >fine.

It turns out that pre ultrix 3 sets TTL from TCP to 15. Our ultrix one
machines are on the US side of a local gateway, and 15 hops from
canada, so the packets made it with theur last gasp.
Our ultrix 2 machines are 16 hops, so never made it.

Everything (BSDish) else seems to set TTL to 30 or 60, so is fine (but
for how long?).

On a more general note, how come we're getting so many hops? - surely
the internet is evolving tree structured, so we'd expect 
log base Gateway/BackBoneFanout(#nets) to set the max hop count 
(with a bit of random permutation here and there) -
and...
should local (say subnet) routers decrement TTL? Since they dont
participate in global routing, so cannot be part of a global loop?
(ok, except they should decrement TTL on time instead of hop, so as to
bound TCP segment lifetimes)...

 jon

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 89 12:15:17 GMT
From:      martillo@cpoint.UUCP (Joachim Carlo Santos Martillo)
To:        misc.legal,comp.protocols.tcp-ip
Subject:   Re: Token Ring Patent

In article <874@anise.acc.com> lars@salt.acc.com (Lars J Poulsen) writes:
>In article <2414@cpoint.UUCP> and <2413@cpoint.UUCP> and <2377@cpoint.UUCP>,
>martillo@cpoint.UUCP (Joachim Carlo Santos Martillo) writes:
 
>>As usual, the language is totally obscure, and if the actual patent
>>is similarly written, I would feel that the patent officer would have
>>been negligent not to have rejected the application on those grounds
>>alone. 
 
>The abstract quoted seems unusually clear. This covers the idea of a
>token ring.

Really! Soderblom patented a unidirectional digital repeater/transceiver
and nowhere mentioned repeater.  That is real clarity.  Now it is
possible that the complete patent mentions that the circuit is a digital
repeater, but I doubt it for the very good reason that the concept of a
digital repeater is not patentable in 1967. 

>>However, I doubt either MAU has any circuits borrowed from the
>>Soderblom circuit. 
 
>The patent does not appear to cover a specific circuit implementation,
>but rather, it covers the abstract notion of a token ring.

No, it covers a much larger class of digital repeaters against
which Soderblom is making no claims because the bogosity of
this patent would be obvious.

>>Now, I would consider the following scenario analogous to what
>>Soderblom has achieved at the patent office.
 
>>It is 1890 and I build the first electric stove which I patent.
>>...
>>Purporting to owning the concept of cooking with
>>electrically-generated heat would seem a bit presumptuous.
>This is what the patent process is supposed to do !!

Wrongo! You can patent non-obvious extensions to existing ideas.  In
1890 the concept of cooking with heat was well-known and the concept of
generating heat via electricity was well-known.  The concept of cooking
with electrically-generated heat would have been practically
self-evident to any engineer working in the field especially since
chemists were already using electrically generated heat to stimulate
chemical reactions (sounds like cooking to me) at this time period. 

>>There is no obvious justification in granting patent rights over all
>>circuits which constitute a class distinguished from a pre-existing
>>class of circuits simply through minor extensions 
 
>The idea of patents is to encourage inventions by allowing the inventor
>sole rights to a new idea for a limited time, provided he publishes the
>idea, so (a) everybody can use it now if they pay the inventor, and (b)
>everybody can use it later, and can build on it.

But that is it exactly.  There is nothing at all new in a slightly
intelligent unidirectional digital repeater in 1967.  Giving a old
device a new name to obscure what it really is does not a new idea make. 
There may be something new and clever in the specific circuit Soderblom
invented, and I have no problem with the Soderblom patent covering
the specific circuit.

>The best patents are always sweeping ideas with many applications. If
>you can't come up with any such, you may be able to invent process
>improvements or applications.

Yes, the digital repeater in the 1950's was a sweeping idea with many
applications, but Soderblom did not invent it. 

>----
>Oh, there I did it; I let myself get baited into an argument with Martillo
>(:-(. At least I've redirected followups.
 
>/ Lars Poulsen <lars@salt.acc.com>     (800) 222-7308  or (805) 963-9431 ext 358
>  ACC Customer Service                Affiliation stated for identification only
>                  My employer probably would not agree if he knew what I said !!

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 89 15:33:36 GMT
From:      mar@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Domain Name Screaming


   Date: 4 Jul 89 13:42:16 GMT
   From: phri!roy@rutgers.edu  (Roy Smith)

	   Besides, for all it's grossness (and there is plenty) YP still
   provides a reasonably convenient way to share files with local additions.
   For example, all our suns share /etc/printcap using YP.  Every machine that
   has direct control of a printer has a local /etc/printcap for that printer.
   The printcap parsing routines were written to read the local file first and
   only go to YP if the name can't be resolved there.  Show me a way to do
   that that's easier than YP.

But we do the exact same thing here at Athena using our Hesiod name
service.  Hesiod is a set of simple library routines layered over BIND
that give us the ability to lookup account information, access groups,
filesystems, printers, etc.  We have the flexibility of the DNS, and
only one kind of database to maintain for hosts and other information.
We find that it's faster to look up something though Hesiod than
scanning a local text file, even if it's not already in the local
named cache.
					-Mark Rosenstein

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 89 16:23:10 GMT
From:      DSTEVENS@DSRM12.STEVENS-TECH.EDU (David L. Stevens)
To:        comp.protocols.tcp-ip
Subject:   RE: World record furtest telnet: Australia -> Sweden

>     
> >The radius of the Earth is about 4000 miles, which gives a
> >circumference of about 25000 miles.  The speed of light is about
> >186000 miles per second, so the lower bound for going around the world
> >is 25000/186000 == 0.13 seconds or so.
>     
> Jeff
>     
>why do we have to go round - right frequency signalling (say
>neutrino's) and we could go thru - this gives
>     
>4000/186000 = .021 seconds, or 21 msecs :-)
>     
> jon
>

 Wrong, Radius = ~4000 miles ==> Diameter = ~8000 miles
 therefor 8000/186000 = .043 seconds (maximum delay)
   
 Couldn't resist
===============================================================================
|                                  |                                          |
| David L. Stevens                 | CCnet:    SITVXC::DSTEVENS               |
| Senior Systems Programmer        | BITnet:   DSTEVENS@STEVENS               |
| Stevens Institute of Technology  | INTERnet: DSTEVENS@VAXC.STEVENS-TECH.EDU |
|                                  |                                          |
===============================================================================
[ ...self realization, I was thinking of those immortal words of Socrates     ]
[    when he said: 'I drank what ?'     -   Val Kilmer  -  Real Genius        ]
------------

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 89 16:34:55 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain Name Screaming


	From: phri!roy@rutgers.edu  (Roy Smith)

	... Yes, for some applications, YP is a big loose [sic] and you
	need to go full-frontal DNS.  But just because a new and better
	tool comes along doesn't mean you should completely throw out
	the old ones; for some applications they might actually be
	better.

YP and the domain system are completely different beasts, and should
never be asked to talk to each other.  Host name service should be DNS
based, except for isolated nets (here one might want to use YP simply
because it makes for one less thing to learn).  Here is why.

The domain service system is a fully distributed database.  It deals
with such issues as network partitioning and multiple administration
(to the tune of thousands of individuals or groups administering their
own part of the database).

YP is a centralised authoritarian database.  It can, to some extent,
handle a partitioned network, but it does not allow independent
administration.  It believes in a master/slave relationship; and
for someone to be able to set up (e.g.) password or printer service
one needs to be the master.  By definition, everyone else is a slave.

Distributed and centralised databases just do not mix.

One caveat:  We have never used YP at all here (at the CS Department;
there are other groups at the College Park campus that do use YP), so
in some cases I am speaking through a metaphorical hat.  No doubt if
I am wrong we will all hear about it.

Chris

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 89 18:07:29 GMT
From:      jml@tw-rnd.SanDiego.NCR.COM (Michael Lodman)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Woolongong Software

I want to contact Woolongong (sp?) Software and I have no idea how.
Could someone please help out?

-- 
Michael Lodman               Mike.Lodman@SanDiego.NCR.COM
NCR Corporation  -  Distributed Systems Lab  -  San Diego
9900 Old Grove Rd.  San Diego, CA.  92131  (619) 693-5353

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 89 18:44:06 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: in re yp is insecure because it uses broadcast binding.

In article <8907050408.AA20722@sparky.Eng.Sun.COM>, cpj@ENG.SUN.COM (Chuck Jerian) writes:
> The use of broadcast binding in yp makes it no more or less secure than
> ip in general....
> Scheme based on unecrypted addresses provide only the illusion of security.

Agreed, but...

An unknowing person can make a machine a YP server for the local domain.
If the machine started with reasonable databases, it can be weeks or months
before neighbors who happen to bind to the impostor start having problems,
and then they tend to seem wierd and impossible.  I've heard that you guys
on the other side of the dump have often had the same problem.

A similar problem occurs if two machines come up with the same IP address.
However, in standard 4.xBSD, at least one of them will complain.  We have
found that having the complainer defend its address not only makes the
other machine also complain, but can keep links up enough to fix the
problem.  It would be nice if ypserv could do something similar.

Both of these are not security issues, except in the same very weak sense
that memory protection makes an operating system "secure."  It's more a
matter of detecting and making difficult errors than of putting bad guys
out of business.

BTW, I miss-wrote about YP or DNS being incomplete solutions.  I meant that
either and/or both are incomplete and that ULTRIX and others have the right
idea about letting you configure which of the 3 databases to consult in
which order.  I think that the issue should be decide not just by a file,
but also be overridable with an environment variable, but that's a nit.

Vernon Schryver
Silicon Graphics
vjs@sgi.com

I hope mentioning ARP screaming make this sufficiently relevant.

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 89 19:26:05 GMT
From:      steve@umiacs.UMD.EDU
To:        comp.protocols.tcp-ip
Subject:   Forwarding IP packets with source on net 0?


   For various ugly reasons, the question of whether or not IP packets with
their source IP address on network 0 should be forwarded has come up here.
I don't see any direct prohibition in an admittedly quick perusal of the
Hosts Requirements draft or of the Gateway Requirements RFC.  Still, I can
see reasons for going either way, and I'm curious as to what others think.

   It seems to me that net 0 means 'this network', and that packets for this
network shouldn't leave it.  Consider what happens if a forward a packet
from net 0 to some other network.  When some other host gets that packet,
it's either got to respond using the net 0 source address as the destination
address (and thus violate RFC 1009, section 4.4), or it's got to use the
information in the packet to build a different reply to another IP address.
Maybe the latter either happens in real life, or should be allowed to
happen -- I just don't know.

   Opinions?  (Polite RTFMs are more than welcome.)

   (This came up in trying to boot a Sun-2 over the net.  I can provide more
details if people are interested; I don't think this will be a problem for
99.44% of all people Out There, but since it did come up...)

	-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

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 89 22:05:29 GMT
From:      tozz@hpindda.HP.COM (Bob Tausworthe)
To:        comp.protocols.tcp-ip
Subject:   Re: line mode diffs for telnetd wanted.

/ hpindda:comp.protocols.tcp-ip / eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert) /  4:52 am  Jun 29, 1989 /
Dear netlanders.

I am looking for extensions for telnetd under (bsd) unix that
provide for line modus. I am using some real slow IP links
over which the single char modus is really unfeasable.

I have seen, that Crays version of telnetd (under unicos) provides
this feature, and switches correctly between line and single-char
modus, as the user changes from shell to vi, or vice versa.

This is exactly what I would like to have in my telnetd on
Sun, HP, Vax or any other workstation.

Does anyone know where I could find for example diffs to 
berkeleys telnetd that will do the trick ??

Toerless Eckert			E-Mail: eckert@informatik.uni-erlangen.de
University of Erlangen		        {pyramid,unido}!fauern!eckert
Lehrstuhl fuer Betriebsysteme	BITNET: tte@derrze0.bitnet
Martensstrasse 3		Phone:  +49 9131 85 7908
8520 Erlangen, W-Germany
----------

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 89 22:14:19 GMT
From:      MRC@CAC.WASHINGTON.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   re: Mail/sendmail/RFC822 Question

In <8906291656.AA03318@WLV.IMSD.CONTEL.COM>, mcc@wlv.imsd.contel.com writes:
>This is a question concerning the use of an embedded space within a recipient
>name.  RFC822 states on page 11 that the following is a legal address construct
>		"first last"@domain
>and I would assume that
>		"first last"%demesne@domain
>is also a valid construct.  The problem that I am having is that either Mail
>or sendmail complains about an unbalanced quoted string when the above construct
>is used and then attempts to deliver the message to
>		first, last%demesne@domain
>which is not the intended action.  Is this action a "feature" of the 4.3bsd
>Mail or sendmail?

You neglected to read the BNF on the final pages of RFC 822.  The string
	first last%demesne
is the local-part of an addr-spec in a mailbox.  A local part is a sequence of
one or more words delimited by "." (the stuff with "." being a word delimiter in
this case is a compromise between an ancient and now abandoned syntax in MMDF
that used period as the "%-hack" character and those folks who considered period
to be an ordinary character in a mailbox).  A word is either an atom or a quoted
string.

So, your string
	"first last"%demesne
violates this rule; it would have to be
	"first last".%demesne
but I seriously doubt if it would have the effect you desire.  Sendmail's
behavior was bizarre, but typical of Garbage In, Garbage Out compounded with
the Unix-ish syntax of space as a mailbox delimiter.

What you have to do, therefore, is quote the entire local part if you have any
special characters, that is,
	"first last%demesne"
or one of these alternates:
	\"first\ last\"%demesne
	"\"first last\"%demesne"
if you want the %-hack parser to see explicit quotes.

Note that the phrase which preceeds a broketed route-addr is simply a sequence
of words, so you could have:
	"first last"%demesne <"first last%demesne"@domain>

-- Mark --

-------

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 89 00:59:24 GMT
From:      beepy%commuter@Sun.COM (Brian Pawlowski)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   ONC/NFS Vendors' Group Papers/Presentations Sought


To:     ONC/NFS Implementors

From:   Sun Corporate Technology Marketing

Ref:    ONC/NFS Vendors' Group Conference

When:   Sept 28th, 1989

Where:  San Francisco


           Call for Presentations/Papers

Sun Microsystems is soliciting the ONC/NFS community for
presentations/papers on ONC/NFS technology. Sun is looking
for both TECHNICAL AND MARKETING presentations. If you have an
interest in presenting at the upcoming ONC/NFS Vendors' conference,
please read the following...
  
 
The Open Network Computing/ Network File System (ONC/NFS)
Vendors' Group Conference provides ONC/NFS vendors, current
and future ONC/NFS implementors and applications developers
the opportunity of exchanging information on ONC/NFS 
technology developments and market trends. 


The ONC/NFS Vendors' Group Conference is scheduled for 
September 28, 1989 in San Francisco. The one day conference 
includes sessions on ONC/NFS Technology Marketing and 
ONC/NFS Technology Engineering. 

The Technology Marketing portion focuses on marketing trends 
and issues. The intended audience is marketing and sales 
people in the ONC/NFS marketplace. This portion may address 
topics such as ONC/NFS Technology Licensing, ONC/NFS 
Technology Market Trends and ONC/NFS Technology 
Developments.

The Technology Engineering program is technically oriented 
with presentations on the state of ONC/NFS technology. 
Attendees are technically oriented - including software 
designers, and programmers who are interested in the current 
and future advancements of ONC/NFS. Examples of topics may 
be ONC/NFS on Non-UNIX Operating Systems, ONC/NFS 
Implemented on Various Network Protocols, Directory Services 
on an ONC/NFS Platform, and Distributed Applications on an 
ONC/NFS Platform. 

Participation Sought

For the ONC/NFS Technology Marketing and the ONC/NFS 
Technology Engineering sessions, the ONC/NFS Vendors' 
Group Conference seeks individuals interested in presenting 
ONC/NFS topics to the intended audience. Interested persons 
should submit a one page abstract describing their topics. Each 
paper should be typewritten and double-spaced. The ONC/NFS 
Vendor's Group Committee shall review each abstract, 
selecting abstracts based on their originality, clarity and their 
relevancy to ONC/NFS technology or the market. Submittors 
should document their background and their experience with 
ONC/NFS technology. Abstracts should be postmarked no later 
than July 17, 1989; authors of accepted topics shall be notified 
by July 31, 1989.

Speakers should limit their discussion length to a maximum of
30 minutes, and adjust their presentation depth according to 
the audience's knowledge of and experience with the topic. 
The ONC/NFS Vendors' Group Conference asks that 
speakers refrain from making product pitches as product 
promotions are generally ill-received by the audience and 
detract from the Vendors' Group Conference's intent.

Send all abstracts to:

	Jeff Hong, Product Marketing Engineer
	Sun Microsystems, Inc.
	2525 Garcia Avenue, M/S: 12-33
	Mountain View, CA 94043
	Telephone:	(415) 336-3876
	FAX: 	        (415) 968-6396
	E-mail :        jlhong@sun.com
 



			Brian Pawlowski <beepy@sun.com> <sun!beepy>
			Sun Microsystems, Portable Software Products

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 89 01:27:45 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  World record furthest telnet: Australia -> Sweden

Roy,

Well, the Navy claims that a few megawatts at a couple kiloHertz and a
few hundred kilometers of buried copper can penetrate down to submarine
operating depths. Before dimming the lights and frying people with more
megawatts and kilometers, not to mention even lower data rates, you might
consider digging a tunnel clean through the Earth. Problem with that is
it only works between selected points. A richly connected system would
require creation of a new asteriod belt to hold the tunnel tailings, but
might revolutionize the intercontinental transportation industry.

Dave

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 89 03:09:12 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  World record furthest telnet: Australia -> Sweden

Jon,

I love it. Old radio hackers perservere and prosper, even if Morse may
be dying. Can you provide address for your Rugby chimer? I would dearly
like to hunt for systematic offset across the Atlantic and maybe prize
out some telco silliness. I once personally observed a massive route
restoral for one of the TATs via INTELSAT apparently without prior warning.

Dave

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 89 03:13:16 GMT
From:      scotth@grebyn.com (Scott Hutchinson)
To:        comp.sys.ibm.pc.net,comp.dcom.lans,comp.protocols.ibm,comp.protocols.iso,comp.protocols.nsf,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.sys.proteon,comp.protocols.misc,comp.sys.ibm.pc
Subject:   Protocol/topology Poll


	I have a poll for all of you out in net land.  I am taking a
survey on what kind of local area networks people are using.  What
topology, what protocols, and what software packages.  Please reply via
mail, and I will post the results.


					-Scott Hutchinson
					 VANCE Systems Inc

-- 
                                     -Scott H. Hutchinson
Standard Disclamers:  These opinions are mine, they do not reflect on my
                      Company at all.
I can be reached at scotth@grebyn.com or grebyn!scotth

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Jul 89 09:38:46 EDT
From:      barns@gateway.mitre.org (Bill Barns)
To:        mcc@WLV.IMSD.CONTEL.COM, tcp-ip@sri-nic.arpa
Subject:   Re:  Mail/sendmail/RFC822 Question
A minor correction to one of Mark's points: for the case where you want
to force explicit quotes as part of the mailbox name (a case that I
hope you will never want!), the form
	\"first\ last\"%demesne
is not valid 822 syntax because it attempts to quote within an atom, but
	"\"first last\"%demesne"
is valid.  This is sort of explained in section 3.4.1, bottom of page
11 of RFC 822; the pseudo-BNF doesn't really convey this, although it's
not inconsistent with the text.  Unfortunately, neither the text nor the
pseudo-BNF of 822 is self-sufficient.

The battle-scarred implementor tends to avoid cleverness in using 822
features because even if you don't bungle your clever feature, the
people on the other end of the wire probably will.  Quotes (especially
those containing spaces) and route addresses are notorious troublemakers.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org
-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 89 06:28:41 GMT
From:      jos@idca.tds.PHILIPS.nl (Jos Vos)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP

Does anybody use the BSD4.3 uucpd daemon on System V.3 systems with some
TCP/IP implementation with sockets (I use Wollongong's implementation) ?

I want to use it for running UUCP (for upwards compatibility) over a
wide-area company TCP/IP network, where remote login can't be done
for security reasons.

Please mail/post experiences with:

-  The porting problems (if any) with uucpd from BDS4.3.

-  The porting problems with AT&T's V.3 uucico (I know the TCP/IP socket
   support is in the code between BSD?? #ifdef's).

-  Any other problem I overlooked...

Patches are of course appreciated :-)

-- 
-- ######   Jos Vos   ######   Internet   jos@idca.tds.philips.nl   ######
-- ######             ######   UUCP         ...!mcvax!philapd!jos   ######

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Jul 89 15:20:15 BST
From:      Robin Pickering <hplabs!inmos-c!rob@decwrl.dec.com>
To:        hp-lsd!tcp-ip@decwrl.dec.com
Subject:   Looking for references to RDP

I seem to recall hearing a reference to RDP (Reliable Datagram Protocol)
a while ago. Could anyone give me any idea about the status of this 
protocol and if possible pointers to any references. (there is no
reference to the name in the RFC index, so I assume it is reasonably
obscure)

    Thanks,
    Rob Pickering.
--
Internet:      rob%inmos-c@col.hp.com
JANET:         ROB@UK.CO.INMOS
UUCP PATH:     ...ukc!inmos!rob or ...uunet!inmos-c!rob
Voice:         +44 454 611517

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 89 18:28:19 GMT
From:      hwajin@wrswrs.wrs.com (Hwajin Bae)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP

In article <1126@ssp15.idca.tds.philips.nl> jos@idca.tds.PHILIPS.nl (Jos Vos) writes:
>Please mail/post experiences with:
>-  The porting problems (if any) with uucpd from BDS4.3.
>-  The porting problems with AT&T's V.3 uucico (I know the TCP/IP socket
>   support is in the code between BSD?? #ifdef's).
>-  Any other problem I overlooked...

HDB UUCP that comes with AT&T V.3.2 UNIX includes support for TLI, TLIS, and
socket interfaces to TCP/IP connections.  Using existing TLIS (TLI STREAMS 
Based) code, all you need is to set up listener service database to invoke
uucico when a request comes in from a remote TCP/IP host.  This is only useful
if you have another machine with TCP/IP, TLI, and equivalent UUCP.
Porting BSD 4.3 UUCP daemon has already been done several times for different 
incarnations of TCP/IP implementations for system V Unix's.  Unfortunately
none of them are "free" that I know of.

-- 
Hwa-jin Bae
hwajin@wrs.com ( a.k.a.  {uunet,rtech,sun}!wrs!hwajin )
bae@tis.llnl.gov (Internet)                                 415/832-2926
Wind River Systems, 1351 Ocean Ave, Emeryville, CA 94608    415/428-2623

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 89 18:54:02 GMT
From:      dorl@vms.macc.wisc.edu (Michael Dorl - MACC)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Terminal Server used in reverse recommendations wanted

I'm looking for recommendations for a terminal server to be used
in reverse to front end a host computer.  I'm interested in a box
with...

  a small number of lines, say about 8.

  one that has static configuration memory.

  one that translates telnet session status to/from
  rs232 signals.  A telnet session ought to cause
  DTR to come up.  A drop of DSR from the host ought 
  to terminate the telnet session.

  one that pools the rs232 under one id so that a telnet
  to the box hunts for an available rs232 port.

Any recommendations or advice welcome.

Thanks,

Michael Dorl (608) 262-0466    fax (608) 262-4679
dorl@vms.macc.wisc.edu
dorl@wiscmacc.bitnet

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 1989 23:53 EDT
From:      Peter Honeyman <honey@citi.umich.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: NFS for the mac
citi's nfs for the mac was developed by staff programmers tom unger, tim
endres, and steve fram.  tom did most of the design work and led the
programming team.  omar juma and chuck jerian also made significant
technical contributions.  i managed the effort (not well), wrote reports
(late), and helped with the design and implementation (a little).

	peter
-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 89 23:08:30 GMT
From:      davidc@umd5.umd.edu (David Conrad)
To:        comp.protocols.tcp-ip,comp.protocols.iso,comp.protocols.misc,comp.std.misc
Subject:   Printing protocols


I am looking for any documents or references to standardized printing
(or more generally object queuing) protocols.  Please mail responses
to me and I'll summarize.

Any help would be greatly appreciated...

-drc
David Conrad           Network Infrastructure Group, Computer Science Center
davidc@umd5.umd.edu  University of Maryland College Park MD 20742, 301-454-2946

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 89 01:42:47 GMT
From:      buck@drax.gsfc.nasa.gov (Loren (Buck) Buchanan)
To:        comp.protocols.tcp-ip
Subject:   SLIP for xxx machine

I received the following reply to my posting: <335@dftsrv.gsfc.nasa.gov>

|From: jbvb@vax.ftp.com (James Van Bokkelen)
|
|Commercial:
|
|Our PC/TCP package for DOS is available in a SLIP version.  Uses COM1 or
|COM2 (the built-in ports), runs at up to 19.2 Kbaud, does not come with
|dial-up support (automatic assignment of IP address to the caller when
|the call is established).
|
|cisco Systems supports SLIP on their terminal concentrator box.  They
|also re-sell PC/TCP, with a special program that works with code on the
|concentrator to assign IP addresses when a dial-up connection opens.
|
|Encore supports SLIP on their Annex terminal concentrator.
|
|Spider Systems supports SLIP on their SysV Streams TCP/IP (sold in
|source form to OEMs).
|
|Lachmann Associates (recently bought by someone) has SLIP support
|in their SysV Streams TCP/IP (OEM source form product - I don't know
|how many of their OEMs actually ship the code).
|
|TGV's VAX/VMS product supports SLIP as an option.
|
|Ultrix 3.0 includes an unsupported SLIP.
|
|SunOS includes an unsupported SLIP.
|
|Non-commercial:
|
|Rick Adams's code for 4.2 (which has evolved into 4.3 and maybe more).
|
|Phil Karn's KA9Q package for DOS (can act as an IP router, too).
|
|PC-IP for DOS (Harvard version) is said to have a SLIP driver.
|
|James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
|FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

Unfortunately I did not receive a response to the original request (I
believe it was for AIX), nor did I receive a response to my request for
the Silicon Graphics 4-D.  I have received requests for SLIP implementations
for some of the machines in listed in James' email plus request for the 
Apple Macintosh, Amiga, and Atari.

Send corrections, additions, and flames to me (I have an asbestos mailbox)
and I will post an updated compilation to the net.

Loren "Buck" Buchanan | internet: buck@drax.gsfc.nasa.gov | standard disclaimer
CSC, 1100 West St.    | uucp: ...!ames!dftsrv!drax!buck   | "By the horns of a
Laurel, MD 20707      | phonenet: (301) 497-2531 or 9898  | sky demon..."

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 89 03:53:00 GMT
From:      honey@CITI.UMICH.EDU (Peter Honeyman)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS for the mac

citi's nfs for the mac was developed by staff programmers tom unger, tim
endres, and steve fram.  tom did most of the design work and led the
programming team.  omar juma and chuck jerian also made significant
technical contributions.  i managed the effort (not well), wrote reports
(late), and helped with the design and implementation (a little).

	peter

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 89 06:20:09 GMT
From:      geoff@FERNWOOD.MPK.CA.US (the terminal of Geoff Goodfellow)
To:        comp.protocols.tcp-ip
Subject:   Cheap X.25 service for TCP-IP tunneling?

Prior to USENET in Baltimore last month I stopped in and visited the folks at 
NetExpress Communications in Vienna, VA.  NetEx offers a X.400 document 
switching service for FAX and X.25 packet switching services geared for bulk 
data transmission.  The NetExpress X.25 services seem to be priced 
substantially below other X.25 Public Data networks such as Telenet & Tymnet 
and may be a cost effective method to connect TCP-IP networks together.

	o  $.20/Kseg for US domestic transmission.
	o  $.80/Kseg for US to Europe transmission.
	o  $1.20/Kseg for US to all other countries.
	o  1 Kseg=1000 segments=64,000 bytes.
	o  1 Kseg per call minimum for US to international transmissions.
	o  $1000 per month communications minimum @ 56Kbs access.
	o  $500 per month communications minimum @ 9.6 access.

NetExpress was started by Larry Roberts and Barry Wessler.  Larry is best
known as the father of packet switching technology (i.e. the ARPANET) when
he was director of ARPA-IPTO in the late 60's and then went onto found
Telenet.  A good contact for further information at NetEx is Chris Yordy at
(703) 749-2254 voice or (703) 749-2375 FAX.

Geoff Goodfellow

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 89 09:18:25 GMT
From:      steve@CS.UCL.AC.UK (Steve Kille)
To:        comp.protocols.tcp-ip
Subject:   Re: in re:quipu as X.500 server


I suggest that we move this discussion to the <quipu@cs.ucl.ac.uk> list,
which is focussed on the issue.  This is an open list, send to
<quipu-request@cs.ucl.ac.uk> of you want to join.  If you have problems with
installing or using quipu, please send reports to
<quipu-support@cs.ucl.ac.uk>.  



 >From:  Chuck Jerian <cpj@eng.sun.com>
 >To:    tcp-ip@sri-nic.arpa
 >Subject: in re:quipu as X.500 server
 >Date:  Tue, 4 Jul 89 12:22:54 PDT
 
 >I took a large list of names, and set up the QUIPU server discussed
 >in the earlier item.  This name server used over 1K of memeory per
 >name in the list, so that to store the large list of people and machines

Right.  There is a lot of structuring info needed.  I guess that your
entries don't have much data, as we estimate an average of 2k per entry.
There is quite a bit of optimisation possible without too much effort, which
we expect to do for QUIPU 6.0.

 >that I made of everyone at Su, it used over 16M of virtual memory.
 >It seemed to reference almost 32M making this list, but freed 
 >about half of the total.  

Are you sure?  This surprises me.

 >The data is organized as a giant linked list
 >within a level of the directory.  A search of the directory using the
 >ISO search mechanism which allows for 'x*y*z' causes the server to
 >violently page trash, as it references every page of this giant list.
 >An answer is sometimes forthecoming in a minute.  The QUIPU server
 >is better behaved for small sets of names.  

This is what I would expect.  If you search the entire tree, you are going
to touch bits all over the virtual memory used.  If this can all fit into
real memory, performace is reasonable (about 1000 entries per second, for
Vaxstation II - quite a bit slower than the machine you quote).  If you step
off real memory, it thrashes (as you note).  In many cases, the X.500
Directory Information Tree hierarchy will be used to control scope of search.
We also plan to make some changes so that common searches touch less memory
(e.g., by grouping all the phone data onto adjacent memory).

 >On the other hand gnu-grep can always scan this same list of data
 >using arbitrary regular expressions which are more powerful than 
 >those in X.500 in less than .3 seconds on a Sun4/260 with the
 >data represented as a text file.

grep is a good tool, and has its applications.  However, supporting a wide
area directory is not one of them.

 >This suggests to me that the most important issue in searching nam >e
 >servers is the organization of data and the choice of algorithms,

Absolutely.   Seems like motherhood to me!

 >those in QUIPU are terrible, much worse than text files and gnu-grep.
 >					--cpj

This does not follow.   QUIPU can do a lot of things which gnu-grep can't!
Let me explain some of the philosophy behind why QUIPU was done the way it
was.  The OSI Directory (X.500) has a very rich (too rich?) framework.   
One design approach is to chooes your database, and then provide X.500
access to it.  For example, I could choose gnu-grep + single file as my
database, and then give X.500 access.  This would give stunning performance
for the things my datanbase was good at, but would fall to pieces for things
keyed the wrong way, or questions which could not be formulated.

With QUIPU, the internal (memory) structures are aligned very much to that
of the OSI directory.  This means that a query will cost about in proportion 
to the complexity of the query in X.500 terms.  This means that it will not
be stunningly good for any sort of query.  However (and more important in an
experimental implementation) it will not be stunningly bad for any sort of
query.  One of the things I'd hope to learn from the QUIPU experiment is how
one might key a database, and which are the things that need to be optimised
for under "real" usage.   




Steve

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 89 09:38:16 GMT
From:      rb@diab.se (Rune Br{nnstr|m)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.pcnet
Subject:   PD NetBIOS on TCP/IP wanted

Netland citizens!

From where can I get a public domain source for a
RFC1001/2 compliant "NetBIOS on TCP/IP" implementation.

A source targeted for a Unix box is preferred, but
anything will go. 

Please e-mail Your hints, comments, sources, etc.,
to me ASAP.

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 89 10:07:37 GMT
From:      jos@idca.tds.PHILIPS.nl (Jos Vos)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP

In article <656@wrs.wrs.com> hwajin@wrs.UUCP (Hwajin Bae) writes:

>HDB UUCP that comes with AT&T V.3.2 UNIX includes support for TLI, TLIS, and
>socket interfaces to TCP/IP connections.  Using existing TLIS (TLI STREAMS 
>Based) code, all you need is to set up listener service database to invoke
>uucico when a request comes in from a remote TCP/IP host.  This is only useful
>if you have another machine with TCP/IP, TLI, and equivalent UUCP.

The socket code is between BSD42 (or whatever) #ifdef's. Isn't it?
I know about the TCP/IP via TLI(S), but I need to be able to talk
to BSD systems too.

>Porting BSD 4.3 UUCP daemon has already been done several times for different 
>incarnations of TCP/IP implementations for system V Unix's.  Unfortunately
>none of them are "free" that I know of.

I only need the patches, I have the BSD4.3 uucpd source...

-- 
-- ######   Jos Vos   ######   Internet   jos@idca.tds.philips.nl   ######
-- ######             ######   UUCP         ...!mcvax!philapd!jos   ######

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 89 12:48:33 GMT
From:      root@neisse.UUCP (Alex Huppenthal)
To:        comp.protocols.tcp-ip
Subject:   Performance enhancements for TCP/IP wanted


Several months ago, an article was published stating that significant 
performance enhancements were being made to the TCP/IP code from Berkeley.

If you have information on this work please respond via E-mail. I will summarize
and post the results.

-Alex  

-- 
Communication Systems Research      |  This area available for witty 
6045 Buffridge Tr. Dallas, Tx 75252 |  comments
UUCP:  ..{texbell}!neisse!alex   alex%neisse.UUCP@{texbell.swbt.com} 

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 89 14:09:55 GMT
From:      konda@ZEUS.MGMT.PURDUE.EDU (Suresh Konda)
To:        comp.protocols.tcp-ip
Subject:   Membership

%msg,129

Please remove my name from the list till Aug 15.  Thank you.

Suresh Konda
konda@purccvm.bitnet
konda@midas.mgmt.purdue.edu

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 89 17:37:36 GMT
From:      anoop@guille.ece.orst.edu (Anoop R. Hegde)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   help needed on ethernet packet access on BSD4.3unix


( My apologies if this posting is not very relevant to this newsgroup,
  but i am sure, some of you have worked on a new protocol implementation)


		We have a MicroVax II running BSD4.3 UNIX. I am trying to 
	develope a new protocol parallel to IP, to be used in the 
	local ethernet environment. ( to be specific, i would like
	to write programs that can receive an ethernet packet carrying
	an experimental 'type' field, so that I can set up communication
	between this machine and any other machine connected to the same
	ethernet) Obviously, this can't be done using sockets, (even raw)
	as, they don't allow access below IP level. I would be very much 
	thankful if someone can provide me with some more info. on this 
	matter, or atleast a pointer to pursue.
		( we have the kernel source code, and it would be of much
	help if i know where is packet demultiplexing done and which files
	to look into, etc. )

--------------------------------------------------------------------------
Anoop R. Hegde			   internet: anoop@guille.ece.orst.edu
Dept. of ECE,			      UUCP :  tektronix!orstcs!hegdea
Oregon State University			or :  hplabs!hp-pcd!orstcs!hegdea
--------------------------------------------------------------------------

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 89 17:59:01 GMT
From:      "Paul_S._Lei.ElSegundo"@Xerox.COM
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Courses


Does anyone know of a course, instructor or seminar that teaches implementaion
of TCP/IP? Any help you guys can give me is appreciated. Thanks.

/Paul

PLei.ElSegundo@Xerox.COM
213-333-7985

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 89 19:01:17 GMT
From:      tim@Data-IO.COM (The Daemon's Slave)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   WD8003E and CMU-PCIP ?


  Does anyone know the tricks to get the WD8003E board to work with  the
CMU-PCIP package?  I got this package from UUNET which was in a tar file
dated "Oct 88".   Should it  work in  this version or  is there  another
newer version I  should get?   I also remember  reading something  about
having to use the "packet" driver for this board, could this be it.

  Any help would be much appreciated, Thanks.
-- 
<tim@Data-IO.COM>            ..uunet            Tim Rosmus (Sys Admin)
..sun!fluke-----------\           |               Data I/O Corporation
..uw-beaver!uw-entropy-!thebes!pilchuck!tim     10525 Willows Road N.E.
..decvax!microsoft----/                        Redmond, WA  (206)881-6444

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 89 20:01:17 GMT
From:      ehrlich@shire.cs.psu.edu (Daniel Robert Ehrlich)
To:        comp.protocols.tcp-ip,comp.mail.misc
Subject:   Re: In search of info on IBM RSCS and UREP protocols.

In article <422@cutter.nbi.com> dwm@nbires.nbi.com (Dave Maclennan) writes:

   I need to find a source for UREP - a protocol/package that I know some folks
   at the University of Pennsylvania did some work on back when.  I'm not sure 
   exactly how this interoperates with the IBM RSCS protocol, but I know they 
   can (must?) be tied together.

   Does anyone know of such a package - either commercially available or in
   Public Domain that I might be able to lay my hands on (or do you know names
   of contacts who might be useful)?  Please mail me if you do.
   -- 

   Dave W. Maclennan		
   NBI Inc., Boulder, CO		dwm@nbires.UUCP or dwm@nbires.NBI.COM
   (303) 938-2968 

Technical questions about UREP can be sent to <urep-bugs@psuvax1.cs.psu.edu>.
In any event, UREP implements the RSCS protocol as documented by IBM.

--
Dan Ehrlich <ehrlich@shire.cs.psu.edu> | Disclaimer: The opinions expressed are
The Pennsylvania State University      | my own, and should not be attributed
Department of Computer Science         | to anyone else, living or dead.
University Park, PA   16802            |

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 89 20:53:56 GMT
From:      terryl@tekcrl.LABS.TEK.COM
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: help needed on ethernet packet access on BSD4.3unix

In article <11530@orstcs.CS.ORST.EDU+ anoop@guille.ece.orst.edu (Anoop R. Hegde) writes:
+
+( My apologies if this posting is not very relevant to this newsgroup,
+  but i am sure, some of you have worked on a new protocol implementation)
+
+
+		We have a MicroVax II running BSD4.3 UNIX. I am trying to 
+	develope a new protocol parallel to IP, to be used in the 
+	local ethernet environment. ( to be specific, i would like
+	to write programs that can receive an ethernet packet carrying
+	an experimental 'type' field, so that I can set up communication
+	between this machine and any other machine connected to the same
+	ethernet) Obviously, this can't be done using sockets, (even raw)
+	as, they don't allow access below IP level. I would be very much 
+	thankful if someone can provide me with some more info. on this 
+	matter, or atleast a pointer to pursue.
+		( we have the kernel source code, and it would be of much
+	help if i know where is packet demultiplexing done and which files
+	to look into, etc. )

     Having done this exact thing quite a few years back for 4.2, the place
you need to look at is the device driver level. Specifically, you need to
look at two separate places: the output routine for the driver for packets
going out on the ethernet, and the input interrupt routine for packets coming
in from the ethernet.

     In the output routine, you key on the sa_family member of a struct
sockaddr; suffice it to say you'll have to examine the code closely to see
what I mean. In the input interrupt routine, you key on the actual ethernet
type field in the packet itself. Again, examine the code.

     For VAX stuff, look in vaxif/if_il.c (for an Interlan driver) at the
routines iloutput and ilrint for the output and input interrupt routines,
respectively.

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 89 20:54:00 GMT
From:      WONGCH@NUSDISCS.BITNET (WONG CHEE HENG)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip source for PC, 3 com Ethernet

I am looking for TCP/IP source code with the following charactheristic :

        1. run on IBM PC DOS/MS DOS in a 3com Ethernet, support all series
           of cards (3c501, 3c503, 3c505, etc.)
        2. can support multiple connections, so that network server can be
           built on top of it, i.e. has multi-tasking capability
        3. source code should be in C language, preferably in microsoft C,
           and MACRO assembly.
        4. some applications like FTP, TELNET, ect are also wanted. Furthermore
           the application that I am going to built is suppose to be a memory
           resident, non-dedicated server, so any application on TCP/IP which
           has such features will be a extremely useful guides to me to
           develop the application


Any one who has information on such source is welcome to give me his/her
advice. Pls send your replys to my bitnet address WONGCH at NUSDISCS
(WONGCH@NUSDISCS)

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Jul 89 12:54 H
From:      <WONGCH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU> (WONG CHEE HENG)
To:        tcp-ip@sri-nic.arpa
Subject:   tcp/ip source for PC, 3 com Ethernet
I am looking for TCP/IP source code with the following charactheristic :

        1. run on IBM PC DOS/MS DOS in a 3com Ethernet, support all series
           of cards (3c501, 3c503, 3c505, etc.)
        2. can support multiple connections, so that network server can be
           built on top of it, i.e. has multi-tasking capability
        3. source code should be in C language, preferably in microsoft C,
           and MACRO assembly.
        4. some applications like FTP, TELNET, ect are also wanted. Furthermore
           the application that I am going to built is suppose to be a memory
           resident, non-dedicated server, so any application on TCP/IP which
           has such features will be a extremely useful guides to me to
           develop the application


Any one who has information on such source is welcome to give me his/her
advice. Pls send your replys to my bitnet address WONGCH at NUSDISCS
(WONGCH@NUSDISCS)

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Sat, 08 Jul 89 15:54:33 EDT
From:      Nick Gimbrone <NJG@CORNELLA.cit.cornell.edu>
To:        Bob Stratton <BSTRATTO%NAS.BITNET@CORNELLC.cit.cornell.edu>, TCP-IP@SRI-NIC.ARPA
Subject:   Re: Need info on U. of Wisconsin 3798-FAL Product.
On Thu, 27 Apr 89 8:49 EDT you said:
>          Is there anyone out there from U. Wisconsin or Wiscnet who
>          can point me toward information on the 3798-FAL TCP/IP
>          implementation for VM/CMS? (That product number may not be
>          right)
>          Any information (availability, cost, accurate product name,
>          etc.) would be greatly appreciated.
The product is 5798-FAL, marketed by IBM (a LOT of work has been done
on it since it left Wisconsin). Your friendly local IBM sales person
should be able to give you more info on costs (they vary depending upon
what discounts you qualify for, under some options it is almost free :-).
I personally feel it is an excelent product, supported by a very talented
staff in IBM research. There is also a discussion list devoted to this
package and related issues (network attachment devices, etc). It is:
   IBMTCP-L@CUNYVM.CUNY.EDU
You can subscribe to the list by sending mail to:
   LISTSERV@CUNYVM.CUNY.EDU
containing the single line body of:
   SUB IBMTCP-L your name here
-njg
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 89 15:42:11 GMT
From:      brian@ucsd.EDU (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Troubleshooting routing problems

Occasionally we here at UCSD seem to suffer from connectivity problems
that I think are a result of lost routing information.  The symptoms are
that we stop being able to reach some networks or they us.

To be more specific about it, our campus Ethernet is connected via a
Proteon router to the San Diego Supercomputer Center's Ethernet and to
several other networks around California - "CERFnet".  We rarely have
trouble reaching those networks.  However, from time to time, some
networks don't seem to be reachable from our campus network, but can be
reached from machines on the SDSC Ether or from other CERFNet members.

For example, right at this moment I can't ping any machines on the
192.31.103 network where RELAY.CS.NET and its nameservers live, nor can
we ping anything on the Purdue campus.  Yet both are quite reachable
from SDSC.  The NIC was unreachable for more than a day, and we haven't
been able to get info from the UK nameservers for more than a week. 
I don't get network unreachable ICMP messages.

Our routing table consists of a few subnet entries and a default route
to the SDSC Proteon.

SDSC has recently lost their network guru, and whilst they are trying
quite hard to help, they're not quite up to speed just yet.

What I think is happening is that the reachability information for the
UCSD network isn't getting propagated as well as it might be.  I suspect
that my outgoing pings are probably reaching their destinations, but
that the return ping response can't find a route back to our network.

How can I test this from here (or elsewhere)?

	Brian Kantor	UCSD Postmaster
		UCSD Office of Academic Computing	(619) 534-6865
		UCSD C-010, La Jolla, CA 92093 USA	fax: 619 534 7018
		brian@ucsd.edu	BRIAN@UCSD ucsd!brian

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 89 19:54:33 GMT
From:      NJG@CORNELLA.CIT.CORNELL.EDU (Nick Gimbrone)
To:        comp.protocols.tcp-ip
Subject:   Re: Need info on U. of Wisconsin 3798-FAL Product.

On Thu, 27 Apr 89 8:49 EDT you said:
>          Is there anyone out there from U. Wisconsin or Wiscnet who
>          can point me toward information on the 3798-FAL TCP/IP
>          implementation for VM/CMS? (That product number may not be
>          right)
>          Any information (availability, cost, accurate product name,
>          etc.) would be greatly appreciated.
The product is 5798-FAL, marketed by IBM (a LOT of work has been done
on it since it left Wisconsin). Your friendly local IBM sales person
should be able to give you more info on costs (they vary depending upon
what discounts you qualify for, under some options it is almost free :-).
I personally feel it is an excelent product, supported by a very talented
staff in IBM research. There is also a discussion list devoted to this
package and related issues (network attachment devices, etc). It is:
   IBMTCP-L@CUNYVM.CUNY.EDU
You can subscribe to the list by sending mail to:
   LISTSERV@CUNYVM.CUNY.EDU
containing the single line body of:
   SUB IBMTCP-L your name here
-njg

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 89 21:22:42 GMT
From:      Gene.Hastings@BOOLE.ECE.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Troubleshooting routing problems

Brian, forgive me if some of what I say is old hat to you, but I feel it is
preferable to give too much information than too little.

My first caveat is to distinguish between the statements "I can't reach the
Internet." and "I can't reach this group of interesting machines." The
reason for this is that the world beyond UCSD and SDSC is not homogeneous,
and that it is possible that certain groups of networks may have a specific
point of failure (such as SRI-NIC and SIMTEL-20, neither of which are
directly connected to NSFNET, but rely on inter-backbone gateways between
NSFNET, ARPANET and MILNET). The value of this distinction is that it may
provide some hint as to the nature of the failure. 

The fact that you get no error messages back indicates that routing
announcements of your networks are not reaching the far end, and thus the
return traffic is dropped (that is, your traffic fails on the return path,
not on tha outgoing). This kind of thing is enormously hard to toubleshoot
without the aid of someone at another site, preferably the other end of the
path you're trying to troubleshoot.

What things can you do? A very powerful tool is traceroute, which has been
described here before (which is my way of admitting I can't recall all of
the pointers), and differs from the other tools in that it does not require
special authentication to use, or running a particular protocol on the
intervening routers.

Other useful tools are in the SGMP/SNMP family (you can query a routing
agent as to individual routes, or its entire routing table), which you may
be able to use depending upon the nature of your agreements with your
regional as to posession of the proper session/community names. Another
tool which provides useful information (in the absence of any other, at
least) is RIP query.) Even if you do not have personal access to the tools,
your regional NOCs should, and may be able to talk you through the tests. 

Gene

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 89 11:16:36 GMT
From:      lap@udel.EDU (Larry Pearlstein)
To:        comp.protocols.tcp-ip
Subject:   Question: Maximum speed of TCP/IP

I would appreciate any information about the maximum practical
data transfer rate using TCP/IP protocols on an unloaded, two
node Ethernet (10 Mbps) in moving large (~50 MBytes) blocks of
data between, say, two fast '386 based machines.  I saw a demo
of ftp between a 386 and fast AT using smart (Excelan) cards
which displayed a throughput of 40 KBytes/sec!  If disk access
is minimized or eliminated (perhaps just peer-peer communication
using TCP sockets) is it feasible to achieve 400 KBytes/sec?

Mail replies will be especially appreciated.

				Larry Pearlstein
				lap@huey.udel.edu

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 89 12:38:08 GMT
From:      cspencer@spdcc.COM (Cliff Spencer)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP

>>Porting BSD 4.3 UUCP daemon has already been done several times for different 
>>incarnations of TCP/IP implementations for system V Unix's.  Unfortunately
>>none of them are "free" that I know of.
>
>I only need the patches, I have the BSD4.3 uucpd source...

What's the big mystery? Doesn't the daemon just spawn /usr/lib/uucp/uucico? 

							-cliff

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 89 17:34:01 GMT
From:      grr@cbmvax.UUCP (George Robbins)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP

In article <3674@ursa-major.SPDCC.COM> cspencer@ursa-major.spdcc.COM (Cliff Spencer) writes:
> >>Porting BSD 4.3 UUCP daemon has already been done several times for different 
> >>incarnations of TCP/IP implementations for system V Unix's.  Unfortunately
> >>none of them are "free" that I know of.
> >I only need the patches, I have the BSD4.3 uucpd source...
> 
> What's the big mystery? Doesn't the daemon just spawn /usr/lib/uucp/uucico? 

Well, yes and no.  It plays with sockets doing a listen and opening a
a connection and then simulates a login and finally runs uucico passing
the open sockets as stdin/stdout.  If you have a completely functional
socket-emulation package, it shouldn't be a big deal.  Also, your uucp
is expected to know that it shouldn't try to do all those terminal
oriented ioctls on sockets...

-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 89 19:17:11 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Question: Maximum speed of TCP/IP

In article <19330@louie.udel.EDU>, lap@udel.EDU (Larry Pearlstein) writes:
> ...If disk access
> is minimized or eliminated (perhaps just peer-peer communication
> using TCP sockets) is it feasible to achieve 400 KBytes/sec?
> 				Larry Pearlstein
> 				lap@huey.udel.edu

400KBytes/sec, as measured by ttcp (doing user-process-to-user-process)
on a quiet ethernet is very slow--at least for current, fast workstations.
It does help to have user buffers >= 1KB.

Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 1989 03:07-EDT
From:      CERF@A.ISI.EDU
To:        steve@GRINCH.UMIACS.UMD.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Forwarding IP packets with source on net 0?
Steve,

It seems to me that packets with source address 0 should
NOT leak out of the net in which they originated.

Forwarding to another address on the same local net is probably
OK, although this could lead to confusion since source address of
zero means "me on this local net" and "me" would change if
the packet were forwarded...

Vint Cerf
-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 89 02:15:57 GMT
From:      mrose@cheetah.nyser.net (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: quipu as X.500 server

You raise some good issues about representations and algorithms.
Whilst I have never been a particularly big fan of the in-memory
approach used by QUIPU, let me explain why I think your comparison is
somewhat off the mark.

If the problem was scanning textual information kept in a single file on
a local disk for regular expressions, then I would simply use grep.
Your figures on grep's performance demonstrate why that is the correct
approach for that problem.

Unfortunately, that's not the problem given to the people who wrote the
Directory spec.  There were a few more constraints that had to be accommodated:

	- information must be distributed on different systems,
	  potentially geographically distant

	- information must be hierarchical in nature, primarily to
	  support autonomous control over parts of the information (of course
	  there is no explicit mapping between the hierarchy and the
	  location of the information).

	- arbitrary binary information, in addition to textual information,
	  must be accommodated; each type of data may have its own searching
	  and comparison characteristics

	- information must be updatable (add, modify, delete)

	- access to information must also support a remote comparison
	  paradigm, when the owner of the information doesn't want it to
	  leave their system (e.g., passwords)

There are probably some others, but these are the ones which jump out at
me.  Whilst grep is very good in the test case you devised, I don't
think it would work if it had to deal with these five other handicaps.
Just in passing, I'll note that five years ago, a similar argument might
have been made about the DNS--why not use grep over /etc/hosts instead
of sending queries to who-knows-where.  (Of course, I'm not comparing
the DNS and the Directory here, but it does make a rather interesting
example!)

Nonetheless, your criticism of QUIPU's in-core strategy remains.  One of
the things I am interested in studying in the pilot project is, in
practice, how much this really becomes a problem.  There is this
theory that a decent whitepages user interface exploits the hierarchy of
the naming architecture to perform more intelligent searchs, thus
reducing the exposure of this in-core business.  I myself wouldn't
structure an organization such that it had 16K users at a single
level--either in a database or in real life, so I'm interested in
finding out what the limits of this theory are.

By the way, you should note that the statement

	gnu-grep can always scan ... using arbitrary regular expressions
	which are more powerful than those in X.500

is not strictly true.  While regexps are more powerful than the modest
wildcarding facilities in the Directory, the Directory has the concept
of approximate matching, which grep does not.  In QUIPU, for example, an
approximate match of a surname data type involves applying a soundex
algorithm.  (I don't think the GNU folks have added that option to
gnu-grep ... yet!)

/mtr

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 89 07:07:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Forwarding IP packets with source on net 0?

Steve,

It seems to me that packets with source address 0 should
NOT leak out of the net in which they originated.

Forwarding to another address on the same local net is probably
OK, although this could lead to confusion since source address of
zero means "me on this local net" and "me" would change if
the packet were forwarded...

Vint Cerf

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jul 89 14:14:09 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        cca.ucsf.edu!wet!epsilon@cgl.ucsf.edu, tcp-ip@sri-nic.arpa
Subject:   Re: TCP/IP Terminal Server used in reverse recommendations wanted
Coming from a standard, Arpanet, packet-switching-among-hosts orientation,
I had a similar, negative view about milking machines.

Imagine my surprise upon disccovering that the use of such a configuration is
an integral part of an industry that has revenue in the range of $100M-$300M
per year.  (That's hundreds of millions of dollars.)

All of the concerns and criticisms that were listed in the previous
note are quite valid.

However, some machines simply do not have a version of the desired protocol
available.  Further, some operations managers want all networking to be
kept separate from the computational engine.  (While this latter issue
seems to be reduced, as host-integrated networking experience increases,
the attitude has not disappeared.)

Dave
-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 89 08:14:13 GMT
From:      epsilon@wet.UUCP (Eric P. Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Terminal Server used in reverse recommendations wanted

Yes, I have a recommendation:

  DON'T DO THIS.

16 reasons why "milking machines" are a bad idea:

- The terminal server doesn't know where "information
  boundaries" are.  It doesn't know when to push, it
  can't dynamically switch between character-at-a-time
  operation and intelligent forwarding.  Remote echo performance
  suffers, or you generate a lot of unnecessary network traffic,
  or both.  Local echoing is probably not a viable option.
- Most telnet implementations do not negotiate baud rate
  information.  Mismatches cause problems.  Then again, who said
  the user side was a "real terminal" anyway?
- You lose all useful telnet subnegotiation capability.
- Unless you have hardware handshake, you tend to have
  transparency problems.
- You might not be able to send BREAKs in both directions.
- You may have flow control problems.
- Interrupt characters don't take effect promptly.
- It's difficult to do flushes.
- You can't do reliable timed inputs.
- The host machine doesn't get address information, making
  intrusion tracing difficult.
- You only get telnet access, and possibly only incoming.
- You are limiting yourself to a small, fixed number of
  sessions.
- It costs more to do it this way--you are paying for two
  unnecessary serial interfaces per line.
- On many machines serial I/O has significantly higher overhead
  than network service.
- What happens if you get a "zombie line" on your host?  Will
  incoming connections consistently hunt to the loser?
- More intervening hardware => lower reliability => more downtime
  => higher maintenance costs
					-=EPS=-

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 89 08:31:00 GMT
From:      ECSYIP@NTIVAX.BITNET
To:        comp.protocols.tcp-ip
Subject:   help

help

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jul 89 12:33:38 EDT
From:      Root Boy Jim <rbj@dsys.ncsl.nist.gov>
To:        tcp-ip@sri-nic.arpa
Cc:        phri!roy@rutgers.edu
Subject:   Domain Name Screaming
? From: <mar@ATHENA.MIT.EDU>
? Date: Wed, 5 Jul 89 11:33:36 -0400

?    Date: 4 Jul 89 13:42:16 GMT
?    From: phri!roy@rutgers.edu  (Roy Smith)

? 	   Besides, for all it's grossness (and there is plenty) YP still
?    provides a reasonably convenient way to share files with local additions.
?    For example, all our suns share /etc/printcap using YP.  Every machine that
?    has direct control of a printer has a local /etc/printcap for that printer.
?    The printcap parsing routines were written to read the local file first and
?    only go to YP if the name can't be resolved there.  Show me a way to do
?    that that's easier than YP.

? But we do the exact same thing here at Athena using our Hesiod name
? service.  Hesiod is a set of simple library routines layered over BIND
? that give us the ability to lookup account information, access groups,
? filesystems, printers, etc.  We have the flexibility of the DNS, and
? only one kind of database to maintain for hosts and other information.
? We find that it's faster to look up something though Hesiod than
? scanning a local text file, even if it's not already in the local
? named cache.
? 					-Mark Rosenstein

Use rdist to distribute the common network part. Maintain the local
entry separately. Use the special command to cat the two together.

rdist - << EOF
( /etc/printcap.net ) -> ( remote.host )
	special /etc/printcap.net
		"cat /etc/printcap.local /etc/printcap.net > /etc/printcap" ;
EOF

	Root Boy Jim is what I am
	Are you what you are or what?
-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 89 16:41:21 GMT
From:      paul@taniwha.UUCP (Paul Campbell)
To:        comp.protocols.tcp-ip
Subject:   Re:  World record furthest telnet: Australia -> Sweden

In article <8907052309.aa07519@huey.udel.edu> Mills@UDEL.EDU writes:
>I love it. Old radio hackers perservere and prosper, even if Morse may
>be dying. Can you provide address for your Rugby chimer? I would dearly

Which brings up a whole new concept in "'World's record furthest Telnet":

	Moon Bounce



	Paul (ex ZL4TFW)

-- 
Paul Campbell    UUCP: ..!mtxinu!taniwha!paul     AppleLink: D3213
"Free Market": n. (colloq.) a primitive fertility goddess worshipped by an
obscure cult in the late 20th C. It's chief priest 'Dow Jones' was eventually
lynched by an enraged populace during an economic downturn (early 21st C).

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 89 16:59:53 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Troubleshooting routing problems

In article <1823@ucsd.EDU> brian@ucsd.EDU (Brian Kantor) writes:
>Occasionally we here at UCSD seem to suffer from connectivity problems
>that I think are a result of lost routing information.  The symptoms are
>that we stop being able to reach some networks or they us.
>[...]
>What I think is happening is that the reachability information for the
>UCSD network isn't getting propagated as well as it might be.  I suspect
>that my outgoing pings are probably reaching their destinations, but
>that the return ping response can't find a route back to our network.
>
>How can I test this from here (or elsewhere)?

	I think you are right.	It is hard for you to troubleshoot
this yourself.  You need help.  The SDSCnet people should be able to
deal with these things in response to mail from you as the campus
representative, exactly like you posted to tcp-ip.  Let SDSCnet or
CERFnet have another shot at solving your problem for you.

	As a local user, you should be able to ask your campus network
manager (perhaps that is you) who can call on the regional network
operations people who can call on MERIT, the backbone network people.
MERIT has the tools and techniques to solve these problems, but they
need to limit their interaction to the regional technical people.
There are too many people on the net for them to work with everyone
directly.

	In the case of Purdue and CSnet, they were once well served by
arpanet, and since the arpanet has evaporated very rapidly, many
organizations are scrambling to migrate to new network services, and
that means the NSF-Internet.

	Right now, connectivity to many organizations and for many
internetwork connections still takes place using default routes.
Default routes tend to break when widespread connectivity changes are
made, like taking down the arpanet.  The most common default is still
the good ol' arpanet, and many a slip twixt Hither and Yon on that old
caravan route.

	(I don't find any purdue nets or the cs.net in routing
information from the backbone via jvncnet.  It could be temporary, but
I think not.  My default routing still works.  Lucky for me, they can
find my in their defaults.)

	--Kent England

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 89 17:19:00 GMT
From:      ljm@TWG.COM (Leo J McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   Re: Question: Maximum speed of TCP/IP


Larry,

>I would appreciate any information about the maximum practical
>data transfer rate using TCP/IP protocols on an unloaded, two
>node Ethernet (10 Mbps) in moving large (~50 MBytes) blocks of
>data between, say, two fast '386 based machines.  I saw a demo
>of ftp between a 386 and fast AT using smart (Excelan) cards
>which displayed a throughput of 40 KBytes/sec!  If disk access
>is minimized or eliminated (perhaps just peer-peer communication
>using TCP sockets) is it feasible to achieve 400 KBytes/sec?

For '386 machines 400KBytes/sec peer to peer is very slow.  Even
without implementing TCP header prediction our FTP transfer speeds
are in the 330KBytes/sec range (with a dumb 3c503).  One thing to
bear in mind is that with smart boards the host's processor doesn't
get to do any of the protocol work -- a performance hit if the host's
processor is significantly faster than the board's.

If you are implementing or modifying a TCP/IP protocol stack and are
concerned about performance there are a few quick things you should 
be looking at.  Make sure your checksum routine is unrolled and your
algorithm is fast.  Negotiate a large MSS when on the same network.
Make sure your TCP flow control mechanisms allow applications to keep
the data pipe full.  And, in general, make sure reciept or tranmission
of the next segment in an open connection happens as quickly as possible.

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

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 89 18:03:59 GMT
From:      konda@ZEUS.MGMT.PURDUE.EDU (Suresh Konda)
To:        comp.protocols.tcp-ip
Subject:   List

%msg,64

Please remove my name from the group till Aug 16th.  Thanks.

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 89 19:31:56 GMT
From:      brian@ucsd.EDU (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Re: Troubleshooting routing problems

Well, we found the problem - seems one of the intermediate routers had a
default route pointing to a machine which no longer exists and which
used to be that site's Arpanet gateway.  Once that was fixed things
started to flow again.

Thanks all for your suggestions; they did help us!

	Brian Kantor	UCSD Office of Academic Computing
			Academic Network Operations Group  
			UCSD C-010, La Jolla, CA 92093 USA
			brian@ucsd.edu ucsd!brian BRIAN@UCSD

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 89 20:13:27 GMT
From:      grr@cbmvax.UUCP (George Robbins)
To:        comp.protocols.tcp-ip
Subject:   regional network for PA area?

Can anyone provide me with contact information for whatever
regional network provides NFSnet/Internet access in the
Philadelphia PA area?  I tried to query the mail server that
was mentioned here, but only got a black hole simulation...

-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 89 21:14:09 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Terminal Server used in reverse recommendations wanted

Coming from a standard, Arpanet, packet-switching-among-hosts orientation,
I had a similar, negative view about milking machines.

Imagine my surprise upon disccovering that the use of such a configuration is
an integral part of an industry that has revenue in the range of $100M-$300M
per year.  (That's hundreds of millions of dollars.)

All of the concerns and criticisms that were listed in the previous
note are quite valid.

However, some machines simply do not have a version of the desired protocol
available.  Further, some operations managers want all networking to be
kept separate from the computational engine.  (While this latter issue
seems to be reduced, as host-integrated networking experience increases,
the attitude has not disappeared.)

Dave

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 89 21:38:55 GMT
From:      carlosp@CSUFRES.CSUFRESNO.EDU (Carlos Perez)
To:        comp.protocols.tcp-ip
Subject:   (none)

Has anybody out there managed to have the YP and the INET nameserver
working together?. I tried 'makedbm -b' but it does not seem to be 
working fine. I also wonder how to link 'rlogin, telnet, ftp',etc. to 
the resolver library and stop using the YP server. I'm running Sun OS 
4.0.1 on a 3/260. The 3/260 has to act as a file server (NFS) for a set
of 386's running PC-NFS. I do not have any source code. How difficult is it
to port telnet, ftp, rlogin, etc. from BSD4.3 to Sun OS 4.0.1?. Has anybody
done it?. Any info (or pointer) on the above subjects will be appreciated.
Please reply to my address. If there is enough information, I'll summarize 
and post to the list.

Thank you.

Carlos Perez
California State University Fresno
Computer Services
(209) 294-4253

carlosp@csufres.CSUFresno.EDU
carlos@deervax.concordia.ca

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 89 22:01:18 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Terminal Server used in reverse recommendations wanted

I agree completely about not using milking machines.  The
configuration is a pain and the neck, and results normally aren't as
good as buying TCP/IP software for the host.  However sometimes there
is no choice.  E.g. we have an HP 3000.  Its TCP/IP is bad enough that
we can't depend upon it for our terminal access.  I would guess that
there are a number of other vendors whose systems either don't have
TCP or where for one reason or another it is not feasible to use their
implementation.  Actually most of our milking machine ports are on an
IBM-compatible mainframe.  Good TCP/IP is now available for them, but
there are technical reasons why some of the subsystem on our machine
need to be accessed via real serial ports.

So I agree that it's not something I'm anxious to do.  But there are
enough cases where we have to that I've put some time into making
milking machine service work as well as possible.  This is on our
cisco terminal servers.  (I believe that cisco supports most of these
features now, though probably not the ability to pad breaks.)  Here
are some of the things that can be done to deal with some of the
problems that Eric mentions:

  - The terminal server doesn't know where "information
    boundaries" are.

In general you have to run milking machine configurations in character
at a time mode.  Until the new "line mode telnet" is widely
implemented, host implementations won't be much better.

  - Most telnet implementations do not negotiate baud rate
    information.  Mismatches cause problems.  Then again, who said
    the user side was a "real terminal" anyway?

You'll notice a relatively new telnet option for sending terminal
speed.  We did this specifically for milking machines.  Our terminal
servers now have an option that causes them to switch the baud rate to
match the other end.  We had to do that because one system we were
front-ending couldn't do flow control.  The usual strategy is to run
the milking machine ports at the highest speed used by the host and
depend upon flow control.  However if you match the speed of the
connection and you have big enough buffers, it is possible to operate
without any flow control.

   - Unless you have hardware handshake, you tend to have
     transparency problems.
   - You may have flow control problems.

Absolutely.  It takes a lot of work on both the host's comm gear and
the terminal server to make things work transparently.  This is not
for the faint of heart.

  - You might not be able to send BREAKs in both directions.

And then again you might.  We have no problem sending breaks, although
on one host that causes them to drop the next character after a break.
We had to implement an option in the terminal server that "pads"
breaks.  I.e. we follow each break with a null.

   - Interrupt characters don't take effect promptly.
   - It's difficult to do flushes.

We added an option that allows the terminal server to flush.  When it
sees a break it not only sends it to the host but does a flush and
telnet sync.  I think we only support breaks, but it would be easy
enough to generalize it to recognize any character.  The problem would
be that if you tried to use it for something like Unix or VMS, you'd
have no way of knowing whether the user had changed his break
character or was in Emacs.  But the systems we're front ending don't
have such fancy terminal handling.  So break is enough.

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 89 02:51:20 GMT
From:      brian@ucsd.EDU (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Routing loop, congestion, or what?

The U.K. became unreachable again late this afternoon, and in the
process of poking around to see what I could see, I got this strange
result back from traceroute.

It seems to me that either a routing loop or severe congestion might
cause this effect.  I'm not quite sure what I'm seeing here, and I'm
really rather curious!  Ideas?

	Brian Kantor	UCSD Office of Academic Computing
			Academic Network Operations Group  
			brian@ucsd.edu ucsd!brian BRIAN@UCSD

Script started on Mon Jul 10 19:39:33 1989 PDT
[ucsd] 1 : traceroute nsfnet-relay.ac.uk
traceroute to nsfnet-relay.ac.uk (128.86.8.6), 30 hops max, 40 byte packets
 1  ucsd-sdsc-gw (128.54.16.9)  19 ms  16 ms  17 ms
 2  129.140.77.6 (129.140.77.6)  61 ms  55 ms  74 ms
 3  129.140.79.13 (129.140.79.13)  151 ms  130 ms  134 ms
 4  129.140.81.15 (129.140.81.15)  183 ms  181 ms  177 ms
 5  129.140.72.17 (129.140.72.17)  218 ms  223 ms  216 ms
 6  * * *
 7  ford-gateway.jvnc.net (128.121.54.73)  250 ms  257 ms  236 ms
 8  zaphod-gateway.jvnc.net (128.121.50.72)  237 ms  615 ms  233 ms
 9  fenchurch-gateway.jvnc.net (128.121.54.78)  246 ms  256 ms  239 ms
10  ford-gateway.jvnc.net (128.121.54.73)  246 ms  261 ms  241 ms
11  zaphod-gateway.jvnc.net (128.121.50.72)  242 ms  1153 ms  337 ms
12  fenchurch-gateway.jvnc.net (128.121.54.78)  271 ms  254 ms  324 ms
13  ford-gateway.jvnc.net (128.121.54.73)  276 ms  268 ms  249 ms
14  zaphod-gateway.jvnc.net (128.121.50.72)  565 ms  316 ms  299 ms
15  fenchurch-gateway.jvnc.net (128.121.54.78)  538 ms  282 ms  254 ms
16  ford-gateway.jvnc.net (128.121.54.73)  250 ms  486 ms  998 ms
17  zaphod-gateway.jvnc.net (128.121.50.72)  310 ms  612 ms  290 ms
18  fenchurch-gateway.jvnc.net (128.121.54.78)  276 ms  262 ms  299 ms
19  ford-gateway.jvnc.net (128.121.54.73)  278 ms  1627 ms  788 ms
20  zaphod-gateway.jvnc.net (128.121.50.72)  1168 ms  1523 ms  1810 ms
21  fenchurch-gateway.jvnc.net (128.121.54.78)  919 ms  846 ms  278 ms
22  ford-gateway.jvnc.net (128.121.54.73)  1962 ms  268 ms  331 ms
23  zaphod-gateway.jvnc.net (128.121.50.72)  287 ms  292 ms  305 ms
24  fenchurch-gateway.jvnc.net (128.121.54.78)  660 ms  283 ms  281 ms
25  ford-gateway.jvnc.net (128.121.54.73)  310 ms  288 ms  825 ms
26  zaphod-gateway.jvnc.net (128.121.50.72)  593 ms  545 ms  777 ms
27  fenchurch-gateway.jvnc.net (128.121.54.78)  301 ms  287 ms  312 ms
28  ford-gateway.jvnc.net (128.121.54.73)  414 ms  368 ms  313 ms
29  zaphod-gateway.jvnc.net (128.121.50.72)  688 ms  283 ms  298 ms
30  fenchurch-gateway.jvnc.net (128.121.54.78)  280 ms  296 ms  328 ms
[ucsd] 2 : exit
[ucsd] 3 : 
script done on Mon Jul 10 19:40:59 1989

(BTW: our nameserver seems to be unable to find names for the 129.140
hosts in these paths; is no one in the DNS providing those PTRs?)

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 89 04:27:03 GMT
From:      vixie@decwrl.dec.com (Paul Vixie)
To:        comp.protocols.tcp-ip
Subject:   relative importance

Here I am again, using comp.protocols.tcp-ip as a news distribution medium
because I happen to know that everyone I want to reach happens to read this
list.

Decwrl and Gatekeeper have moved from 128.45.9.1/128.45.9.52 to
16.1.0.1/16.1.0.2.  The core name servers don't know this yet (all I can do
is ask the NIC, right?)  and the old addresses are cached in a lot of places.

If all the important name servers in the world were restarted, it would make
Decwrl/Gatekeeper a whole lot easier to reach :-).

Paul Vixie
DEC WRL
-- 
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 89 13:54:38 GMT
From:      n2dsy@cbnewsh.ATT.COM (j.gordon.beattie)
To:        comp.protocols.tcp-ip,comp.protocols.iso,rec.ham-radio.packet
Subject:   Internet Domain - How it fits in globally




I am no internet domain expert, but I seem to recall that ".COM", ".EDU",
".GOV", ".MIL", ".ORG", ".US", etc. are all domains within the
Internet domain.  The Internet is a subdomain of the US DoD.

The next step is a bit unclear to me...is it "ORG" followed by "ISO" 
as the last step in the hierarchy? This would yield a complete 
string of: 

"host.city.state.us.internet.dod.org.iso".

Can someone confirm/deny this?

I base this on the recollection that the DoD has one of 
two domain  IDs given to the US by ISO from its branch "Identified
Organizations".  

A few years ago we obtained such a domain ID from ISO
for "Amateur Radio OSI" and we have broken it down by both
geographical and organizational lines as was done by the internet
folks.  We have a few different branches, which are described 
elsewhere, but I was somewhat curious how the internet handles
domains on other branches of the global domain tree.
The picture shown below illustrates my understanding, 
could someone comment on this?


                              iso(1)
   /------------------/-------/ \---------\---------------------\
  /                  /                      \                     \
...                 DCC(?)     Identified Organizations(3)        ....
                                       /
      /-------------/-----------/----/-----------------------\
    /             /           /                                \
  ...           dod(5)     nbs(6)     ....       Amateur Radio OSI(11)
                  /                                  
            internet(1)
         /------/------\------\-------- etc.
        /      /         \      \
      ORG     GOV        US     MIL






Thanks,

J. Gordon Beattie, Jr.
201-615-4168 (O)
201-387=8896 (H)

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 89 14:25:14 GMT
From:      pkulik@emdeng.Dayton.NCR.COM (Peter.J.Kulik)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   TCP/IP Products for the PC

Hi,

I'm doing a survey of TCP/IP and NETBIOS over TCP/IP products for the PC.
Any information you could provide about current or future products would
be greatly appreciated.  I'm most interested in manufacturer or distributer
names and product names, as well as any comments or recommendations (or
complaints!).

Please post directly to me.  I'll summarize if there's enough interest.
Thanks in advance,

Peter Kulik


Standard disclaimer.

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 89 15:02:58 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  DECWRL/GATEKEEPER  DEC.COM.

> Decwrl and Gatekeeper have moved from 128.45.9.1/128.45.9.52 to
> 16.1.0.1/16.1.0.2. 
 
I take it this was a spur of the moment decision and normal mechanisms
like decrementing the ttl sometime prior to the change were not employed?

Anyhow, as seen from here dec nameservers on net 128.45 are not accessable.
Also, there appears to be an inconsistent view of dec.com as seen from
dec.com.  16.1.0.1 and 36.22.0.10 look the same but 16.1.0.2 shows a
different set of nameservers and names one of which is not reachable.

> server 16.1.0.1
Default Server:  [16.1.0.1]
Address:  16.1.0.1

> set q=ns
> dec.com.
Server:  [16.1.0.1]
Address:  16.1.0.1

dec.com	nameserver = gatekeeper.pa.dec.com
dec.com	nameserver = decwrl.pa.dec.com
dec.com	nameserver = cybele.pa.dec.com
gatekeeper.pa.dec.com	inet address = 16.1.0.2
cybele.pa.dec.com	inet address = 36.22.0.10
> server 16.1.0.2
Default Server:  [16.1.0.2]
Address:  16.1.0.2

> dec.com.
Server:  [16.1.0.2]
Address:  16.1.0.2

dec.com	nameserver = gatekeeper.dec.com
dec.com	nameserver = decwrl.dec.com
dec.com	nameserver = cybele.dec.com
decwrl.dec.com	inet address = 128.45.9.1
decwrl.dec.com	inet address = 16.1.240.1
> server 36.22.0.10
Default Server:  [36.22.0.10]
Address:  36.22.0.10

> dec.com.
Server:  [36.22.0.10]
Address:  36.22.0.10

dec.com	nameserver = gatekeeper.pa.dec.com
dec.com	nameserver = decwrl.pa.dec.com
dec.com	nameserver = cybele.pa.dec.com
gatekeeper.pa.dec.com	inet address = 16.1.0.2
cybele.pa.dec.com	inet address = 36.22.0.10
> 

Also, addresses for names are different from the different servers.
Check out the address for decwrl.dec.com from 16.1.0.2


> server 16.1.0.2
Default Server:  [16.1.0.2]
Address:  16.1.0.2

> set q=a
> gatekeeper.dec.com.
Server:  [16.1.0.2]
Address:  16.1.0.2

Name:    gatekeeper.dec.com

> decwrl.dec.com.
Server:  [16.1.0.2]
Address:  16.1.0.2

Name:    decwrl.dec.com
Addresses:  128.45.9.1, 16.1.240.1

> cybele.dec.com.
Server:  [16.1.0.2]
Address:  16.1.0.2

Name:    cybele.dec.com


> server 16.1.0.1
Default Server:  [16.1.0.1]
Address:  16.1.0.1

> gatekeeper.dec.com
Server:  [16.1.0.1]
Address:  16.1.0.1

Name:    gatekeeper.pa.dec.com
Address:  16.1.0.2
Aliases:  gatekeeper.dec.com

> decwrl.dec.com
Server:  [16.1.0.1]
Address:  16.1.0.1

Name:    decwrl.dec.com
Addresses:  16.1.0.1, 16.1.240.1

> cybele.dec.com.
Server:  [16.1.0.1]
Address:  16.1.0.1

Name:    cybele.pa.dec.com
Address:  36.22.0.10
Aliases:  cybele.dec.com

> server 36.22.0.10
Default Server:  [36.22.0.10]
Address:  36.22.0.10

> gatekeeper.dec.com
Server:  [36.22.0.10]
Address:  36.22.0.10

Name:    gatekeeper.pa.dec.com
Address:  16.1.0.2
Aliases:  gatekeeper.dec.com

> decwrl.dec.com.
Server:  [36.22.0.10]
Address:  36.22.0.10

Name:    decwrl.dec.com
Addresses:  16.1.0.1, 16.1.240.1

> cybele.dec.com.
Server:  [36.22.0.10]
Address:  36.22.0.10

Name:    cybele.pa.dec.com
Address:  36.22.0.10
Aliases:  cybele.dec.com

> 

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 89 17:26:41 GMT
From:      manglik@bgsuvax.UUCP (Pankaj Manglik)
To:        comp.protocols.tcp-ip
Subject:   Membership

Hi. I am a new reader of this newsgroup. Please add my name to the mailing list.

Pankaj Manglik

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 89 18:18:29 GMT
From:      burdick@hpindda.HP.COM (Matt Burdick)
To:        comp.protocols.tcp-ip
Subject:   Re: SysV tn3270 sources needed

> I am sorry to post this here but I have been attempting to e-mail Mr.
> Merritt at the iris government machine with no luck
 
> If you are out there listening, I have been trying to email you in
> regards your response on the SysV tn3270 sources.

I've also tried to contact Mr. Merritt via email and have gotten bounced
mail back.

I have a copy of tn3270 for HPUX.  In compressed tar format, it is 541121
bytes long.  Therefore, it is a little difficult to mail it to you.  If you
have a location that I can ftp anonymously to and deposit it, please let me
know.

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

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 89 18:48:42 GMT
From:      dorl@vms.macc.wisc.edu (Michael Dorl - MACC)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for Prime PRIMOS Machines

We have a couple of Prime machines that want to join the campus
IP network.  They run PRIMOS.  Prime tells us we need LHC-300
Ethernet controllers, TCP/IP software, and a mail user agent such
as PDN Mail from Prime Custom Systems.

I'd like to hear from anyone using or knowledgable about this 
hardware and software.  How well does it work?  What alternatives
exist?

What facilities are provided? 

 telnet client?  server?

 ftp client?  server?

 smtp client?  server?

 ping client?  ping server?

 unix r commands?

 news support?

 snmp support?

 routed?

Any advice or comments appreciated.

Thanks, 

Michael Dorl (608) 262-0466    fax (608) 262-4679
dorl@vms.macc.wisc.edu
dorl@wiscmacc.bitnet

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 89 19:31:21 GMT
From:      Gene.Hastings@BOOLE.ECE.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: regional network for PA area?

PREPnet, the Pennsylvania Research and Economic Partnership Network at
412-268-7870.

The director is Tom Bajzek, twb+@andrew.cmu.edu.

There are currently hubs in Philadelphia and Pittsburgh, with tail circuits
to assorted points across the state.

Gene

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jul 89 07:57:29 -0700
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        barns@gateway.mitre.org, mcc@WLV.IMSD.CONTEL.COM, tcp-ip@sri-nic.arpa
Cc:        LARSON@KL.SRI.COM, MRC@CAC.Washington.EDU, dcrocker@ahwahnee.Stanford.EDU, hubcap@hubcap.clemson.edu, jas@proteon.com
Subject:   Re:  Mail/sendmail/RFC822 Question
First, I would like to thank those that responded to my Mail/sendmail/RFC822
query.  Given the existing RFC822 address syntax rules, everyone pointed out
that

                "first last"%demesne@domain

should be

                "first last%demesne"@domain

Unfortunately, the latter produces the same error unless the embedded space is
explicitly quoted with a "\".  The problem is in the parsing performed in Mail
needed to support a space separated rather than comma separated list of
addressees.

As our sendmail has been configured for demesne addressing (%-hack) either of
the above forms is acceptable to sendmail.  [I think that demesne sounds better
than %-hack and is more appropriate in the sense of lands ((sub-)network)
granted to or retained by a feudal lord to administer as he wishes.]  In our
local environment, mail which specifies the ELIS demesne "%ELIS" is passed to a
mail gateway for ELIS which is responsible for routing the mail to the specific
system on which the addressee has an account.  This mechanism allows users to
be moved, readily, from system to system due to changes in jobs or equipment
failure (unfortunately a too frequent problem on the ELIS systems) without
impacting mail to and from the Internet.

The unpublished (still?) host requirements RFC suggests that demesne address-
ing should be used as an alternative to the current source routing mechanism.
This implies that the "%" is to be added to the list of special characters and
implies that the quoting used in the first of the above addresses is correct.

Based on the responses that I received and, of course, re-reading the RFC;
there appears to be some problems or inconsistencies in the RFC between the
text and the BNF.  The common problem was to misuse the term "atom" when
discussing an address--addresses are comprised of "word"s not "atom"s.  Of
course that statement is only valid if one assumes that the BNF is the correct
definition of the syntax and that the text is only there to clarify the BNF.

In the discussion on domain-dependent local strings (pp 30,31), the RFC does
identify another solution for space separated mailbox names which is to use
a "." in place of the space.  The problem with quoting address information
came about when I attempted to send a mail item to our site's Digital Account
Representative.  It seems that account rep's while they have VMS Mail accounts
prefer to use their ALL-IN-ONE mail.  ALL-IN-ONE mail addresses are in the
form:

                First Last@office

and can be accessed from VMS Mail by the following:

                MTS$::"First Last@Office"

Normal semantics for sending mail from the Internet to VMS Mail through the
decwrl gateway is to use the following:

        user%node.DEC@decwrl.DEC.COM  or  user@node.decwrl.DEC.COM

The latter instance is for sites which understand MX records.  Which led
to several attempts on my part to get a quoted string to node MTS$ which
of course was wrong and introduced the problems with the embedded space.
The correct syntax is

        First.Last%office.MTS@decwrl.DEC.COM

During the sendmail parsing of the address, the "%" will be replaced by an
"@" and the following tokens will be defined

        "First" "Last" "@" "office" "MTS"

At which point MTS (Mail Tranlation Service) has the "First Last@office"
needed to route the mail item.

Anyway, thanks for your responses again.

Merton

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 89 03:05:45 GMT
From:      brad@cayman.COM (Brad Parker)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   CRC calc for Ethernet; How?

I need a simple way to calculate the CRC used in Ethernet packets.
This is (from what I can see) using the "AUTODON II" polynomial.

I found some nice pictures in the Ethernet spec blue book, but
they assume a bit stream (and seem easy to implement if you are
doing VLSI, but not C code!)

Anyone have a hints for a some way to do this in C? I do not need
speed, just a correct algorithm. I assume there are some tricks
which can be exploited for 8 or 16 (or even 32) bit computation
machines.

thanks
-brad
-- 

Brad Parker
Cayman Systems, Inc.		Cambridge, Ma.			brad@cayman.com

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 89 13:55:54 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Mail/sendmail/RFC822 Question

First, I would like to thank those that responded to my Mail/sendmail/RFC822
query.  Given the existing RFC822 address syntax rules, everyone pointed out
that

                "first last"%demesne@domain

should be

                "first last%demesne"@domain

Unfortunately, the latter produces the same error unless the embedded space is
explicitly quoted with a "\".  The problem is in the parsing performed in Mail
needed to support a space separated rather than comma separated list of
addressees.

As our sendmail has been configured for demesne addressing (%-hack) either of
the above forms is acceptable to sendmail.  [I think that demesne sounds better
than %-hack and is more appropriate in the sense of lands ((sub-)network)
granted to or retained by a feudal lord to administer as he wishes.]  In our
local environment, mail which specifies the ELIS demesne "%ELIS" is passed to a
mail gateway for ELIS which is responsible for routing the mail to the specific
system on which the addressee has an account.  This mechanism allows users to
be moved, readily, from system to system due to changes in jobs or equipment
failure (unfortunately a too frequent problem on the ELIS systems) without
impacting mail to and from the Internet.

The unpublished (still?) host requirements RFC suggests that demesne address-
ing should be used as an alternative to the current source routing mechanism.
This implies that the "%" is to be added to the list of special characters and
implies that the quoting used in the first of the above addresses is correct.

Based on the responses that I received and, of course, re-reading the RFC;
there appears to be some problems or inconsistencies in the RFC between the
text and the BNF.  The common problem was to misuse the term "atom" when
discussing an address--addresses are comprised of "word"s not "atom"s.  Of
course that statement is only valid if one assumes that the BNF is the correct
definition of the syntax and that the text is only there to clarify the BNF.

In the discussion on domain-dependent local strings (pp 30,31), the RFC does
identify another solution for space separated mailbox names which is to use
a "." in place of the space.  The problem with quoting address information
came about when I attempted to send a mail item to our site's Digital Account
Representative.  It seems that account rep's while they have VMS Mail accounts
prefer to use their ALL-IN-ONE mail.  ALL-IN-ONE mail addresses are in the
form:

                First Last@office

and can be accessed from VMS Mail by the following:

                MTS$::"First Last@Office"

Normal semantics for sending mail from the Internet to VMS Mail through the
decwrl gateway is to use the following:

        user%node.DEC@decwrl.DEC.COM  or  user@node.decwrl.DEC.COM

The latter instance is for sites which understand MX records.  Which led
to several attempts on my part to get a quoted string to node MTS$ which
of course was wrong and introduced the problems with the embedded space.
The correct syntax is

        First.Last%office.MTS@decwrl.DEC.COM

During the sendmail parsing of the address, the "%" will be replaced by an
"@" and the following tokens will be defined

        "First" "Last" "@" "office" "MTS"

At which point MTS (Mail Tranlation Service) has the "First Last@office"
needed to route the mail item.

Anyway, thanks for your responses again.

Merton

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 89 14:10:24 GMT
From:      adoyle@bbn.com (Allan Doyle)
To:        comp.protocols.tcp-ip,comp.realtime
Subject:   Summary: Need TCP/IP to run under PSOS

I recently posted an inquiry on the net:

> I'm looking for an implementation of TCP/IP that I can run on a Motorola
> MVME-147 board under pSOS.
> 
> The MVME 147 has the LANCE chipset, and a 68030 CPU. pSOS is a real-time
> kernel. Any code that I can bash into submission is welcome. It does
> not have to fit the 147 board and pSOS like a glove but the closer the
> better :-)

Here is a summary of what I've been able to find:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

At Spider we have written a TCP (and X.25, by the way)which runs in Unix
V.3 streams.  We have also written a 'clean' (no AT&T code) version of
streams as a 'stand-alone' package.  This has enabled us to port it to a
variety of simple exec's, and from what I know of pSOS, the job should
take very little time indeed.

Nick Felisiak				nick@spider.co.uk
Spider Systems Ltd			+44 31 554 9424
Stanwell Street
Edinburgh
EH6 5JQ

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

VxWorks can run with VRTX, pSOS or our own kernel (Wind), and is
available for a wide range of VME based 680x0 targets.

Nigel  Standing

Wind River Systems Technical Support

e-mail: support@wrs.com

[[Another response said try inquiries@wrs.COM (sun!wrs!inquiries)]]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Berkeley more-or-less gives away what is may be the
highest quality TCP/IP implementation. The contact there
is Claire LeDonne (415) 643-7201. Terms are liberal. It is
of course designed to work with 4.3BSD, but is said to be
easy to port.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you are willing to try something different from pSOS, you might want to try
the OS-9 Operating system from Microware Systems Corporation.  They have a
very nice TCP/IP implementation with a Berkeley-style socket interface and
the TCP is based on the Berkeley 4.3-tahoe release.  Very up to date, highly
modular and reconfigurable.  I know, I wrote it ;-).  The MVME-147 was one of
the first two CPU cards we had up with the full TCP/IP/Sockets package.  It
does fit "like a glove".  I believe you may find that OS-9 has a lot of other
advantages over pSOS depending on your application.

Contact:
Mary Jo Marturello
Microware Systems Corp.
1844 NW 114th St.
Des Moines, IA 50322
(515)224-1929

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I also found some old stuff that came out of MITRE in the early 80's.
It does not come with a LANCE driver and is written for the CMOS kernel.


Allan Doyle                                              adoyle@bbn.com
BBN Systems and Technologies Corporation		 (617) 873-3398
70 Fawcett Street,   Cambridge, MA 02138




Allan Doyle                                              adoyle@bbn.com
BBN Systems and Technologies Corporation		 (617) 873-3398
70 Fawcett Street,   Cambridge, MA 02138

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 89 16:23:22 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   What is arp-5

When I run tcpdump, I occasionally see "arp-5" packets.  What are these?
-- 
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 89 17:32:12 GMT
From:      subbu@HPINDAW.HP.COM (MCV Subramaniam)
To:        comp.protocols.tcp-ip
Subject:   4 BSD TCP question.


I have a question on 4.3 BSD tcp_input() code. In the section in which
keepalive packets are handled, there is a comment that says "Dont toss 
RST in response to 4.2 style keepalive."  The code following it checks
for RST flag in the incoming packet.

Does this mean that 4.2 BSD sets the RST flag in a keepalive packet?
Can somebody point to me to 4.2 BSD sources?

Thanks in advance.

-Subbu
--
Domain: hpindaw.hp.com	UUCP: hplabs!hpindaw!subbu
Voice: (408)447-2693

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 89 00:01:04 GMT
From:      boland@hpindda.HP.COM (Ross Boland)
To:        comp.protocols.tcp-ip
Subject:   Re: CRC calc for Ethernet; How?


Try looking in "Journal of Data & Computer Communications" volume 1
Number 4, Spring 1989. They have a section dedicated to CRC calulations with 
examples written in C.

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 89 06:42:54 GMT
From:      euarrd@euas12g.ericsson.se (Richard Rosenlund)
To:        comp.protocols.tcp-ip
Subject:   Filter FTP traffic

I Recently sent an article out on the Swedish backboone, but i didn't
receive any answer to my question, so here it goes:

Background:

I wish to know, how to restrict FTP access so that it would be possible to deny
FTP "GET" requests from outside a network. One way would be to use a Router.
This may be "wrong thinking" but i thought it might be good to restrict
incoming access of the "well known port" # 20, but during a couple of
"shoots" here, i found out that port 20 always is opened by "FTP server".
And that is independent in both cases (GET or PUT).

Question:

My question simply is: Does any one have suggestions on how to proceed ?

Answers:

Please send your answer directly with E-mail to: euarrd@euas12g.ericsson.se

Thank you

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jul 89 11:19:53 EDT
From:      "Karen L. Bowers" <kbowers@NRI.Reston.VA.US>
To:        TCP-IP@sri-nic.arpa
Subject:   IETF Directory



The Internet Engineering Task Force announces the availability of a newly
revised on-line directory, the "IETF:" directory.

The "IETF:" directory has been established as an aid to both veteran IETF
members and newcomers. It is comprised of files containing: a general
description of the IETF (history, organization, goals); a summary of active
Working Groups within the IETF; IETF meeting dates/locations; upcoming
meeting information and an associated RSVP form; the upcoming meeting
agenda; and a README file with an overview of directory contents.  In
addition, individual files have been dedicated to each Working Group
and their particular activities. These files contain respective Charters,
Status Updates and Current Meeting Reports. The WG files are named in
the following fashion:

		<WG NAME>.charter
		<WG NAME>.status
		<WGNAME>.report

The "IETF:" directory is available on-line at SRI-NIC.ARPA and can be
accessed by anonymous ftp. The "dir" or "ls" command will permit a review 
of what files are available and the specific naming scheme to use for a 
successful anonymous ftp action. For more information, please contact:
             
                 ietf-request@venera.isi.edu.

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jul 89 11:22:33 EDT
From:      "Karen L. Bowers" <kbowers@NRI.Reston.VA.US>
To:        TCP-IP@sri-nic.arpa
Subject:   Internet-Drafts Directory



The Internet Engineering Task Force announces the availability of another
newly revised on-line directory, "INTERNET-DRAFTS:".

The "INTERNET-DRAFTS:" directory presents drafts for review and comment. 
It contains documents that will be submitted ultimately to the RFC
Editor to be considered for publishing as RFCs. Comments are welcomed
and should be addressed to the responsible persons whose names and email
addresses are listed on the first page of the respective draft. Each
Internet-Draft is placed in a separate file; the following standard
naming scheme is used:

File Format		Naming Scheme

ascii text		DRAFT-<TFNAME>-<WGNAME>-<ABBREVTITLE>-<REVNO>.TXT
Postscript		DRAFT-<TFNAME>-<WGNAME>-<ABBREVTITLE>-<REVNO>.PS
unix compressed ascii	DRAFT-<TFNAME>-<WGNAME>-<ABBREVTITLE>-<REVNO>.TXTZ
unix compressed 	DRAFT-<TFNAME>-<WGNAME>-<ABBREVTITLE>-<REVNO>.PSZ
  Postscript

If the document is not being authored in a Task Force, then the author's name
will be substituted for the Working Group name (WGNAME) and an organizational 
affiliation will be submitted for the Task Force name (TFNAME). Example:
 
         DRAFT-<ORG>-<AUTHORNAME>-<ABBREVTITLE>-<REVNO>.TXT

Drafts recently installed include the following:

<DRAFT-IETF-HOSTREQ-HRLL-00.TXT>	Requirements for Internet Hosts --
			or TXTZ>	Communication Layers, edited by
					Robert Braden for the Host Requirements
					Working Group, 16 June 89

<DRAFT-IETF-HOSTREQ-HRUL-00.TXT>	Requirements for Internet Hosts --
			or TXTZ>	Application Layer, edited by
					Robert Braden for the Host Requirements
					Working Group, 22 May 89.

<DRAFT-IETF-PPP-REQ-00.TXT>		Requirements for an Internet Standard
					Point-to-Point Protocol, edited by 
					Drew Perkins for the PT-PT Protocol
					Working Group, June 1989

<DRAFT-IETF-PPP-IPDATAGRAMSTX-00.TXT	The Point-to-Point Protocol(PPP):
					A Proposed Standard for the 
					Transmission of IP Datagrams over
					Point-to-Point Links, edited by
					Drew Perkins for the PT-PT Protocol
					Working Group, June 1989

<DRAFT-UCL-KILLE-X400RFC822-00.TXT	Mapping between X.400 (1988) and\
					RFC822, Steve Kille, University
					College London, 5 June 89.

<DRAFT-IETF-TELNET-LINEMODE-00.TXT>	Telnet Linemode Option, edited by
					David Borman for the TELNET Working
					Group, July 1989. COMMENTS ON THIS
					DRAFT WILL BE ACCEPTED UNTIL 17 July
					1989.

<DRAFT-IETF-HRWG-MULTIHOMING-00.TXT>	Multi-homed Hosts in an IP Network,
					J. Lekashman, 26 April 1988



The "INTERNET-DRAFTS:" directory is on-line at SRI-NIC.ARPA and can be
accessed by anonymous ftp. It contains a README file and an Index-Abstract
file to aid the reader in locating drafts of interest. The "dir" or "ls" 
command will permit a review of what files are available and the specific 
naming scheme to use for a successful anonymous ftp action. 
For more information, please contact:

                 ietf-request@venera.isi.edu.

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 89 12:25:49 GMT
From:      heker@JVNCA.CSC.ORG (Sergio Heker)
To:        comp.protocols.tcp-ip
Subject:   Re: Troubleshooting routing problems


I tend to agree with Kent that troubleshooting routing problems require
the interaction with other Networks.  But a more general statement can
be made that includes not only routing but End to End service.  This means
connectivity as well as performance.  In this, more general case we need
to remember that the Internet is a "network" has distributed management or 
in other words, each of the Internet components is managed and operated
by different (autonomous) entities.  These "entities" have different
levels of service (hours of operation and type of support, e.g. tools).
One of the greatest efforts to put some light into this problem, in my
opinion, is the NSFnet backbone.  MERIT has been developing the 
infrastructure to be able to look into problems that affect users across
country that use the NSFnet network to pass Inter-regional traffic, and
is doing a very good job assisting the Regional Networks to get problems
resolved.  The Regional Networks have a role in dealing with the regional
users and helping them to get the problems outside their campuses resolved.
This requires among other things, that Regional Networks be prepared (have
the facilities and infrastructure) to help their users.  This raises the
point of who the users of the Regional Network are.  One answer is the
institutions connected to it, the other answer is the people that pass
traffic.  If the Regional Network users are the "Campus" Network Organization
(for the Campuses that have one), then they are responsible for assisting
their users (the people that send the traffic).

The JvNCnet network, like other networks has been dealing with all these 
issues for the last three years, and is working closely with the Institution
members (Campuses), with MERIT and with other Regional Networks to assist
users.  Consistent with this spirit of cooperation we have met a number of
times with the principals of the Regional and State Networks in the North
East of the Country (PREPnet, NYSERnet, NEARnet and JvNCnet) to discuss
technical issues of Regional to Regional nature. 
meetings have been very productive, and will continue in the future, in
order to provide for the necessary coordination among the peer networks
to free the end-user of unnecessary complications.
In doing this we have developed a group within the Network Department,
called the Network Information Services Group, with the function of providing
information to the JvNCnet members (among other things).  A Network Operations
Group deals with the daily operations of the network.  Two other groups 
sometimes not visible but nevertheless very important in supporting our
network are the Network Engineering Group and the Network Installation and
Maintenance Group.  This organization and the facilities available consitute
our infrastructure to be able to support our community of users.

A problem that we have encountered, is that some of the end users (or the
Campus' users) don't know who to contact when there is a problem on the
network.  Ocassionally, they call the wrong person, or the person that cannot
help them to resolve the problem, or get forwarded a number of times.  This
only causes frustration for the end users.  We are in the process, through
the Network Information Services Group of initiating some training to the 
JvNCnet Member sites so they can assist the end users.  This effort will
be discussed in the next JvNCnet Regional Network Meeting in September.

If anyone is interested in getting more information about JvNCnet please
contact our Network Coordinator or myself at "nisc@nisc.jvnc.net" or by
phone at (609) 520-2000.

						-- Sergio




-----------------------------------------------------------------------------
|		John von Neumann National Supercomputer Center		    |
|  Sergio Heker				tel:	(609) 520-2000		    |
|  Director for Networking		fax:	(609) 520-1089		    |
|  Internet: "heker@jvnca.csc.org"	Bitnet:	"heker@jvnc"		    |
-----------------------------------------------------------------------------

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 89 14:38:08 GMT
From:      craig@bbn.com (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   ACM SIGCOMM miscellany

I just wanted to make people aware of several SIGCOMM related activies.

    + the program for ACM SIGCOMM '89 appears in this month's issue of
	Communications of the ACM (pages A-23 through A-25).

    + we continue to be interested in nominations for the SIGCOMM Award.
	The award "recognizes outstanding contributions to the field
	of computer communications and networking.  It
	is presented annually to an individual whose work in the
	theory or practice of communications and networking
	has significantly advanced the field."  The nomination deadline
	has been extended until August 15th because this month's issue
	of CCR was delayed when the July 4th weekend fell in the middle
	of the publication schedule.  Nominations should be sent to me,
	and should include a full vita, a list of publications, and a
	essay on the the candidate's most notable contributions to the
	field of data communications.

    + Where available, papers from CCR are now available on-line on
	nnsc.nsf.net in the directory CCR.  Papers are in postscript
	and are organized by month of issue and the last name of the
	first author.  So, for example, Dave Borman's paper on
	Cray TCP performance from the April '89 issue is in:

		CCR/apr89/borman.ps

	Each issue's directory also contains a complete table of contents
	(TOC.ps) and the issue's bibliography of recent publications (in
	UNIX refer format).

    + the SIGCOMM '90 Call for Papers is out.  The program chair is
	Phil Karn (karn@thumper.bellcore.com).  You can FTP a copy
	of the call for papers from CCR/jul89/call.ps

Craig

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 89 15:19:53 GMT
From:      kbowers@NRI.RESTON.VA.US ("Karen L. Bowers")
To:        comp.protocols.tcp-ip
Subject:   IETF Directory




The Internet Engineering Task Force announces the availability of a newly
revised on-line directory, the "IETF:" directory.

The "IETF:" directory has been established as an aid to both veteran IETF
members and newcomers. It is comprised of files containing: a general
description of the IETF (history, organization, goals); a summary of active
Working Groups within the IETF; IETF meeting dates/locations; upcoming
meeting information and an associated RSVP form; the upcoming meeting
agenda; and a README file with an overview of directory contents.  In
addition, individual files have been dedicated to each Working Group
and their particular activities. These files contain respective Charters,
Status Updates and Current Meeting Reports. The WG files are named in
the following fashion:

		<WG NAME>.charter
		<WG NAME>.status
		<WGNAME>.report

The "IETF:" directory is available on-line at SRI-NIC.ARPA and can be
accessed by anonymous ftp. The "dir" or "ls" command will permit a review 
of what files are available and the specific naming scheme to use for a 
successful anonymous ftp action. For more information, please contact:
             
                 ietf-request@venera.isi.edu.

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 89 15:22:33 GMT
From:      kbowers@NRI.RESTON.VA.US ("Karen L. Bowers")
To:        comp.protocols.tcp-ip
Subject:   Internet-Drafts Directory




The Internet Engineering Task Force announces the availability of another
newly revised on-line directory, "INTERNET-DRAFTS:".

The "INTERNET-DRAFTS:" directory presents drafts for review and comment. 
It contains documents that will be submitted ultimately to the RFC
Editor to be considered for publishing as RFCs. Comments are welcomed
and should be addressed to the responsible persons whose names and email
addresses are listed on the first page of the respective draft. Each
Internet-Draft is placed in a separate file; the following standard
naming scheme is used:

File Format		Naming Scheme

ascii text		DRAFT-<TFNAME>-<WGNAME>-<ABBREVTITLE>-<REVNO>.TXT
Postscript		DRAFT-<TFNAME>-<WGNAME>-<ABBREVTITLE>-<REVNO>.PS
unix compressed ascii	DRAFT-<TFNAME>-<WGNAME>-<ABBREVTITLE>-<REVNO>.TXTZ
unix compressed 	DRAFT-<TFNAME>-<WGNAME>-<ABBREVTITLE>-<REVNO>.PSZ
  Postscript

If the document is not being authored in a Task Force, then the author's name
will be substituted for the Working Group name (WGNAME) and an organizational 
affiliation will be submitted for the Task Force name (TFNAME). Example:
 
         DRAFT-<ORG>-<AUTHORNAME>-<ABBREVTITLE>-<REVNO>.TXT

Drafts recently installed include the following:

<DRAFT-IETF-HOSTREQ-HRLL-00.TXT>	Requirements for Internet Hosts --
			or TXTZ>	Communication Layers, edited by
					Robert Braden for the Host Requirements
					Working Group, 16 June 89

<DRAFT-IETF-HOSTREQ-HRUL-00.TXT>	Requirements for Internet Hosts --
			or TXTZ>	Application Layer, edited by
					Robert Braden for the Host Requirements
					Working Group, 22 May 89.

<DRAFT-IETF-PPP-REQ-00.TXT>		Requirements for an Internet Standard
					Point-to-Point Protocol, edited by 
					Drew Perkins for the PT-PT Protocol
					Working Group, June 1989

<DRAFT-IETF-PPP-IPDATAGRAMSTX-00.TXT	The Point-to-Point Protocol(PPP):
					A Proposed Standard for the 
					Transmission of IP Datagrams over
					Point-to-Point Links, edited by
					Drew Perkins for the PT-PT Protocol
					Working Group, June 1989

<DRAFT-UCL-KILLE-X400RFC822-00.TXT	Mapping between X.400 (1988) and\
					RFC822, Steve Kille, University
					College London, 5 June 89.

<DRAFT-IETF-TELNET-LINEMODE-00.TXT>	Telnet Linemode Option, edited by
					David Borman for the TELNET Working
					Group, July 1989. COMMENTS ON THIS
					DRAFT WILL BE ACCEPTED UNTIL 17 July
					1989.

<DRAFT-IETF-HRWG-MULTIHOMING-00.TXT>	Multi-homed Hosts in an IP Network,
					J. Lekashman, 26 April 1988



The "INTERNET-DRAFTS:" directory is on-line at SRI-NIC.ARPA and can be
accessed by anonymous ftp. It contains a README file and an Index-Abstract
file to aid the reader in locating drafts of interest. The "dir" or "ls" 
command will permit a review of what files are available and the specific 
naming scheme to use for a successful anonymous ftp action. 
For more information, please contact:

                 ietf-request@venera.isi.edu.

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 89 20:28:03 GMT
From:      rdn@chinet.chi.il.us (Richard Nichols)
To:        comp.protocols.tcp-ip
Subject:   Ethernet 'null transceiver'?


We have a need to connect two machines together that have thick-wire
ETHERNET connections.  Since there are only two machines in this 'network' I
was wondering if there is such a thing as a 'null transceiver'?  In other
words, is there a way to connect our two machines without having to actually
connect real transceivers?

Any help would be appreciated.

Rick Nichols
rdn@chinet.chi.il.us

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 89 21:07:11 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Terminal Server used in reverse recommendations wanted

["-=EPS=-" says:]
    Yes, I have a recommendation:
      DON'T DO THIS.
    16 reasons why "milking machines" are a bad idea:

First of all, let me agree with EPS and Chuck - reverse terminal
server connections are not a particurally wonderful way of connecting
things to a network.  However, things are not necessarily as bad as
EPS makes out, especially if the "milking machine" the only
alternative you have for connecting something to the host.  A lot of
the complaints made are generally true of network terminal access
(not restricted to "milking machines").  These include:

    - You may have flow control problems.
    - Interrupt characters don't take effect promptly.
    - It's difficult to do flushes.
    - You can't do reliable timed inputs.
    - The terminal server doesn't know where "information
      boundaries" are.  It doesn't know when to push, it
      can't dynamically switch between character-at-a-time
      operation and intelligent forwarding.  Remote echo performance
      suffers, or you generate a lot of unnecessary network traffic,
      or both.  Local echoing is probably not a viable option.

Very few telnet implementations do any of this (although this will
hopefully change in the non-distant future).  For a milking machine,
it may be impossible, rather than just not done, but this is a fine
distinction.  Depending on the application, it may be possible to
configure the terminal server to be more intelligent (to know when
to "push", for example).


I have some other answers:
    - You lose all useful telnet subnegotiation capability.
Which may not be supported by the originating host anyway, which may not
be applicable for the application.

    - Unless you have hardware handshake, you tend to have
      transparency problems.
Always true for any situation requiring flow control.

    - You might not be able to send BREAKs in both directions.
This SHOULD work.

    - You only get telnet access, and possibly only incoming.
This may be all you need.

    - You are limiting yourself to a small, fixed number of
      sessions.
This may be all you need.

    - It costs more to do it this way--you are paying for two
      unnecessary serial interfaces per line.
    - More intervening hardware => lower reliability => more downtime
      => higher maintenance costs
    - On many machines serial I/O has significantly higher overhead
      than network service.
This all assumes that network service is available at a finite cost.
network access.  I can assure you that if you have (say) a DEC-20
that already has serial lines, it is much cheaper to connect it
to a $3000 milking machine than to install an ethernet interface ($12000,
plus significant hardware work that may force you to change your current
configuration), plus TCP software ($5000, if you can find someone to sell
it to you, free from various other places, if you happen to know how to
build your own monitors from sources).  And after you've spent your
$17K, the network support doesn't give you any additional telnet
functionality than the milking machine.  Im sure that there are other
dinosaurs (obviously anything that doesn't run unix) in the same boat.

One of the things we use "milking machines" for internally at cisco
is to connect to the console ports of routers, csu/dsus, and so on,
so that we can access them form the network.  A milking machine is
obviously adequate for this sort of use.

Bill Westfield
cisco Systems.
-------

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 89 21:44:00 GMT
From:      nccpriv@hyper0.lynn.ge.com ("Kundrot, Andy")
To:        comp.protocols.tcp-ip
Subject:   re: ICMP multiple Echo Replies

:I started noticing repeated ICMP Echo Replies after a change in
:our local network.
 [stuf deleted]
:the campus is converting to using the Chipcom Ethermodem III with
:Lanbridge 100.  Our local net has Sun 3's,a Sequent, uVaxII's with DELQA's 
:and a variety of uVax workstations, and some 3b2's and 3b1's.  There may 
:be some mismatching of ethernetversions in there like Phil suggested.
:-- 
:<- David Herron; an MMDF guy                              <david@ms.uky.edu>
:<- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
:<-
:<- New word for the day: Obnoxity -- an act of obnoxiousness
:--------
   Our extended ethernet has 20+ segments linked together via LB100's with 
about half of these going through Chipcom Ethermodem III's to our Plant Wide 
Broadband.  Some of the equipment I have tried to plug directly into the 
Chipcom does not function properly and may result in the problem you describe.
Amongst these is my trusty HP-LANalizer.  The Chipcom claims to be 802.3 and 
the HP compatible with both 802.3 and Ethernet.  I suspect the Chipcom is the 
strange one.
   You should also determine if SQE is wanted or not by annything you plug into 
your Chipcoms (or your trancivers, MAUs, etc).  If you have SQE set wrong all 
kinds of weirdness will plauge your network.  The LB100 does not realy care 
about SQE but most DEC hosts MUST have it and many others MUST NOT have it.  
This feature is switch selectible in the Chipcom.  BTW if a host does not 
expect SQE and it is enabled it may think there was a collision and if it does 
expect SQE and does not get it the host may decide there was a problem with 
transmition.  Ether way you MIGHT get an unexpected retransmition.
   On page 4-3 of the manual under COLLISIONS ON BROADBAND they state that 
detection of a collision by one node does not garantee that all transmitting 
nodes on the network will be aware of it. [stuff deleted]  Any node that
detects a collision sends a signal in the collision channel.  [Thus making all 
other nodes aware of it]  That is the theory, in reality I see high collision 
rates at the ends of broadband runs and lower collision rates near the headend. 
I do not have a lot of confidance in Chipcoms BroadBand collision detection 
system and suspect that it could cause one segment to think there was a 
collision when the packet actualy went through. (quoted without permission)

Mark E. Baldwin			baldwinm@hyper0.lynn.ge.com	or
Network Analyst			baldwinm%hyper0.lynn.ge.com@crdgw1.ge.com
GE

Please remember that I only work for GE, I do not speek for them.

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 89 00:42:22 GMT
From:      earle@SUN.COM (Greg Earle)
To:        comp.protocols.tcp-ip
Subject:   BSD FTP client won't allow auto-logon when `Account' required - why?


The latest documentation for the 4BSD `ftp' client program that I have lists
the following, in the description of the .netrc file:

     account string
          Supply an additional account password.  If  this  token
          is  present,  the  auto-login  process  will supply the
          specified string if the remote server requires an addi-
          tional account password, or the auto-login process will
          initiate an ACCT command if it does not.

The last half of this appears to be true, but the first half is not.
When one attempts to use this, one is always prompted for the `Account:'
string, no matter whether the `account [ string ]' is in the .netrc file or
not.  An example, talking to a Univac system that requires an account:

myhost% cat ~/.netrc
machine univac login me password noseeum account 12345
myhost% ftp -v -t -d univac
Connected to univac.
220-File server ready for new user.
220 Enter USER user-id.
---> USER me
331 User-id received; Enter PASS password.
---> PASS noseeum
332 enter ACCT account[,project].
Account: ^C
myhost%

I found the following code chunk in /usr/src/ucb/ftp/ftp.c's login()
function, for every version of ftp.c I could find - SunOS 4.0.3, 
4.3BSD-tahoe, and Rick Adams' post-Tahoe ftp on uunet.UU.NET:

myhost% sccs what uunet_ftp/ftp.c bsd-tahoe_ftp/ftp.c /usr/src/ucb/ftp/ftp.c
uunet_ftp/ftp.c:
	ftp.c   5.28 (Berkeley) 4/20/89
bsd-tahoe_ftp/ftp.c:
	ftp.c   5.24.1.3 (Berkeley) 3/1/89
/usr/src/ucb/ftp/ftp.c:
	ftp.c 1.1 89/05/19 SMI; from 5.14 (Berkeley) 5/22/86

[ code chunk ]
...
	n = command("USER %s", user);
	if (n == CONTINUE) {
		if (pass == NULL)
			pass = getpass("Password:");
		n = command("PASS %s", pass);
	}
	if (n == CONTINUE) {
		aflag++;
		acct = getpass("Account:");
		n = command("ACCT %s", acct);
	}
	if (n != COMPLETE) {
		fprintf(stderr, "Login failed.\n");
		return (0);
	}
	if (!aflag && acct != NULL)
		(void) command("ACCT %s", acct);
...

In other words, the code checks to see if the PASS has been loaded from the
.netrc, and if so, it sends it on. However, in the case of ACCT, it doesn't
check to see if it has been pre-loaded, and asks for it no matter what.
This seems so obvious that I thought I'd ask first before assuming it's a bug.
Am I missing something?  Is there some reason for this??  i.e., why is the code

		acct = getpass("Account:");
and not
		if (acct == NULL)
			acct = getpass("Account:");

just like it is for the sending of the password???

I have a customer who would like to use his .netrc file in conjunction
with a shell `here is' document to automate retrieval of files from this
Univac, and we're stuck by this.  As you can see from the script, the
Univac machine demands the account at login time; so we can't just remove
the `account 12345' from .netrc and manually send it from the `here is'
document (as part of the standard input) once logged on.

Thanks,

	- Greg Earle
	  earle@Sun.COM

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 89 04:26:30 GMT
From:      pst@anise.acc.com (Paul Traina)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet 'null transceiver'?

rdn@chinet.chi.il.us (Richard Nichols) writes:
>We have a need to connect two machines together that have thick-wire
>ETHERNET connections.  Since there are only two machines in this 'network' I
>was wondering if there is such a thing as a 'null transceiver'?

Yes there is a way to do it,  but it's a little more complex than just
hacking a tranceiver cable to flip signals.  When I was at ComDesign,
we came up with just such a hack to connect two forms of stat. mux.
that usually talked directly over the ethernet.

First off,  there are the expected wire switches in the tranceiver
cable itself.  Secondly,  you must program the ethernet chips to
operate in loopback (yes!) mode.  I can't say that this will work
for a Lance chip,  but I have done it properly with a LCC.  If you're
able to hack the software that controls the ethernet chip,  drop me
a note and I'll try and dig up my old notes on how we got the bugger
to work.

On the other hand,  if you can't do it a simple way, you could always
purchase a DELNI (from Digital) or any other tap-expander,  which will
simply look like 8 ethernet tranceivers.  You can hang a tap off the
9th jack and plug it into a real thick wire ethernet,  or you can
just flip a switch and have the DELNI look like the entire ethernet.

If you'll only have those two machines, and you can't go in and mung
them,  I'm afraid your cheapest alternative is probably buying two
tranceivers and a 2 meter ethernet segment.  If you'll ever add on
a third or fourth node,  go with the DELNI-type device.

Good luck & if anyone wants to know about mashing the cables and
and reprogramming the ethernet chip, just drop me a line (I may
be somewhat slow about getting back to you on it, as I may have to
call some friends at ComDesign if I can't dig up my notes.)

						Paul

-- 
    "Calling people sexist because they are into S/M is like calling
     people capitalist because they like to play Monopoly(TM)."
			    -- `Ask Aunt Sadie' / the Ministry of Truth

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 89 09:37:00 EST
From:      <afrlinkv@wpafb-info5.af.mil>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Re: Ethernet 'null transceiver'?

Richard Nichols asked about a 'null transceiver' to connect two PCs
without multiple transceivers and ethernet cable.  So far all responses 
have recommended fanout boxes - an active device.  There is an alternative;
ANC, now a Division of Niravoice, Inc. makes the ANC-10.  Their description
follows:
		Ethernet AUI-AUI Direct Connection Device
		Direct connection of  two Ethernet/IEEE 802.3 nodes up
		to 100 meters or 330 ft. without using transceivers
		and Ethernet coaxial cable.

		list price:  $180.00

We've throughly tested this device and both sides fully meet the 802.3
specs for tranceivers.  You can get about 30% off of list.  ANC's
address is:

	ANC Division of Niravoice, Inc.
	103 East Alma Avenue
	San Jose, CA  95112
	(408) 947-2040  FAX:  (408) 947-1343

Good luck!

Link Verstegen
Integration Manager
Network Solution, Inc.
4350 Will Rogers Parkway
Suite 100
Oklahoma City, OK 73108
(405) 942-8884
AFRLINKV@WPAFB-info2.AF.MIL

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Jul 89 12:28:11 edt
From:      rhott@relay.nswc.navy.mil
To:        daitc!dgis.daitc.mil!generous@uunet.uu.net, tcp-ip@sri-nic.arpa
Cc:        rdn@chinet.chi.il.us
Subject:   Re: Ethernet 'null transceiver'?
>rdn@chinet.chi.il.us (Richard Nichols) writes:
>>We have a need to connect two machines together that have thick-wire
>>ETHERNET connections.  Since there are only two machines in this 'network' I
>>was wondering if there is such a thing as a 'null transceiver'?  In other
>>
>>Rick Nichols
>>rdn@chinet.chi.il.us
>
>The easiest way is to get a "Fan Out Unit" (aka multiport transceiver).
>Allows several (usually 8) devices to talk to one other without the
>need of a ethernet segment.  No cheap, costs around $1000.
>
>--curtis
>---
>Curtis C. Generous
>DTIC Special Projects Office (DTIC-SPO)
>ARPA: generous@daitc.mil
>UUCP: {uunet,vrdxhq,lll-tis}!daitc!generous

  I have a copy of a "glossy" for a product from American Network Connections.
It is for a device called "ANC-10".  It is an Ethernet AUI-AUI Direct
Connection Device.  It basically connects two systems together.  I wrote
in the margin that the cost was ~$120.00  You might try contacting them:

  American Network Connections, Inc
  462 Oakmead Parkway
  Sunnyvale, California 94086

  Phone (408) 737 - 1511

One of their schematics looks something like this:

     Workstation -----aui cable------[ANC-10]------aui cable---- Workstation

I have not tried this device, and I am not in any way affiliated with them.
Hope that this helps!


Bob Hott
Networks Branch (Code E41)
Naval Surface Warfare Center
Dahlgren, VA  22448
(703) 663 - 7745
-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 89 11:49:45 GMT
From:      generous@dgis.daitc.mil (Curtis Generous)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet 'null transceiver'?

rdn@chinet.chi.il.us (Richard Nichols) writes:
>We have a need to connect two machines together that have thick-wire
>ETHERNET connections.  Since there are only two machines in this 'network' I
>was wondering if there is such a thing as a 'null transceiver'?  In other
>
>Rick Nichols
>rdn@chinet.chi.il.us

The easiest way is to get a "Fan Out Unit" (aka multiport transceiver).
Allows several (usually 8) devices to talk to one other without the
need of a ethernet segment.  No cheap, costs around $1000.

--curtis
---
Curtis C. Generous
DTIC Special Projects Office (DTIC-SPO)
ARPA: generous@daitc.mil
UUCP: {uunet,vrdxhq,lll-tis}!daitc!generous

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 89 12:44:47 GMT
From:      grim@udel.EDU (Dan Grim)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet 'null transceiver'?

rdn@chinet.chi.il.us (Richard Nichols) writes:


>We have a need to connect two machines together that have thick-wire
>ETHERNET connections.  Since there are only two machines in this 'network' I
>was wondering if there is such a thing as a 'null transceiver'?  In other
>words, is there a way to connect our two machines without having to actually
>connect real transceivers?
 
>Any help would be appreciated.
 
>Rick Nichols
>rdn@chinet.chi.il.us

Black Box sells two-port and four-port transceivers that can do exactly
what you want for somewhat less money than DELNI-like devices (8-port).
Here's the info:

	NK-LE050A	2-port Ethernet Transceiver		$450
	NK-LE051A	2-port BNC Transceiver			$450
	NK-LE052A	4-port Ethernet Transceiver		$699
	NK-LE053A	4-port BNC Transceiver			$699

Both units appear to use the standard AMP vampire or BNC tap and do not
appear to require a separate transceiver for cable attachment.  Both
devices appear to be the same size which is approximately 3.5" x 7".

					Dan

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 89 12:48:46 GMT
From:      mike@cmx.npac.syr.edu (Mike Leccarde)
To:        comp.protocols.tcp-ip
Subject:   Bridge Terminal Server


Hello,

Has anyone had any luck connecting a printer to a bridge terminal
server??

Also, We have a spectrometer that will run kermit. I'd like to be able
to have it run kermit and be connected to a port on a bridge terminal
server. My question is: Could any other node on the ethernet gain access
to the spectrometer, assuming it was running kermit and in "server"
mode?

Any information on these topics would be greatly appreciated.


I can be reached as follows:

By US Mail or Voice:

Mike Leccarde 
New Methods Research, Inc.
719 East Genesee Street
Syracuse, NY 13210
315-424-0329

or by E-mail:
uunet!nmri!mike -or-
mike@cmx.npac.syr.edu

or via the net.

Thankyou

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 89 14:37:00 GMT
From:      afrlinkv@WPAFB-INFO5.AF.MIL
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet 'null transceiver'?


Richard Nichols asked about a 'null transceiver' to connect two PCs
without multiple transceivers and ethernet cable.  So far all responses 
have recommended fanout boxes - an active device.  There is an alternative;
ANC, now a Division of Niravoice, Inc. makes the ANC-10.  Their description
follows:
		Ethernet AUI-AUI Direct Connection Device
		Direct connection of  two Ethernet/IEEE 802.3 nodes up
		to 100 meters or 330 ft. without using transceivers
		and Ethernet coaxial cable.

		list price:  $180.00

We've throughly tested this device and both sides fully meet the 802.3
specs for tranceivers.  You can get about 30% off of list.  ANC's
address is:

	ANC Division of Niravoice, Inc.
	103 East Alma Avenue
	San Jose, CA  95112
	(408) 947-2040  FAX:  (408) 947-1343

Good luck!

Link Verstegen
Integration Manager
Network Solution, Inc.
4350 Will Rogers Parkway
Suite 100
Oklahoma City, OK 73108
(405) 942-8884
AFRLINKV@WPAFB-info2.AF.MIL

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 89 15:22:09 GMT
From:      ddf@a.cs.okstate.edu (D D Fisher)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Information request: ADCAP protocol

I need information on the ADCAP protocol. Any suggestions
on where to look for information will be appreciated.

D D Fisher

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 89 15:37:00 GMT
From:      Chucko@VERMITHRAX.SCH.SYMBOLICS.COM (Charles R. Fry)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet 'null transceiver'?


    Date: 14 Jul 89 11:49:45 GMT
    From: daitc!dgis.daitc.mil!generous@uunet.uu.net  (Curtis Generous)

    rdn@chinet.chi.il.us (Richard Nichols) writes:
    >We have a need to connect two machines together that have thick-wire
    >ETHERNET connections.  Since there are only two machines in this 'network' I
    >was wondering if there is such a thing as a 'null transceiver'?  In other
    >
    >Rick Nichols
    >rdn@chinet.chi.il.us

    The easiest way is to get a "Fan Out Unit" (aka multiport transceiver).
    Allows several (usually 8) devices to talk to one other without the
    need of a ethernet segment.  No cheap, costs around $1000.

    --curtis
    ---
    Curtis C. Generous
    DTIC Special Projects Office (DTIC-SPO)
    ARPA: generous@daitc.mil
    UUCP: {uunet,vrdxhq,lll-tis}!daitc!generous

I have had excellent results with Cabletron's MT800, and the price and
delivery are right.  They have offices in Silicon Valley and New Hampshire,
but I don't recall the phone numbers at the moment.

 -- Chuck Fry
    Chucko@Riverside.SCRC.Symbolics.COM

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 89 16:28:11 GMT
From:      rhott@RELAY.NSWC.NAVY.MIL
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet 'null transceiver'?

>rdn@chinet.chi.il.us (Richard Nichols) writes:
>>We have a need to connect two machines together that have thick-wire
>>ETHERNET connections.  Since there are only two machines in this 'network' I
>>was wondering if there is such a thing as a 'null transceiver'?  In other
>>
>>Rick Nichols
>>rdn@chinet.chi.il.us
>
>The easiest way is to get a "Fan Out Unit" (aka multiport transceiver).
>Allows several (usually 8) devices to talk to one other without the
>need of a ethernet segment.  No cheap, costs around $1000.
>
>--curtis
>---
>Curtis C. Generous
>DTIC Special Projects Office (DTIC-SPO)
>ARPA: generous@daitc.mil
>UUCP: {uunet,vrdxhq,lll-tis}!daitc!generous

  I have a copy of a "glossy" for a product from American Network Connections.
It is for a device called "ANC-10".  It is an Ethernet AUI-AUI Direct
Connection Device.  It basically connects two systems together.  I wrote
in the margin that the cost was ~$120.00  You might try contacting them:

  American Network Connections, Inc
  462 Oakmead Parkway
  Sunnyvale, California 94086

  Phone (408) 737 - 1511

One of their schematics looks something like this:

     Workstation -----aui cable------[ANC-10]------aui cable---- Workstation

I have not tried this device, and I am not in any way affiliated with them.
Hope that this helps!


Bob Hott
Networks Branch (Code E41)
Naval Surface Warfare Center
Dahlgren, VA  22448
(703) 663 - 7745

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 89 17:32:59 GMT
From:      schoff@SOLBOURNE.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: Troubleshooting routing problems

I wish the problems were only routing, the reality of many situations
is that they are caused by a myriad of problems:

	1) the diameter of the Internet continues to grow, Ultrix systems
	out of the box which are configured with a
	"low" TTL's are having lots of problems right now since there are
	10's of gateway hops now between many facilities.  This is especially
	true during a failure where the redundant multiple path capability
	kicks in, but over a much "longer" path.  This week within NYSERNet
	a T1 failed in NYC and for two days RockefellerUniv communicated
	with CUNY (both in NYC) through upstate NY.

	2) networks break for periods of time and the word doesn't really
	get out.  For instance both the NYSERNet and Merit/NSFNet NOCs saw
	truelly horrible reachability problems into the MILNET this week.
	Why?  We don't know.

	3) networks run out of bandwidth, almost nothing gets through to
	some very important hosts like SRI-NIC.ARPA with its ARPANET and
	MILNET only connections during much of the day.

	4) our backup connections are mere straws in comparison to the
	fire hoses we normally use.  A T1 connection to NEARNET (of which
	CSNET has connectivity through) has been very flakey of late,
	when it doesn't work traffic backs off onto 56kbps ARPANET.

	5) and then there is routing:  string, chewing gum, glue and people
	pushing ISO "solutions"..

Good Luck, just don't lay the blame on one cause or one group.  We're all
at fault.


Marty
--------------------
    Occasionally we here at UCSD seem to suffer from connectivity problems
    that I think are a result of lost routing information.  The symptoms are
    that we stop being able to reach some networks or they us.

    To be more specific about it, our campus Ethernet is connected via a
    Proteon router to the San Diego Supercomputer Center's Ethernet and to
    several other networks around California - "CERFnet".  We rarely have
    trouble reaching those networks.  However, from time to time, some
    networks don't seem to be reachable from our campus network, but can be
    reached from machines on the SDSC Ether or from other CERFNet members.

    For example, right at this moment I can't ping any machines on the
    192.31.103 network where RELAY.CS.NET and its nameservers live, nor can
    we ping anything on the Purdue campus.  Yet both are quite reachable
    from SDSC.  The NIC was unreachable for more than a day, and we haven't
    been able to get info from the UK nameservers for more than a week. 
    I don't get network unreachable ICMP messages.

    Our routing table consists of a few subnet entries and a default route
    to the SDSC Proteon.

    SDSC has recently lost their network guru, and whilst they are trying
    quite hard to help, they're not quite up to speed just yet.

    What I think is happening is that the reachability information for the
    UCSD network isn't getting propagated as well as it might be.  I suspect
    that my outgoing pings are probably reaching their destinations, but
    that the return ping response can't find a route back to our network.

    How can I test this from here (or elsewhere)?

    	Brian Kantor	UCSD Postmaster
    		UCSD Office of Academic Computing	(619) 534-6865
    		UCSD C-010, La Jolla, CA 92093 USA	fax: 619 534 7018
    		brian@ucsd.edu	BRIAN@UCSD ucsd!brian

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 89 18:16:47 GMT
From:      jnford@jay.weeg.uiowa.edu (Jay Ford)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet 'null transceiver'?

In article <8943@chinet.chi.il.us>, rdn@chinet.chi.il.us (Richard Nichols) writes:
>
> We have a need to connect two machines together that have thick-wire
> ETHERNET connections.  Since there are only two machines in this 'network' I
> was wondering if there is such a thing as a 'null transceiver'?  In other
> words, is there a way to connect our two machines without having to actually
> connect real transceivers?

American Network Connections makes a thing called an "ANC-10 Ethernet AUI-AUI
Direct Connection Device", which sounds like what you want.  We have one here
and it behaved very well (but has since been replaced by a multiport
transceiver).  It has LEDs and everything!

We bought ours from a distributor:

	Illinois Computer Cable, Inc
	5207 Walnut Ave
	Downers Grove, IL  60515

	312-810-0200
	1-800-323-2612


Jay Ford,  Weeg Computing Center,  University of Iowa,  Iowa City,  IA  52242
jnford@jay.weeg.uiowa.edu  or  jnfordpb@uiamvs.bitnet,  319-335-5555

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 89 18:39:11 GMT
From:      lwilson@umabco.UUCP (Lowell G. Wilson)
To:        comp.protocols.tcp-ip
Subject:   Mail servers

I'm not altogether certain I am posting this to the right newsgroup, so
please bear with me. 

Our shop is in the process of stringing fiber across the campus to
create a campus LAN.  Currently we have lots of users connected to
Novell, 3-Com and Starlan networks.  Additionally, we have a PACX data
switch that grants access to a UNIX-based conferencing system and an IBM
mainframe.  All of this stuff will eventually be hooked up to the campus
LAN which will have a TCP/IP router hanging off of it.  This means that
several independant electronic mail systems might just be able to talk
to one another? I was wondering if anyone who has done this sort of
thing could send me some ideas.  Right now we are running Profs on the
mainframe, plain vanilla UNIX mail on the UNIX box, and 3-Com, StarLAN
and Novell mail on the file servers. 

I THINK what I need to find out is if there is any way to get all these
systems to talk SMTP and, if there is, if there is any way to get them
to forward mail not intended for users of their systems to some default
SMTP mail server.  Our mainframe is rather underutilized, so if there is
any way that machine could be used as an SMTP mail server, that would be
great.  

Any help would be greatly appreciated.  We're a ways away from getting
the fiber strung so I'm just trying to get a handle on the problems
we're going to run into and mail seemed as good a place to start as any!
If I have left out any needed details (doubtless I have) I'll be happy
to fill in the blanks as best I can.  Thanks in advance for any
suggestions...  
-- 
Lowell Wilson : Sinecure III        University of Maryland at Baltimore    
                                    Information Resources Mgt Division     
                                    UUCP: ...cvl!umabco!lwilson            
                                    Internet: umabco!lwilson@cvl.umd.edu

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 89 19:32:58 GMT
From:      cliff@WSU-ENG.ENG.WAYNE.EDU (Cliff Stallings)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip relay group

Please add my name to the tcp-ip relay group.  My email address is:
 
 cliff@wsu-eng.eng.wayne.edu
 
thanks...

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 89 20:43:59 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Forwarding IP packets with source on net 0?


Steve,

  The Host Requirements RFC draft (Internet Layer, Section 3.2.1.3)
  says a host MUST NOT send {0,*} except as a source address as part of
  a booting procedure (which is your case, I believe).  More importantly,
  a host receiving a datagram with such a source address MUST ignore the
  datagram.

 The discussion of filtering bogus addresses in RFC-1009 (Section 4.4
 and Appendix A.1) talks only about the destination address; it does
 outlaw forwarding to {0,*} as a destination.   We put no requirements
 on the source address in order to avoid excessive gateway overhead.

 I would certainly agree with you and Vint that architecturally, a
 gateway that forwards such a datagram is in bad odor, but for
 efficiency reasons you may want to enforce this at the end host, not
 the gateway.
 
 Bob Braden
 

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 89 21:20:39 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   re: looking for reference to RDP


Rob Pickering:

RDP is Reliable Data Protocol (there is no such thing as a reliable
datagram).  RDP is documented in RFC-908.

--jon.

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 89 01:50:15 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Filter FTP traffic

In <2078@erix.ericsson.se> euarrd@euas12g.ericsson.se (Richard Rosenlund):
> I wish to know, how to restrict FTP access so that it would be possible
> to deny FTP "GET" requests from outside a network.

	The obvious way would be to hack your ftp server to look at the
address of the connected client and refuse to process GET requests if the
network didn't match your network.
-- 
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 89 07:34:57 GMT
From:      john@smosjc.UUCP (John Conover)
To:        comp.protocols.tcp-ip
Subject:   NCSC Sys V sources

Is the NCSC tcp-ip sources available for Sys V/386? If so, where?

Thanks a million,
	John
	..uunet!smosjc!john

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 89 14:42:28 GMT
From:      bryan@geo-works.UUCP (Bryan Ford)
To:        comp.protocols.tcp-ip
Subject:   Ignorant question - multiple connections within TCP ports?

I've been reading a book about the TCP/IP suite, and I have a question
(concern) about the TCP protocol.  It appears to me from reading this book
that you can have one separate TCP connection for each port on a single
host.  For example, if someone connects to port 2 on a host, someone else
can connect to port 3 on the same host, and have two independent
connections - correct?  However, is there a way that there can be more than
one connection to a single port?  For example, if someone connects to port
21 on a host to do some FTP stuff, then someone else tries to also connect
to port 21 on the same host while the first connection is still going, what
happens?  Does the request get denied, or does another FTP server process
get started up, or what?

I hope I've been clear enough.  I've been searching all over this book for
information on this, but can't find anything.

Thanks for your help!

				Bryan

--

     _______________________________________
   _/   Bryan Ford - bryan@geo-works.uucp   \_
 _/  ..!utah-cs!caeco!i-core!geo-works!bryan  \_
/ ..!uunet!iconsys!caeco!i-core!geo-works!bryan \

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 89 15:06:45 GMT
From:      rs@eddie.MIT.EDU (Robert E. Seastrom)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet 'null transceiver'?

In article <19719@louie.udel.EDU> grim@udel.EDU (Dan Grim) writes:
>rdn@chinet.chi.il.us (Richard Nichols) writes:
>
>>   <some stuff about hooking only a couple of machines together>
>>   <to form an Ethernet>
>
>Black Box sells two-port and four-port transceivers that can do exactly
>what you want for somewhat less money than DELNI-like devices (8-port).
>Here's the info:
>
>	NK-LE050A	2-port Ethernet Transceiver		$450
>	NK-LE051A	2-port BNC Transceiver			$450
>	NK-LE052A	4-port Ethernet Transceiver		$699
>	NK-LE053A	4-port BNC Transceiver			$699
>


OK,  so what's inside the box on one of these anyway?  Judging from
my previous experiences with Black Box, the fact that they sell them 
for $450 means you can probably whip one up for $100-$150.  So, what
makes one of these "ethernet-in-a-box"es work?  Is it just a passive
resistive network to keep the impedences looking OK to everyone?  Or
is it something active?  (I must confess, I forget whether a DELNI
has to plug into the wall, that would answer my question), but they warn
you about coupling too many DELNIs together in the wrong configuration, 
which would suggest to me that the guts are not all that complicated.

           ---Rob

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 89 18:04:17 GMT
From:      John_Robert_Breeden@cup.portal.com
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Info on twisted pair w/ voice/data

Has anyone out their had any experience with 10mb twisted pair ethernet
(ie;Synoptics, Cabletron, HP, UB, AT&T etc) co-existing with voice 
(ie: PBX and/or Centrex) in the same wire bundle (ie; voice/data in the same
4 pair PDS wiring or 25 pair).

I'm most interested in experience with Synoptics, I've been led to believe
that, because their signalling is only 1v pp that the Ring Indicator on the
voice circuit would drive it crazy.

Please e-mail to:

uunet!john_robert_breeden@cup.portal.com

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 89 20:35:00 GMT
From:      heker@JVNCA.CSC.ORG (Sergio Heker)
To:        comp.protocols.tcp-ip
Subject:   Re:  regional network for PA area?

George,

Both JvNCnet and PREPnet can provide you with Internet access in the 
Pennsylvania area.  The JvNCnet requires that your usage of the network be
for research purposes only.  

The NSF Network Service Center (NNSC) can provide you with contacts
information, they can be reached at "nnsc@nnsc.nsf.net".  

The JvNCnet network is installing a backbone node in Philadelphia this 
coming week.  The University of Pennsylvania and Penn State University both 
will be connected with T-1 lines to that backbone node (they are presently 
connected to the JvNCnet network with direct T-1 lines to JvNC in Princeton).
The backbone node in Philadelphia will be part of a ring of backbone nodes 
all connected with T-1 lines.  This is scheduled to be completed this summer
and is moving according to schedule.  The backbone nodes are co-located with 
the phone company point of presence in the cities of Philadelphia/PA, 
Trenton/NJ, Newark/NJ, NYC/NY, Stamford/CT, Providence/RI, Boston/MASS and 
at JvNC in Princeton.  

For more information on the JvNCnet network contact the JvNCnet network 
coordinator by e-mail at "nisc@nisc.jvnc.net" or by phone at (609) 520-2000.

					-- Sergio

-----------------------------------------------------------------------------
|		John von Neumann National Supercomputer Center		    |
|  Sergio Heker				tel:	(609) 520-2000		    |
|  Director for Networking		fax:	(609) 520-1089		    |
|  Internet: "heker@jvnca.csc.org"	Bitnet:	"heker@jvnc"		    |
 -----------------------------------------------------------------------------

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 89 21:15:32 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP performance

Some people have written me expressing surprise at my claim that 400KB/sec
is slow for process-to-process TCP/IP, or asking about ttcp.

The numbers one can obtain using port 7, "echo", or port 9, "discard",
depend strongly on how the sink or echoer is implemented.  For example, the
Silicon Graphics IRIS numbers improved significantly after inetd was tuned
up a bit.  After that exercise, I discarded my implementation of a "blast"
benchmark.

Ttcp is a user-process-to-user-process TCP and UDP benchmark from BRL.
Mike Muuss has given permission to distribute it.  It differs from some
other benchmarks such as at least some versions of "blast" by having both a
sender and a receiver.  A version of it is available via anonymous ftp from
sgi.com in sgi/src/ttcp.c.

For some reason, on this side of the Mountain View dump there are fewer
Sun workstations than those of another maker.  However, we have seen peak
averages of above 400KB/sec and well over 800KB/sec for pairs of the two
of Sun 4 models that were handy.  The graph for the faster, Sun 4/260, had
two valleys, but was otherwise flat for buffer sizes above 1KB.  We don't
have the latest Sun operating systems, but I not expect things to be
slower.

I do not know if Sun is using header prediction, but doubt it for several
nontechnical reasons.  Among technical reasons is that given a fast enough
cpu, you can execute a lot of protocol code and copy a lot of bytes in the
transmission time of an ethernet packet.

Of course, as with any benchmark, one should try ttcp many times and vary
its parameters to obtain a range of numbers.  We usually run a script
which take averages for each of about a dozen buffer sizes.  As always,
ttcp is a synthetic benchmark, less interesting than the target application
itself.  Given all of that, a factor of 2 above what some thought is the
state of the art is significant.  Please notice that at these speeds,
little else is happening on the ethernet in general and so specifically in
the network parts of the pair of hosts.  That makes ttcp reasonably
representative of real ethernet applications talking at maximum speed.

If you are buying a bridge or router, you might want to consider the
implications of >800KB/sec speeds between hosts upon the required speed of
the bridge.

To avoid being commercial, I won't mention the other workstation vendor's
numbers.


Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 89 22:23:07 GMT
From:      bzs@ENCORE.COM (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Ethernet 'null transceiver'?


>On the other hand,  if you can't do it a simple way, you could always
>purchase a DELNI (from Digital) or any other tap-expander,  which will
>simply look like 8 ethernet tranceivers.  You can hang a tap off the
>9th jack and plug it into a real thick wire ethernet,  or you can
>just flip a switch and have the DELNI look like the entire ethernet.
>
>If you'll only have those two machines, and you can't go in and mung
>them,  I'm afraid your cheapest alternative is probably buying two
>tranceivers and a 2 meter ethernet segment.  If you'll ever add on
>a third or fourth node,  go with the DELNI-type device.

Although DELNI type devices are always handy you can certainly hook
these two together a lot cheaper by just building a small ethernet.

You don't say if they're thick or thin net. If they're thin net you
only need about $50 worth of parts to hook it all together, two
terminators, two BNC T adaptors and a length of cable. If they're
thick you'll need the transceivers which will cost more like $250 each
plus terminators and cable (but still less than most DELNI type things
which cost around $2K.) I still agree the DELNI is nicer if you can
afford it.

What I'm curious about in this regard is twisted pair stuff. I saw a
thick-net to twisted pair (RJ11) adapter for $90. Is it possible to
string two of these together back to back to make a simple net
connection?  A thin-net to RJ11 is about $35, could one of each be
used to put a thick-net device into a thin-net? I guess I'm not up to
speed at all on twisted-pair cabling so forgive any silliness.

	-Barry Shein

Software Tool & Die, Purveyors to the Trade
1330 Beacon Street, Brookline, MA 02146, (617) 739-0202

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 89 23:11:05 GMT
From:      eshop@saturn.ucsc.edu (Jim Warner)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet 'null transceiver'?

In article <12222@eddie.MIT.EDU> rs@eddie.MIT.EDU (Robert E. Seastrom) writes:
>In article <19719@louie.udel.EDU> grim@udel.EDU (Dan Grim) writes:
>>rdn@chinet.chi.il.us (Richard Nichols) writes:
>>
>>>   <some stuff about hooking only a couple of machines together>
>>>   <to form an Ethernet>
>>
>>Black Box sells two-port and four-port transceivers that can do exactly
>>what you want for somewhat less money than DELNI-like devices (8-port).
>>Here's the info:
>>
>>	NK-LE050A	2-port Ethernet Transceiver		$450
>>	NK-LE051A	2-port BNC Transceiver			$450
>
>OK,  so what's inside the box on one of these anyway?  Judging from
>my previous experiences with Black Box, the fact that they sell them 
>for $450 means you can probably whip one up for $100-$150.
===================

Black box is in the business of selling solutions to problems.  Sure.
If you know what you're doing you could make one of these for less
money.

There are active components inside the box.  They are required because
Ethernet interfaces expect to see an echo of their signal come back
when they transmit.  Logic inside the box has to decide which signal
to gate through in _both_ directions.

I don't know what other folks are paying for their thin net transceivers.
We get ours for about $130 each.  Add $14 for a pair of terminators and
$5 for a short BNC cable.  It comes out to be less expensive than the
Black Box solution by about $170.  

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 89 23:49:51 GMT
From:      hwb@MERIT.EDU (Hans-Werner Braun)
To:        comp.protocols.tcp-ip
Subject:   Re:  Routing loop, congestion, or what?


> (BTW: our nameserver seems to be unable to find names for the 129.140
> hosts in these paths; is no one in the DNS providing those PTRs?)

Brian:

We set up some servers the other day for the 129.140 in-addr domain and
asked the SRI-NIC to add them to the root server, which should happen this
coming week. I would like to point out, though, that this was done in
response to friendly private suggestions from some sites to us and not to 
requests on public mailing lists. Generally, if you see problems like the
one you have mentioned in your message (the routing problem) you should
be able to rely on your local regional network (SDSC? CERFNET?) to get 
it forwarded and fixed, even if the problem is not local to the regional
network you are connecting through. The person(s) responsible for your 
campus network should know the people responsible for the regional network 
which they connect through.

	-- Hans-Werner

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 89 06:09:49 GMT
From:      root@swituc.UUCP (Admin)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet 'null transceiver'?

In article <19719@louie.udel.EDU>, grim@udel.EDU (Dan Grim) writes:
> rdn@chinet.chi.il.us (Richard Nichols) writes:
> 
> Black Box sells two-port and four-port transceivers that can do exactly

We use these when we want a very small network (2 to 4 machines) with
no outside world connections, such as a "secure" development group.
They work completely satisfactorily and can be used to tie into the
larger Ethernet systems when desired.

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 89 07:14:32 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  relative importance

Paul,

Truechimer clepsydra.dec.com (16.1.0.4) popped out of the swamps, so I
assume your gateways are compis, if not mentis; however, the path from
here (UDel) to there is rather awful, with delays running to the seconds.
It seems our paths via NSFNET are bogonite thus now, so I can report the
paths via ARPANET are hilarious, to say the most. Meanwhile, give thanks
you have your own GOES radio, since your friends out here are too noisy
to help.

Dave

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 89 12:40:50 GMT
From:      sob@harvisr.harvard.edu (Scott Bradner)
To:        comp.protocols.tcp-ip
Subject:   router testing

Newsgroups: comp.dcom.lans
Subject: router testing
Expires: 
References: 
Sender: 
Reply-To: sob@harvisr.UUCP (Scott Bradner)
Followup-To: 
Distribution: 
Organization: Harvard University, Cambridge MA
Keywords: 

We are about to do more of the router testing that we did a while
ago.  I got a number of comments back after posting the last results
pointing out tests we should have done etc.  This time, I'd like
to get the comments up front so the tests will provide as much
information as possible.  

Here is an outline of the tests we have been thinking of, if you
see problems with any of them or would like to suggest others
please send me mail.

The routers that we expect to test this time are: cisco, Wellfleet,
Proteon and "brand X" not yet announced.  If you know of others
that we should also be testing please let me know.

Yes - the results of the tests along with a description of
the tests and test setup will be posted when the tests are finished.

Scott Bradner
Harvard University

sob@harvard.harvard.edu


1/ raw speed
	evenly spaced packets sent through the router - all to same dest
	within trial, all packets are the same size
	change sizes between trials
	a trial is to find max throughput for condition
	a set of trials checks the effect of changing router setups
		"normal"
		enable specific routes - vary # of routes enabled
		disable specific routes - vary # of routes disabled
		enable/disable protocols
		router mode - routing/bridgeing
	check router counters for accurate counts
	what happens to router when max throughput reached, can
		one still talk to processor? what do counters show?

2/ raw speed contd
	same as #1 but additional dest on same or different output port(s)
	check for effect

3/ broadcast
	#1 but add broadcast packets - check for effect

4/ back-to-back packets
	send n back to back packets with large gap to next batch
		see how many will be ok
	what errors (if any) show up in router counters

5/ background
	what is "idle" state, how many (if any) packets does router
	send out in "idle" state.

6/ errors
	send bad packets (bad crc etc) mixed with legit data through
	router, check for effect on throughput and counters
	does router toss all bad packets?

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 89 14:47:52 GMT
From:      gkrishn@izzy.eng.clemson.edu (Krishnan Gopalan)
To:        comp.protocols.tcp-ip
Subject:   mailing list


____________________________________________________________________________
					gkrishn@eng.clemson.edu
					gkrishn@hubcap.clemson.edu
____________________________________________________________________________

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 89 14:52:13 GMT
From:      erik@mpx2.mpx.com (Erik Murrey)
To:        comp.protocols.tcp-ip
Subject:   TCP header prediction

All this talk about TCP throughput keeps mentioning TCP header prediction.
Can someone point me to an RFC on this?  I'm porting TCP/IP right now, but
haven't gotten to TCP yet.

Thanks,
... Erik


-- 
Erik Murrey                            /|   //  /~~~~/  |  /
MPX Data Systems, Inc.                / | / /  /____/   |/
erik@mpx.com                         /  /  /  /        /|  Data Systems, Inc. 
{vu-vlsi, bpa, cbmvax}!mpx1!erik    /     /  /       /  |====================

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 89 17:34:02 GMT
From:      heker@JVNCA.CSC.ORG (Sergio Heker)
To:        comp.protocols.tcp-ip
Subject:   Re:  Routing loop, congestion, or what?

Brian,

Thank you for the detailed information on your message.  Certainly 
traceroute is a great debugging tool.

I received your message today regarding the problems to reach the JANET
network, and when looking at the date of your log is Mon Jul 10.  Almost
a week ago.

After checking our Cisco/syslog messages I didn't find any reference of
any entry for that date and timestamp that can correlate to the problem
that you are pointing at.  When looking at SNMP information that we
collect in all our Cisco gateways (we have 30 operational and 14 more
that are being installed) the findings are a high number of input
errors coming from the ARPANET (Zaphod and Ford are directly on the
ARPANET), plus errors from one of the ethernets that connects both
routers.  Of course to analyze a problem that was sampled for less than
two minutes, six days ago is hard if not impossible due to the dynamic
nature of the network.

Two comments about this.  The first one is that as soon as you notice
a problem like this, please notify us immediately.  You can do that
by phone (609) 520-2000, or by e-mail "JVNCnet-noc@jvnca.csc.org". We
operate the network 24 hours/7 days a week.
The second thing, is the ability to resolve names for the JANET domains,
we have been discussing the posibility of backing up those domains in
the US.  If we do that, the we will have resolved at least the name
server part.  As for the routing loop, we will try to make sense of the
stats that we have to better understand why the routing loop happened
in the first place, but the best way to deal with it is to work on the
problem when the problem is happening.

Again, thank you very much for your effort to isolate the problem by
yourself, and our appologies for not having been of much help to you
until know.  Let us help you in the future if you have a problem again.

					-- Sergio




-----------------------------------------------------------------------------
|		John von Neumann National Supercomputer Center		    |
|  Sergio Heker				tel:	(609) 520-2000		    |
|  Director for Networking		fax:	(609) 520-1089		    |
|  Internet: "heker@jvnca.csc.org"	Bitnet:	"heker@jvnc"		    |
-----------------------------------------------------------------------------

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 89 17:56:30 GMT
From:      tjs@UF.MSC.UMN.EDU ("Tim Salo")
To:        comp.protocols.tcp-ip
Subject:   X.3/Telnet Gateway Wanted


          Effective X.3/Telnet Gateway for Unix Desired
          ---------------------------------------------

Overview
--------

This note describes the need for a gateway which would enable
asynchronous devices attached to X.25 networks to communicate
effectively with Unix hosts using Telnet.  The gateway should
translate between X.3/X.25 and Telnet/TCP/IP protocols.  
Furthermore, the gateway should use one-character X.25 packets
when required and one-line X.25 packets with local echoing when
possible.  This note assumes that Line Mode Telnet is available.

I am looking for people with experience with or opinions about
such a gateway.  Additionally, I would like to know whether
anyone has or plans to develop, or has interest in working on, an
RFC for or prototype implementation of such a gateway.  I will
summarize the responses.


X.3/Telnet Gateway Requirement
------------------------------

The configuration of the desired X.3/Telnet Gateway is shown
below.  The X.3 PAD, X.25 Packet-Switched Data Network and
Telnet Host are existing products.  The X.3/Telnet Gateway is the
product which is desired.

                     ........
        ______      .        .      ______________     _______
       |      |    .          .    |              |   | Telnet|
TTY ___| X.3  |___.    X.25    .___|  X.3/Telnet  |   | (Unix)|
     ^ | PAD  | ^  .   PSDN   .  ^ |    Gateway   |   |  Host |
     ^ |______| ^   .        .   ^ |______________|   |_______|
     ^          ^    ........    ^           |            |
   async       X.25             X.25         |            |
                                             |            |
                   Telnet/TCP/IP (ethernet)  |            |
                   =============================================

                X.3/Telnet Gateway Configuration


The X.3/Telnet Gateway should map between telnet connections and
X.3 connections, including X.3 SET PAD PARAMETERS and telnet
option negotiations.  The X.3/Telnet Gateway must work well with
Unix hosts.

1.   Efficient use should be made of the X.25 network; local
     echoing at the X.3 PAD and large packets should be used when
     possible.

2.   Effective support for Unix software which relies upon one-
     character-at-a-time communications and echoing by the Unix
     user program should be provided.  Programs such as "vi",
     "less", and "more" should operate, from the perspective of
     the terminal user, the same as if the terminal were directly
     attached to the Unix host.

3.   The gateway should automatically switch the X.3 PAD between
     line-at-a-time and character-at-a-time communications.  It
     is assumed that Line Mode Telnet is available on the Unix
     host to signal the gateway, through the telnet protocol,
     when the user software moves into and out of character-at-
     a-time communications.  The gateway, upon receipt of an
     indication that the user software in entering character-at-
     a-time communications, should issue SET PAD PARAMETER
     packets to the remote X.3 PAD to prepare it for one-
     character X.25 packets.  Upon receipt of an indication of
     line-at-a-time communications, the gateway should issue SET
     PAD PARAMETERS to prepare the remote PAD forward at the end
     of a line and to echo locally.


Proposed X.3/Telnet Gateway Architecture
----------------------------------------

The X.3/Telnet Gateway should be a combined X.3 PAD and telnet
client.  The telnet client and Unix host must implement the Line
Mode Telnet option to provide signalling of the movement of the
Unix user software in and out of character-at-a-time mode.


                     X.3/Telnet Gateway    Unix Host
                    ___________________     _______________ 
                   |   |   | G |   |   |   |   |   |   | U |
        _____      |   |   | a | T | T |   | T | T | K | s |
       |     |     | X | X | t | e | C |   | C | e | e | e |
TTY ___| X.3 |_____| . | . | e | l | P |   | P | l | r | r |
     ^ | PAD | ^   | 2 | 3 | w | n | / |   | / | n | n |   |
     ^ |_____| ^   | 5 |   | a | e | I |   | I | e | e | S |
     ^    |    ^   |   |   | y | t | P |   | P | t | l | W |
   async  |  X.25  |___|___|___|___|___|   |___|___|___|___|
          |______________|   ^   |   |_______|   |    
              X.3/X.28       ^   |     TCP/IP    |
                             ^   |_______________|
                             ^   Telnet (line mode)
                             ^
                      X.3/Telnet Gateway
                        Functionality

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

Feel free to send comments to:

Tim Salo
Minnesota Supercomputer Center
tjs@msc.umn.edu
(612) 626-0347

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jul 89 05:19:15 PDT
From:      ballard@trout.nosc.mil (Constance M. Ballard)
To:        tcp-ip@sri-nic.arpa
Subject:   Removal from Mailing List
-------
Please remove me from the TCP-IP mailing list.

Thank you,
Coni Ballard
@nosc.mil
-------

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 89 07:57:00 EDT
From:      "VAXB::DBURKE" <dburke%vaxb.decnet@nusc-npt.navy.mil>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Mac/SE << cheap >> TCP/IP
Date sent:  17-JUL-1989 07:59:48 

Hi all,
	What is the "cheapest" way to put a single Mac/SE on to Ethernet for 
common TCP/IP functions (ie. file xfer, printing, etc.).  I will consider a 
gateway if the price is right.  

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

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 89 11:38:13 GMT
From:      HANK@TAUNIVM.BITNET (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Revision of PC/IP scorecard

People have asked and I have postponed it, but I now have a couple of hours
on the horizon so here goes:

I have decided to invest 3 weeks to update the scorecard that I last
circulated a year ago.  Please do not send updates yet.  Just send me your
ideas for what needs to be added (or deleted) to the scorecard - new functions,
new Ethernet cards, etc.  I will accept comments for revision until
July 23.  On the 23rd or 24th I will come out with a new table and
will request people to then send me their updates for the scrorecard.
The new scorecard will be posted on August 3rd as revision #7.

Please send me now your comments for additions.  Please reply directly to
me since I am not subscribed to your list.

Thanks,
Hank
                         The Pc/Ip Scorecard
                        revision 6:  07/28/88
                        ---------------------

    This scorecard will  be like a  PC Magazine analysis  of of hard
disks or printers.  But  I need help in  filling in the boxes.   So,
here is what the scorecard looks like.  Please send me your  replies
and  I  will  integrate  all  answers  and  comments and publish the
finalized scorecard in the weeks to come.

    This first table is called "Must Have".

Vendor        TFTP SMTP VT-  3270 FTP  max  cost
                         100      Clnt FTP  ($)
-------------+----+----+----+----+----+----+----+----
Beame        | Yes| No | Yes| No | Yes| 75k|    |
Cornell      |  No| No | No | Yes| No |    |  25|site
CMU          | Yes| No | No | No | No |    |   0|
Excelan 3.3  | No | No | Yes| No | Yes| 88k| 250|cpu
FTP  2.02    | Yes| Yes| Yes| Yes| Yes|114k| 400|cpu
FUSION 3.2   | Yes| Yes| Yes| No | Yes| 85k| 300|
IBM  V1.1    | Yes| Yes| No | Yes| Yes| 90k| 200|cpu
KA9Q         | No | Yes| No | No | Yes| 74k|   0|
MIT          | Yes| No | No | No | No |    |  50|site
NCSA  V2.2   | No | No | Yes| No | Yes|    |   0|
Stanford 3.0 | No | Yes| Yes| No | Yes|    | 100|site
SUN PC-NFS   | No |Xtra| Yes| No | Yes|167k| 395|cpu
UB           |    | No | No | No | Yes|    | 495|cpu
WIN/TCP 3.2  | Yes| Yes| Yes| No | Yes|200k| 395|cpu

Notes: 1) All versions must support ARP, ICMP and UDP
       2) max FTP is for the fastest FTP to a PC (*not* from) in
          Kbytes/sec.  The sending machine can be any machine.
          The origin and destination of the FTP must be disk or
          ramdisk.  NUL is not a valid destination.

    The  following  table  lists  the  most  popular  Ethernet cards
available and whether the Pc/Ip implementation works with the stated
card.

Vendor      3com  Excelan  Inter   UB    WD   3Com  UB NIC  3com  MICOM
            3C501 EXOS205  NI5010 2273A 8003  3C523  PS/2   3C503 NI5210
-----------+-----+--------+------+-----+-----+-----+------+------+------+
Beame      | Yes |  No    |  No  | No  | No  | No  | No   | No   | No
Cornell    | Yes |  No    |  No  | No  | No  | No  | No   | No   | No
CMU        | Yes |  No    |  Yes | No  | Yes | No  | No   | No   | No
Excelan    | No  |  Yes   |  No  | No  | No  | No  | No   | No   | No
FTP        | Yes |  Yes   |  Yes | Yes | Yes | Yes | No   | Yes  | Yes
FUSION     | Yes |  No    |  Yes | No  | Yes | No  | No   |      | Yes
IBM        | Yes |  No    |  No  | Yes | No  | No  | Yes  | No   | No
KA9Q       | Yes |  No    |  No  | No  | No  | No  | No   |      | Yes
MIT        | Yes |  No    |  Yes | No  | No  | No  | No   |      |
NCSA       | Yes |  No    |  No  | Yes | Yes | No  | No   | No   | Yes
Stanford   | Yes |  No    |  No  | No  | Yes | Yes |      | Yes  |
Sun        | Yes |  No    |  Yes | Yes | Yes | Yes | No   | Yes  | Yes
UB         | No  |  Yes   |  No  | Yes | No  | No  | Yes  |      |
Wollongong | Yes |  No    |  Yes | No  | No  | Yes | No   | Yes  | No

    This table is  called the "Nice  to Have" table.   The functions
listed  here  are  not  mandatory   but  are  useful  in  a   Tcp/Ip
environment:

            domn time fing whoi NFS  gate srce Net- ping SLIP POP
Vendor      name srvr                way  code BIOS
            srvr                               1001
-----------+----+----+----+----+----+----+----+----+----+----+----+----+
Beame      | Yes| Yes| Yes| No | No | No | No | No | No | No | No |    |
Cornell    |  No|  No|  No| No | No | No | No | No | Yes| No | No |    |
CMU        | Yes| Yes| Yes| No | No | No | Yes| No | Yes| Yes| No |    |
Excelan    | No | No | No | No | No | No | No | Yes| No | No | No |    |
FTP        | Yes| Yes| Yes| Yes| No | No |Xtra|Xtra| Yes| Yes| No |    |
FUSION     | No | Yes| Yes| Yes| No | No | Yes| No | Yes| No | No |    |
IBM        | Yes| Yes| Yes| Yes| No | Yes| Yes| No | Yes| No | Yes|    |
KA9Q       | No | No | No | No | No | Yes| Yes| No | Yes| Yes| No |    |
MIT        | Yes| Yes| Yes| Yes| No | No | Yes| No | Yes| No | No |    |
NCSA       | Yes| No | No | No | No | Yes| Yes|    | Yes| No | No |    |
Stanford   | No | Yes| Yes| Yes| No | No | No |    | Yes| No | Yes|    |
Sun        | Yes| No | No | No | Yes| No |Xtra| No | Yes| Yes|Xtra|    |
UB         | Yes| No |    |    | No | Yes| No | Yes| Yes| No |    |    |
Wollongong | No | No | No | No | No | Yes| No | No | Yes| No | No |    |

Notes: 1) POP refers to RFC937
       2) gateway refers to IP forwarding capability

FTP Software is OEMed to BICC Data Networks, Fibronics, Proteon, cisco,
Spider Systems, MICOM-Interlan, Scope, Univation and Western Digital.

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 89 11:57:00 GMT
From:      dburke%vaxb.decnet@NUSC-NPT.NAVY.MIL ("VAXB::DBURKE")
To:        comp.protocols.tcp-ip
Subject:   Mac/SE << cheap >> TCP/IP

Date sent:  17-JUL-1989 07:59:48 

Hi all,
	What is the "cheapest" way to put a single Mac/SE on to Ethernet for 
common TCP/IP functions (ie. file xfer, printing, etc.).  I will consider a 
gateway if the price is right.  

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

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 89 12:19:15 GMT
From:      ballard@TROUT.NOSC.MIL (Constance M. Ballard)
To:        comp.protocols.tcp-ip
Subject:   Removal from Mailing List

-------
Please remove me from the TCP-IP mailing list.

Thank you,
Coni Ballard
@nosc.mil
-------

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 89 12:34:02 GMT
From:      adnan@sgtech.UUCP (Adnan Yaqub)
To:        comp.protocols.tcp-ip
Subject:   Re: CRC calc for Ethernet; How?

I asked a similar question awhile ago and was sent some `C' code.
This code uses a trick which allows on to due 8 bits at a time.  Based
on the next character received, one can look in a table to find out
what the CRC is supposed to look like (more or less).  The trick is as
follows:
	crc = (crc_32_tab[((crc) ^ (octet)) & 0xff] ^ ((crc) >> 8));
I've enclosed the code at the end of this letter.

Adnan Yaqub
Star Gate Technologies, 29300 Aurora Rd., Solon, OH, USA, +1 216 349 1860
...uunet!abvax!sgtech!adnan

/*% cc -O -K -dos % -o crc.exe
*/

/*
 *  Crc - 32 BIT ANSI X3.66 CRC checksum files
 */
#include <stdio.h>
#define OK 0
#define ERROR (-1)
#define LINT_ARGS

/**********************************************************************\
|*                                                                    *|
|* Demonstration program to compute the 32-bit CRC used as the frame  *|
|* check sequence in ADCCP (ANSI X3.66, also known as FIPS PUB 71     *|
|* and FED-STD-1003, the U.S. versions of CCITT's X.25 link-level     *|
|* protocol).  The 32-bit FCS was added via the Federal Register,     *|
|* 1 June 1982, p.23798.  I presume but don't know for certain that   *|
|* this polynomial is or will be included in CCITT V.41, which        *|
|* defines the 16-bit CRC (often called CRC-CCITT) polynomial.  FIPS  *|
|* PUB 78 says that the 32-bit FCS reduces otherwise undetected       *|
|* errors by a factor of 10^-5 over 16-bit FCS.                       *|
|*                                                                    *|
\**********************************************************************/

/* Need an unsigned type capable of holding 32 bits; */
typedef unsigned long int UNS_32_BITS;

/*
 * Copyright (C) 1986 Gary S. Brown.  You may use this program, or
 * code or tables extracted from it, as desired without restriction.
 */
/* First, the polynomial itself and its table of feedback terms.  The  */
/* polynomial is                                                       */
/* X^32+X^26+X^23+X^22+X^16+X^12+X^11+X^10+X^8+X^7+X^5+X^4+X^2+X^1+X^0 */
/* Note that we take it "backwards" and put the highest-order term in  */
/* the lowest-order bit.  The X^32 term is "implied"; the LSB is the   */
/* X^31 term, etc.  The X^0 term (usually shown as "+1") results in    */
/* the MSB being 1.                                                    */

/* Note that the usual hardware shift register implementation, which   */
/* is what we're using (we're merely optimizing it by doing eight-bit  */
/* chunks at a time) shifts bits into the lowest-order term.  In our   */
/* implementation, that means shifting towards the right.  Why do we   */
/* do it this way?  Because the calculated CRC must be transmitted in  */
/* order from highest-order term to lowest-order term.  UARTs transmit */
/* characters in order from LSB to MSB.  By storing the CRC this way,  */
/* we hand it to the UART in the order low-byte to high-byte; the UART */
/* sends each low-bit to hight-bit; and the result is transmission bit */
/* by bit from highest- to lowest-order term without requiring any bit */
/* shuffling on our part.  Reception works similarly.                  */

/* The feedback terms table consists of 256, 32-bit entries.  Notes:   */
/*                                                                     */
/*  1. The table can be generated at runtime if desired; code to do so */
/*     is shown later.  It might not be obvious, but the feedback      */
/*     terms simply represent the results of eight shift/xor opera-    */
/*     tions for all combinations of data and CRC register values.     */
/*                                                                     */
/*  2. The CRC accumulation logic is the same for all CRC polynomials, */
/*     be they sixteen or thirty-two bits wide.  You simply choose the */
/*     appropriate table.  Alternatively, because the table can be     */
/*     generated at runtime, you can start by generating the table for */
/*     the polynomial in question and use exactly the same "updcrc",   */
/*     if your application needn't simultaneously handle two CRC       */
/*     polynomials.  (Note, however, that XMODEM is strange.)          */
/*                                                                     */
/*  3. For 16-bit CRCs, the table entries need be only 16 bits wide;   */
/*     of course, 32-bit entries work OK if the high 16 bits are zero. */
/*                                                                     */
/*  4. The values must be right-shifted by eight bits by the "updcrc"  */
/*     logic; the shift must be unsigned (bring in zeroes).  On some   */
/*     hardware you could probably optimize the shift in assembler by  */
/*     using byte-swap instructions.                                   */

static UNS_32_BITS crc_32_tab[] = { /* CRC polynomial 0xedb88320 */
0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988, 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de, 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, 0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5,
0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172, 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940, 0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116, 0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f,
0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924, 0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d,
0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a, 0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818, 0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e, 0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457,
0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c, 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2, 0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb,
0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0, 0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9,
0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086, 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4, 0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad,
0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a, 0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683,
0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8, 0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe, 0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7,
0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc, 0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252, 0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,
0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60, 0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79,
0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236, 0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f,
0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04, 0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d,
0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a, 0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38, 0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21,
0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e, 0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,
0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c, 0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45,
0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2, 0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db,
0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0, 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6, 0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf,
0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94, 0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d
};

#define UPDC32(octet, crc) (crc_32_tab[((crc) ^ (octet)) & 0xff] ^ ((crc) >> 8))

main(argc, argp)
char **argp;
{
	register errors = 0;

	while( --argc > 0)
		errors |= crc32file( *++argp);
	exit(errors != 0);
}

crc32file(name)
char *name;
{
	register FILE *fin;
	register unsigned long oldcrc32;
	register unsigned long crc32;
	register unsigned long oldcrc;
	register c;
	register long charcnt;

	oldcrc32 = 0xFFFFFFFF; charcnt = 0;
#ifdef M_I86SM
	if ((fin=fopen(name, "rb"))==NULL)
#else
	if ((fin=fopen(name, "r"))==NULL)
#endif
	{
		perror(name);
		return ERROR;
	}
	while ((c=getc(fin))!=EOF) {
		++charcnt;
		oldcrc32 = UPDC32(c, oldcrc32);
	}

	if (ferror(fin)) {
		perror(name);
		charcnt = -1;
	}
	fclose(fin);

	crc32 = oldcrc32;  oldcrc = oldcrc32 = ~oldcrc32;

/*
	crc32 = UPDC32((oldcrc32 & 0377), crc32);  oldcrc32 >>=8;
	crc32 = UPDC32((oldcrc32 & 0377), crc32);  oldcrc32 >>=8;
	crc32 = UPDC32((oldcrc32 & 0377), crc32);  oldcrc32 >>=8;
	crc32 = UPDC32((oldcrc32 & 0377), crc32);  oldcrc32 >>=8;
	printf("%08lX ", crc32);
*/

	printf("%08lX %7ld %s\n", oldcrc, charcnt, name);

	return OK;
}

--
Adnan Yaqub
Star Gate Technologies, 29300 Aurora Rd., Solon, OH, USA, +1 216 349 1860
...uunet!abvax!sgtech!adnan

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 89 14:12:26 GMT
From:      paul@ppgbms (Paul Evan Matz)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Looking for any public domain network diagnostic/monitor tools


	I was wondering if someone out there could recommend any good
network diagnostic tools that run on a PC or a Sun, either for cash or
public domain.  I have heard that some things from CMU and MIT exist,
but have no details.  Monitoring of packet sources and destinations,
of various types of protocol, might be handy.  Any tips would be much
appreciated.  (I have played with Sun's traffic program, but it doesn't
seems to do much with packets of the ipx [netware] protocol variety).

	Thanks (wishful thinking)
	Regards,

	Paul Matz
	PPG Biomedical Systems
	One Campus Drive
	Pleasantville, NY. 10570
	914-741-4685
	path ppgbms!moe!paul@philabs.philips.com

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 89 14:25:08 GMT
From:      chris@SALT.ACC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   SNMP list?

Good morning all,
		I was wondering if someone knew about an SNMP mail list and
where I would send to subscribe to it?
			Thanks in advance,
					  Chris VandenBerg
					  (chris@salt.acc.com)
					  (805) 963-9431

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jul 89 11:47:06 IST
From:      Hank Nussbacher <HANK%TAUNIVM.BITNET@CUNYVM.CUNY.EDU>
To:        PC/IP Forum <pcip@louie.udel.EDU>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Revision of PC/IP scorecard
People have asked and I have postponed it, but I now have a couple of hours
on the horizon so here goes:

I have decided to invest 3 weeks to update the scorecard that I last
circulated a year ago.  Please do not send updates yet.  Just send me your
ideas for what needs to be added (or deleted) to the scorecard - new functions,
new Ethernet cards, etc.  I will accept comments for revision until
July 23.  On the 23rd or 24th I will come out with a new table and
will request people to then send me their updates for the scrorecard.
The new scorecard will be posted on August 3rd as revision #7.

Please send me now your comments for additions.  Please reply directly to
me since I am not subscribed to your list.

Thanks,
Hank
                         The Pc/Ip Scorecard
                        revision 6:  07/28/88
                        ---------------------

    This scorecard will  be like a  PC Magazine analysis  of of hard
disks or printers.  But  I need help in  filling in the boxes.   So,
here is what the scorecard looks like.  Please send me your  replies
and  I  will  integrate  all  answers  and  comments and publish the
finalized scorecard in the weeks to come.

    This first table is called "Must Have".

Vendor        TFTP SMTP VT-  3270 FTP  max  cost
                         100      Clnt FTP  ($)
-------------+----+----+----+----+----+----+----+----
Beame        | Yes| No | Yes| No | Yes| 75k|    |
Cornell      |  No| No | No | Yes| No |    |  25|site
CMU          | Yes| No | No | No | No |    |   0|
Excelan 3.3  | No | No | Yes| No | Yes| 88k| 250|cpu
FTP  2.02    | Yes| Yes| Yes| Yes| Yes|114k| 400|cpu
FUSION 3.2   | Yes| Yes| Yes| No | Yes| 85k| 300|
IBM  V1.1    | Yes| Yes| No | Yes| Yes| 90k| 200|cpu
KA9Q         | No | Yes| No | No | Yes| 74k|   0|
MIT          | Yes| No | No | No | No |    |  50|site
NCSA  V2.2   | No | No | Yes| No | Yes|    |   0|
Stanford 3.0 | No | Yes| Yes| No | Yes|    | 100|site
SUN PC-NFS   | No |Xtra| Yes| No | Yes|167k| 395|cpu
UB           |    | No | No | No | Yes|    | 495|cpu
WIN/TCP 3.2  | Yes| Yes| Yes| No | Yes|200k| 395|cpu

Notes: 1) All versions must support ARP, ICMP and UDP
       2) max FTP is for the fastest FTP to a PC (*not* from) in
          Kbytes/sec.  The sending machine can be any machine.
          The origin and destination of the FTP must be disk or
          ramdisk.  NUL is not a valid destination.

    The  following  table  lists  the  most  popular  Ethernet cards
available and whether the Pc/Ip implementation works with the stated
card.

Vendor      3com  Excelan  Inter   UB    WD   3Com  UB NIC  3com  MICOM
            3C501 EXOS205  NI5010 2273A 8003  3C523  PS/2   3C503 NI5210
-----------+-----+--------+------+-----+-----+-----+------+------+------+
Beame      | Yes |  No    |  No  | No  | No  | No  | No   | No   | No
Cornell    | Yes |  No    |  No  | No  | No  | No  | No   | No   | No
CMU        | Yes |  No    |  Yes | No  | Yes | No  | No   | No   | No
Excelan    | No  |  Yes   |  No  | No  | No  | No  | No   | No   | No
FTP        | Yes |  Yes   |  Yes | Yes | Yes | Yes | No   | Yes  | Yes
FUSION     | Yes |  No    |  Yes | No  | Yes | No  | No   |      | Yes
IBM        | Yes |  No    |  No  | Yes | No  | No  | Yes  | No   | No
KA9Q       | Yes |  No    |  No  | No  | No  | No  | No   |      | Yes
MIT        | Yes |  No    |  Yes | No  | No  | No  | No   |      |
NCSA       | Yes |  No    |  No  | Yes | Yes | No  | No   | No   | Yes
Stanford   | Yes |  No    |  No  | No  | Yes | Yes |      | Yes  |
Sun        | Yes |  No    |  Yes | Yes | Yes | Yes | No   | Yes  | Yes
UB         | No  |  Yes   |  No  | Yes | No  | No  | Yes  |      |
Wollongong | Yes |  No    |  Yes | No  | No  | Yes | No   | Yes  | No

    This table is  called the "Nice  to Have" table.   The functions
listed  here  are  not  mandatory   but  are  useful  in  a   Tcp/Ip
environment:

            domn time fing whoi NFS  gate srce Net- ping SLIP POP
Vendor      name srvr                way  code BIOS
            srvr                               1001
-----------+----+----+----+----+----+----+----+----+----+----+----+----+
Beame      | Yes| Yes| Yes| No | No | No | No | No | No | No | No |    |
Cornell    |  No|  No|  No| No | No | No | No | No | Yes| No | No |    |
CMU        | Yes| Yes| Yes| No | No | No | Yes| No | Yes| Yes| No |    |
Excelan    | No | No | No | No | No | No | No | Yes| No | No | No |    |
FTP        | Yes| Yes| Yes| Yes| No | No |Xtra|Xtra| Yes| Yes| No |    |
FUSION     | No | Yes| Yes| Yes| No | No | Yes| No | Yes| No | No |    |
IBM        | Yes| Yes| Yes| Yes| No | Yes| Yes| No | Yes| No | Yes|    |
KA9Q       | No | No | No | No | No | Yes| Yes| No | Yes| Yes| No |    |
MIT        | Yes| Yes| Yes| Yes| No | No | Yes| No | Yes| No | No |    |
NCSA       | Yes| No | No | No | No | Yes| Yes|    | Yes| No | No |    |
Stanford   | No | Yes| Yes| Yes| No | No | No |    | Yes| No | Yes|    |
Sun        | Yes| No | No | No | Yes| No |Xtra| No | Yes| Yes|Xtra|    |
UB         | Yes| No |    |    | No | Yes| No | Yes| Yes| No |    |    |
Wollongong | No | No | No | No | No | Yes| No | No | Yes| No | No |    |

Notes: 1) POP refers to RFC937
       2) gateway refers to IP forwarding capability

FTP Software is OEMed to BICC Data Networks, Fibronics, Proteon, cisco,
Spider Systems, MICOM-Interlan, Scope, Univation and Western Digital.
-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 89 15:36:19 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Filter FTP traffic

In article <3865@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>In response to euarrd@euas12g.ericsson.se (Richard Rosenlund):
>> I wish to know, how to restrict FTP access so that it would be possible
>> to deny FTP "GET" requests from outside a network.
>
>	The obvious way would be to hack your ftp server to look at the
>address of the connected client and refuse to process GET requests if the
>network didn't match your network.
>-- 
	Pardon me if I am really dense, but can't unauthorized GETs be
avoided by requiring USER and PASSWORD?

	If you require login, you don't have to do source address
checking on GET requests.  It is more efficient to stop FTPs at
initiation. 

	You can disable anonymous FTP or do source address checking at
login where USER is "anonymous".

	Routers aren't very good at limiting access by source address
checking so long as they are *required* to support source routing.
Hosts aren't very good either, if they don't tell applications like
FTP about IP options like "source-routed".

	--Kent England

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 89 16:43:52 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   traceroute + map


just how many different routes are there? and who has the maps?

If i cannot reach somewhere,
i'd like to feed a network map to a program, run traceroute and feed
its output to the program, and get a list of probable network/gateway
failures out (starting with most likely, decreasing (i.e. apply occams
razor - first the most likely failure is the nearest hop on the
'normal' route that i didnt take, the next is that plus the next
shortest/congested 1 or more routes both failed, and so on)
 - obviously generating this for all cases for all src/dst pairs is
ooq (out of the question) but on the fly when the fly on the wall is
in the ointment would be handy - is this a (np) hard problem?


jon 

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jul 89 17:43:52 +0100
From:      Jon Crowcroft <J.Crowcroft@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   traceroute + map

just how many different routes are there? and who has the maps?

If i cannot reach somewhere,
i'd like to feed a network map to a program, run traceroute and feed
its output to the program, and get a list of probable network/gateway
failures out (starting with most likely, decreasing (i.e. apply occams
razor - first the most likely failure is the nearest hop on the
'normal' route that i didnt take, the next is that plus the next
shortest/congested 1 or more routes both failed, and so on)
 - obviously generating this for all cases for all src/dst pairs is
ooq (out of the question) but on the fly when the fly on the wall is
in the ointment would be handy - is this a (np) hard problem?


jon 
-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 89 20:36:15 GMT
From:      karn@jupiter.bellcore.com
To:        comp.protocols.tcp-ip
Subject:   Re: Revision of PC/IP scorecard

Some corrections to the KA9Q entries:

I have supported the FTP Software Packet Driver spec for quite some
time. This means I can handle any interface for which a packet driver
exists. In particular, drivers for the Interlan NI5010, WD8003, 3Com
3C523 and 3Com 3C503 are all available in the copylefted driver archive
coordinated by Russ Nelson (nelson@sun.soe.clarkson.edu). I'm using
the WD8003 and 3Com 3C503 myself.

Also, my NOS version (available for about the past 6 months, although it
is still being enhanced) supports domain name lookups and the finger
protocol (both client and server).

Phil

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 89 02:53:10 GMT
From:      joshua@athertn.Atherton.COM (Flame Bait)
To:        comp.sys.apollo,comp.protocols.tcp-ip,comp.protocols.nfs,comp.sys.hp
Subject:   A comparison of Commercial RPC Systems

I've finished work on a paper entitled "A Comparison of Commercial RPC
Protocols" which I gave at NCF: The Network Computing Forum, and also
as a work in progress at USENIX.

It compares RPC (Remote Procedure Call) systems from Apollo, Sun and 
Netwise for speed and dependablity.  I'm posting the paper (in troff 
format) to comp.misc, so interested people can get it.  If you can not 
get comp.misc, then please send me email, and I'll send it to you.  I 
can also send a plain text version, for people who do not have nroff 
or troff.

I'm also thinking about follow on work to compare data representation
techniques (Sun's XDR vs. Apollo's RMR vs. Netwise's ASN.1).  If you
would like to help (especially if you use Apollo's NCS) please email me.

Joshua Levy
--------                Quote: "If you haven't ported your program, it's not
Addresses:                      a portable program.  No exceptions."  
joshua@atherton.com          
{decwrl|hpda|sun|pyramid}!athertn!joshua  work:(408)734-9822 home:(415)968-3718

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 89 10:37:36 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   trace route to OZ


FYI

Script started on Tue Jul 18 11:26:46 1989

traceroute to 128.250.1.21 (128.250.1.21), 30 hops max, 38 byte packets
 1  ucl-cisco (128.16.6.150)  0 ms  40 ms  0 ms
 2  192.5.28.6 (192.5.28.6)  140 ms  80 ms  80 ms
 3  192.42.155.2 (192.42.155.2)  660 ms  860 ms  640 ms
 4  192.42.155.2 (192.42.155.2)  660 ms  640 ms  640 ms
 5  192.52.71.2 (192.52.71.2)  660 ms  680 ms  680 ms
 6  10.3.0.5 (10.3.0.5)  760 ms  1460 ms  740 ms
 7  arc-psn.arc.nasa.gov (26.1.0.16)  1360 ms  1400 ms  2240 ms
 8  192.52.195.11 (192.52.195.11)  2040 ms  1400 ms  1420 ms
 9  132.160.249.1 (132.160.249.1)  1360 ms  1120 ms  1820 ms
10  132.160.1.2 (132.160.1.2)  1200 ms  1340 ms  1240 ms
11  132.160.253.2 (132.160.253.2)  1780 ms  2000 ms  1780 ms
12  128.250.1.21 (128.250.1.21)  1960 ms  2440 ms  2000 ms

script done on Tue Jul 18 11:33:46 1989

i wish i could put names to all the numbers, but thats london to
Melbourne for you; the performance is pretty reasonable, but i guess
everyone West and South of here is still in the land of Nod, their
Ruby slippers under the bed...

jon

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 89 11:55:28 GMT
From:      schoff@STONEWALL.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP list?


snmp@nisc.nyser.net
snmp-request@nisc.nyser.net

is what you are looking for.

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

    Good morning all,
    		I was wondering if someone knew about an SNMP mail list and
    where I would send to subscribe to it?
    			Thanks in advance,
    					  Chris VandenBerg
    					  (chris@salt.acc.com)
    					  (805) 963-9431

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Jul 89 11:37:36 +0100
From:      Jon Crowcroft <J.Crowcroft@Cs.Ucl.AC.UK>
To:        G.Michaelson@cc.uq.oz.au
Cc:        tcp-ip@sri-nic.arpa, ja@Cs.Ucl.AC.UK
Subject:   trace route to OZ

FYI

Script started on Tue Jul 18 11:26:46 1989

traceroute to 128.250.1.21 (128.250.1.21), 30 hops max, 38 byte packets
 1  ucl-cisco (128.16.6.150)  0 ms  40 ms  0 ms
 2  192.5.28.6 (192.5.28.6)  140 ms  80 ms  80 ms
 3  192.42.155.2 (192.42.155.2)  660 ms  860 ms  640 ms
 4  192.42.155.2 (192.42.155.2)  660 ms  640 ms  640 ms
 5  192.52.71.2 (192.52.71.2)  660 ms  680 ms  680 ms
 6  10.3.0.5 (10.3.0.5)  760 ms  1460 ms  740 ms
 7  arc-psn.arc.nasa.gov (26.1.0.16)  1360 ms  1400 ms  2240 ms
 8  192.52.195.11 (192.52.195.11)  2040 ms  1400 ms  1420 ms
 9  132.160.249.1 (132.160.249.1)  1360 ms  1120 ms  1820 ms
10  132.160.1.2 (132.160.1.2)  1200 ms  1340 ms  1240 ms
11  132.160.253.2 (132.160.253.2)  1780 ms  2000 ms  1780 ms
12  128.250.1.21 (128.250.1.21)  1960 ms  2440 ms  2000 ms

script done on Tue Jul 18 11:33:46 1989

i wish i could put names to all the numbers, but thats london to
Melbourne for you; the performance is pretty reasonable, but i guess
everyone West and South of here is still in the land of Nod, their
Ruby slippers under the bed...

jon
-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 89 13:19:38 GMT
From:      baw@sharkey.cc.umich.edu (Brian Wolfe)
To:        comp.protocols.tcp-ip
Subject:   Ethernet Bridge Recommendations?


I have about $6000 (at most $8000) to bridge 3 standard ethernet subnets,
so far the best deal I can find is on 2 of Retix' low-end bridges that
are rated for 6000 'frames/second'... is that fast enough for joining segments
that have about 10 hosts each?? Security is something of an issue since
there is clinical data on some hosts and research data on others, so I would
like some control over access. 
 
So far I've looked at bridges from Micom, Raycom, Retix and DEC, are there
any other vendors that I should try?

Are there any bridges that I should avoid like the plague?            
 
I would appreciate any recommendations you may have and I will gladly
post a summary to the net!
 
Thanks,
 
Brian.
 

-- 
Brian Wolfe                    Internet: baw@terminator.cc.umich.edu
Systems Analyst                UUCP:     {rutgers,uunet}!sharkey!brian
Henry Ford Hospital 	       Voice:    (313)-876-7461
Detroit, MI 48202              FAX:      (313)-875-0315

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 89 15:21:03 GMT
From:      heberlei@iris.ucdavis.edu (Todd)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for any public domain network diagnostic/monitor tools

SORRY TO TAKE UP BANDWIDTH, BUT OUR HOST TABLES ARE NOT THE BEST (THIS
MACHINE IS NOT USING BIND-OR WHATEVER ITS CALLED).  I ALSO THOUGHT
OTHERS MAY BE INTERESTED IN THIS PACKAGE.  READ ON...

In article <9445@ppgbms.UUCP> paul@ppgbms (Paul Evan Matz) writes:
>
>	I was wondering if someone out there could recommend any good
>network diagnostic tools that run on a PC or a Sun, either for cash or
>public domain.  I have heard that some things from CMU and MIT exist,
>but have no details.  Monitoring of packet sources and destinations,
>of various types of protocol, might be handy.  Any tips would be much
>appreciated.  (I have played with Sun's traffic program, but it doesn't
>seems to do much with packets of the ipx [netware] protocol variety).
>
>	Thanks (wishful thinking)
>	Regards,
>
>	Paul Matz
>	PPG Biomedical Systems
>	One Campus Drive
>	Pleasantville, NY. 10570
>	914-741-4685
>	path ppgbms!moe!paul@philabs.philips.com

NNStat created at USC / Information Sciences Institute under a
contract from the NSF looks like it will do much of what is requested.
Here is the first paragraph from its manual:

    NNstat is a set of programs that comprise a facility for the
    distributed collection of Internet traffic statistics.  This
    facility is designed to support the requirements of a network
    administrator for gathering long-term usage statistics
    simultaneously at many network entry points... [more]

It runs on a Sun under SunOS 3.x and 4.0.  If you are interested, I
guess the best place to contact is the NSF (the package just showed up
on out computer).

ALSO, MANY THANKS TO ALL THE PEOPLE WHO RESPONDED TO MY QUESTION
CONCERNING THE NIT INTERFACE UNDER SUN0S 4.0 (for raw sockets)!

--------------
Todd Heberlein
heberlei@iris.ucdavis.edu	128.120.57.20

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 89 15:42:14 GMT
From:      yozzo@arnor.arpa
To:        comp.protocols.tcp-ip
Subject:   Racal-Interlan TCP/IP for OS/2

Has anyone tried Racal-Interlan TCP/IP for OS/2?

If so, what are you're reactions?

    

Ralph Yozzo (YOZZO at WATSON, arpanet:yozzo@ibm.com bitnet:yozzo@yktvmx.bitnet)'

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 89 15:52:31 GMT
From:      bywater!arnor!arnor.arpa!yozzo@uunet.uu.net
To:        tcp-ip@sri-nic.arpa
Subject:   Kenmore MicroWave Oven For Sale
For Sale
     24 x 18 x 15 
  Kenmore MicroWave Oven
  - Delay start cooking
  - Multi-stage cooking
  - Time of day indicator
  - Memory/recall
  - Power guide
  - Data
    - Power 1400 Watts
  - Excellent condition

  - Originally $250
  - Asking     $150

- Call Ralph Yozzo (914) 564-4731
  (evenings or weekends)
- Call Ralph Yozzo (914) 945-3634
  (weekdays)
  or write to:
  Ralph Yozzo
  RD #3 Box 142A Cooks Lane
  Walden, NY
  12586
-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Jul 89 23:35:59 -0400
From:      "Marty Schoffstall" <schoff@solbourne.nyser.net>
To:        heker@jvnca.csc.org (Sergio Heker)
Cc:        kwe@bu-cs.bu.edu, nisc@nisc.jvnc.net, tcp-ip@sri-nic.ARPA, schoff@nisc.nyser.net
Subject:   Re: Troubleshooting routing problems
NYSERNet has not participated in discussions of technical issues in
these meetings as we have never sent technical representatives.  We
have met/discussed/agreed seperately with NEARnet to cooperate via
a direct connection of our two peer regional networks.  

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

>    The JvNCnet network, like other networks has been dealing with all these 
>    issues for the last three years, and is working closely with the Institutio
>    members (Campuses), with MERIT and with other Regional Networks to assist
>    users.  Consistent with this spirit of cooperation we have met a number of
>    times with the principals of the Regional and State Networks in the North
>    East of the Country (PREPnet, NYSERnet, NEARnet and JvNCnet) to discuss
>    technical issues of Regional to Regional nature. 
>    meetings have been very productive, and will continue in the future, in
>    order to provide for the necessary coordination among the peer networks
>    to free the end-user of unnecessary complications.
-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 89 17:41:11 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Terminology deplored

Recently I have noticed the rise of the word "gate" as a contraction of
"gateway", first in speech, then in messages, and recently in a draft
RFC.  To my eye and ear, this usage seems precious and slovenly.  The
English language is too marvelous a machine to deserve such
maltreatment.

   Bob Braden

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 89 17:47:18 GMT
From:      "Paul_S._Lei.ElSegundo"@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Courses


Thanks to all that responded to my request. I will forward the responses to
anyone interested. Thanks again.

/Paul
PLei.ElSegundo@Xerox.COM

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 89 18:33:39 GMT
From:      heberlei@iris.ucdavis.edu (Todd)
To:        comp.protocols.tcp-ip
Subject:   Re: Ignorant question - multiple connections within TCP ports?

In article <1765.AA1765@geo-works> bryan@geo-works.UUCP (Bryan Ford) writes:
>I've been reading a book about the TCP/IP suite, and I have a question
>(concern) about the TCP protocol.  It appears to me from reading this book
>that you can have one separate TCP connection for each port on a single
>host.  For example, if someone connects to port 2 on a host, someone else
>can connect to port 3 on the same host, and have two independent
>connections - correct?  However, is there a way that there can be more than
>one connection to a single port?  For example, if someone connects to port
>21 on a host to do some FTP stuff, then someone else tries to also connect
>to port 21 on the same host while the first connection is still going, what
>happens?  Does the request get denied, or does another FTP server process
>get started up, or what?
>
>I hope I've been clear enough.  I've been searching all over this book for
>information on this, but can't find anything.
>
>Thanks for your help!
>
>				Bryan
>   _/   Bryan Ford - bryan@geo-works.uucp   \_

This does happen.  For example if two people from host A
login into host B, the port on B for both connections will be port
513 (the default port for login I believe).  Host B can then separate
the connections by:

 (1) source ports of the originating connection (from host A)
        or
 (2) sequence / acknowledgement numbers of the separate connections

I was once told that (2) was the correct answer.
The question I have is: If the connections are separated by seq/ack
numbers as I have been told, what would happen if the seq. number from
one connection passed the seq. number for another connection?

Note:
There are a number of ports used for certain services (ie. finger,
telnet, ftp, ftp-data, etc).  All hosts logging into host B will use
the same port on host B (513).  However, I have yet to see the ports
of two connections have both the same source and destination ports (eg
two connections from host A to host B using ports 1025 (on A) and 513
(on B)).  Thus by experience, I am starting to believe answer (1) is
correct.

WOULD SOMEONE THAT KNOWS THE ACTUAL SPECS. PLEASE HELP US OUT?


Todd Heberlein

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 89 18:43:13 GMT
From:      broehl@watdcsu.waterloo.edu (Bernie Roehl)
To:        comp.protocols.tcp-ip
Subject:   Re: Revision of PC/IP scorecard

In article <17218@bellcore.bellcore.com> karn@jupiter.bellcore.com () writes:
>Some corrections to the KA9Q entries:
>
>Also, my NOS version (available for about the past 6 months, although it
>is still being enhanced) supports domain name lookups and the finger
>protocol (both client and server).

We've been using Phil's package for some time now, and are very pleased with
it; it does everything we need and then some.

Unfortunately, the manual on flash.bellcore.com seems to be out of date;
in particular, the hosts file has been replaced by something called
"domain.txt", whose format doesn't seem to be defined in the manual.

Short of reading the source, is there some way to find out how to set up
this file?

-- 
	Bernie Roehl, University of Waterloo Electrical Engineering Dept
	Mail: broehl@watdcsu.UWaterloo{.edu,.csnet,.cdn}
	BangPath: {allegra,decvax,utzoo,clyde}!watmath!watdcsu!broehl
	Voice:  (519) 745-4419 [home]  (519) 885-1211 x 2607 [work]

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 89 19:15:27 GMT
From:      larry@macom1.UUCP (Larry Taborek)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,news.sysadmin
Subject:   need info on tcpip suppliers

In our local environment (our department) we are looking at
connecting up a variety of computers (zilogs, unicorns, and an
IBM model 8800) and pc's to a TCPIP network.

I talked to our MIS people and they directed us to look at
Synoptics in California.  After calling them I found out that
they only offer the hardware.  There is no application software
that they sell to facilitate FTP/SMTP or remote login.

I am not locked to Synoptics by any means, but am begining to see
that I should be talking to a wide variety of network vendors,
both hardware and software.

Question 1:  Who are the hardware and software vendors in the TCPIP
environment and what are their phone numbers?  I know a
smattering of buzzwords (Western digital, Connectics, etc) but no
phone numbers.

Question 2:  Anyone have any good/bad stories of what to 
look/lookout for in setting up their TCPIP lan.  I am
particularly interested in functionality at the PC/Micicomptuer
level.

Question 3:  Has anyone had any experience using a minicomputer
as a pc network server.

As I don't subscribe to all the newsgroups that I am crossposting
to, please just email me any responses you have.  If requested, I
will post a summary.  You don't have to have to be able to relate
to all three questions to respond.

Thanks Guys and Gals,

Larry


-- 
Larry Taborek	..!uunet!grebyn!macom1!larry	Centel Federal Systems
		larry@macom1.UUCP		11400 Commerce Park Drive
						Reston, VA 22091-1506
						703-758-7000

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 89 20:55:22 GMT
From:      khj@ecsvax.UUCP (Kenneth H. Jacker)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for any public domain network diagnostic/monitor tools

In article <9445@ppgbms.UUCP> paul@ppgbms (Paul Evan Matz) writes:
>
>	I was wondering if someone out there could recommend any good
>network diagnostic tools that run on a PC or a Sun ...
>	..... <lines deleted> .....
>
>	Paul Matz
>	PPG Biomedical Systems
>	One Campus Drive
>	Pleasantville, NY. 10570
>	914-741-4685
>	path ppgbms!moe!paul@philabs.philips.com
>

	... and I was wondering the same for a Macintosh II.  With
	all the good Mac-based work at the NCSA (telnet, et al),
	not to mentioned Stanford, and others --- there must be
	*something* out there (preferably PD) that will run on
	a Mac.  

	Anything -- no matter how simplistic -- would be better
	than what I have now:  NOTHING!


-- 
Kenneth H. Jacker               Domain:   khj@uncecs.edu
Dept of Math Sciences           BITNET:   khj@ecsvax
Appalachian State Univ          UUCP:     ...!ecsvax!khj
Boone, NC  28608

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 89 21:43:30 GMT
From:      byun@EDN-VAX.DCA.MIL (byun)
To:        comp.protocols.tcp-ip
Subject:   gated information






	The butterfly gateway which connects our in house network to the ARPANETis being removed.  To replace the gatway, we will be running gated on
Berkley 4.3.  However, I have no information on how to set up a configuration 
file for the program.  I also have no information on the core gateways in 
relation to our butterfly gateway.  If you have information on either of the twoproblems or know where I may be able to find the information please respond.

					Hyuk Byun
					DCEC/R640 

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 89 21:54:00 GMT
From:      david@ms.uky.edu (David Herron -- One of the vertebrae)
To:        comp.protocols.tcp-ip
Subject:   Re: Kenmore MicroWave Oven For Sale

What sort of TCP/IP does it have??
-- 
<- David Herron; an MMDF guy                              <david@ms.uky.edu>
<- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-
<- WARNING: Hunting season is now open in West Virginia!

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 89 22:14:15 GMT
From:      welch@giza.cis.ohio-state.edu (Arun Welch)
To:        comp.protocols.tcp-ip
Subject:   Re: Kenmore MicroWave Oven For Sale

In article <12201@s.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) writes:
> What sort of TCP/IP does it have??

I dunno, but my guess is it's an NTP chimer, from the clock...:-)

...arun


----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
welch@tut.cis.ohio-state.edu

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 89 23:55:41 GMT
From:      djl@mips.COM (Dan Levin)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   DNS for Unix Information

If you are using or thinking about using RFC 1034-35 style DNS for
distributing information such as passwd, group, etc. in a UNIX
environment, I would like to talk to you.

-- 
			***dan

{decwrl,pyramid,ames}!mips!djl         djl@mips.com (No, Really! Trust Me.)
+1 408 991 0343

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 00:51:44 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Kenmore MicroWave Oven For Sale

In article <12201@s.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes:

   What sort of TCP/IP does it have??

I think that they took the old CP/M version of Karn's code and ported it
to an 8051.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])|(70441.205@compuserve.com)

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 01:17:04 GMT
From:      wisner@mica.Berkeley.EDU (Bill Wisner)
To:        comp.protocols.tcp-ip
Subject:   Re: Kenmore MicroWave Oven For Sale

But what good is it if it doesn't speak TCP/IP?

Bill Wisner		wisner@mica.berkeley.edu	     ucbvax!mica!wisner
I'm not poricthys notatus either.

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 01:27:46 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Ignorant question - multiple connections within TCP ports?

In article <4908@ucdavis.ucdavis.edu>, heberlei@iris.ucdavis.edu (Todd) writes:
> In article <1765.AA1765@geo-works> bryan@geo-works.UUCP (Bryan Ford) writes:
> >It appears to me from reading this book
> >that you can have one separate TCP connection for each port on a single
> >host.  For example, if someone connects to port 2 on a host, someone else
> >can connect to port 3 on the same host, and have two independent
> >connections - correct?  However, is there a way that there can be more than
> >one connection to a single port?  For example, if someone connects to port
> >21 on a host to do some FTP stuff, then someone else tries to also connect
> >to port 21 on the same host while the first connection is still going, what
> >happens?  Does the request get denied, or does another FTP server process
> >get started up, or what?
> 
> This does happen.  For example if two people from host A
> login into host B, the port on B for both connections will be port
> 513 (the default port for login I believe).  Host B can then separate
> the connections by:
> 
>  (1) source ports of the originating connection (from host A)
>         or
>  (2) sequence / acknowledgement numbers of the separate connections
> 
> I was once told that (2) was the correct answer.

Connections are distinguished by the 4-tuple

	<localhost,localport,remotehost,remoteport>

If two people from A request the same service of B at the same time,
they will have different port numbers on A.  For some operating
systems, two users on A can each use the same local port number
to request the same service on two different hosts B and C.  It
is illegal for A's TCP to assign the same local port number to
two connections if both are destined for the same port on B; if A
does this, it's broken.

Sequence numbers are *not* used to disambiguate in this case.  They come
into play only to distinguish between the current connection and old
packets floating around the net from previous instantiations of the
same connection (i.e., the same 4-tuple).  That topic gets rather
involved, and I think I'll pass on explaining it till another posting.

And yes, before you ask, I'm utterly certain that my answer is correct.

		--Steve Bellovin

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 02:09:39 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  trace route to OZ

Jon,

(Sputter) About that hop from ARPANET to MILNET at NASA/Ames. Either the
Munchkins are upon us or the Wicked Witch ain't dead. I conclude the route
to Oz is via US DoD, but who would find that surprising?

Dave

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Jul 89 08:25:17 EDT
From:      ted@NADC.ARPA (T. Calkins)
To:        tcp-ip@sri-nic.ARPA
Subject:   Advice Needed..
 
We are running 4.3BSD UNIX(tm) on a DEC VAX 11/780 with a UNIBUS-installed
Ethernet board connected to a mini-Ethernet. The mini-Ethernet includes a
Sun and an Apollo Workstations and a separate nameserver. I need some advice
and/or some samples as to what tables/files need to be modified and how in 
order to include the VAX on the mini-net to run mail, telnet and ftp
with TCP/UDP. There is no connection, at this point, to the DDN Internet.
Perhaps in the future. I have read the appropriate SMM pages and (most of)
the RFCs but it's still not clear to me what needs to be done.
 
Please reply directly to me: ted@nadc.arpa.
 
Thanks in advance.   Ted

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 05:10:12 GMT
From:      bob@giza.cis.ohio-state.edu (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Kenmore MicroWave Oven For Sale

One step closer to ToasterNet...

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Jul 89 09:59:58 edt
From:      rhott@relay.nswc.navy.mil
To:        tcp-ip@sri-nic.arpa
rdn@chinet.chi.il.us (Richard Nichols) writes:


>We have a need to connect two machines together that have thick-wire
>ETHERNET connections.  Since there are only two machines in this 'network' I
>was wondering if there is such a thing as a 'null transceiver'?  In other
>words, is there a way to connect our two machines without having to actually
>connect real transceivers?

>Any help would be appreciated.

>Rick Nichols
>rdn@chinet.chi.il.us

I have a glossy for for a product called an "ANC-10 Ethernet AUI-AUI
Direct Connection Device" from American Network Connections, Inc.  I have
written in the margin a cost of ~$180.  I also have an article from Digital
Review on the device.  The article confirms the price.  I have not used
this device but it sounds like it should meet your requirements.  The
device provides 2 AUI Cable interfaces.

Configuration:
     host ----AUI Cable----- ANC-10 -----AUI Cable---- host

ANC, Inc can be reached at:
   462 Oakmead Parkway
   Sunnyvale, California 94086
   Ph #  (408) 737-1511


If you can afford one of the 8-port transceiver devices (fan-out boxes)
I would recommend doing so.  They would permit future expansion!  Anyway
hope that this helps!

- Bob -

=============================================================================

Fullname:         Robert W. (Bob) Hott
Mailing Address:  Naval Surface Warfare Center
                  Networks Branch (Code E41)
                  Dahlgren, Virginia  22448
DDN Mail:         rhott@relay.nswc.navy.mil
Telephone:        (703) 663 - 7745

"If man were not meant to play volleyball, why are there so many beaches?"
	 - Bob Hott -

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 08:52:52 GMT
From:      torben@DORSAI.ICS.HAWAII.EDU ("Torben N. Nielsen")
To:        comp.protocols.tcp-ip
Subject:   Re:  trace route to OZ

>From:	Mills@udel.edu
>To:	Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
>cc:	G.Michaelson@cc.uq.oz.au, tcp-ip@sri-nic.arpa, ja@cs.ucl.ac.uk
>Subject:  Re:  trace route to OZ
>Message-ID: <8907182209.aa04438@huey.udel.edu>
>Status: R
>
>Jon,
>
>(Sputter) About that hop from ARPANET to MILNET at NASA/Ames. Either the
>Munchkins are upon us or the Wicked Witch ain't dead. I conclude the route
>to Oz is via US DoD, but who would find that surprising?
>
>Dave

It may be going that way, but it shouldn't be. If my understanding of the 
situation is correct, the UK is linked via JVNC. Now, if I run a simple thing
like a ``traceroute" to ``jvnc.csc.org" (and Oz is one hop South of here), I get
the following:

traceroute to jvnca.csc.org (128.121.50.1), 30 hops max, 40 byte packets
 1  menehune.Hawaii.Net (128.171.1.6)  0 ms  0 ms  10 ms
 2  132.160.249.2 (132.160.249.2)  60 ms  70 ms  70 ms
 3  ARC1.BARRNET.NET (192.52.195.7)  70 ms  70 ms  70 ms
 4  ARC.SU.BARRNET.NET (131.119.3.6)  70 ms  70 ms  70 ms
 5  129.140.79.13 (129.140.79.13)  140 ms  150 ms  140 ms
 6  129.140.81.15 (129.140.81.15)  220 ms  200 ms  200 ms
 7  129.140.72.17 (129.140.72.17)  240 ms  230 ms  230 ms
 8  * * *
 9  zaphod-gateway.jvnc.net (128.121.54.72)  260 ms  270 ms  300 ms
10  * * * 
11  * * * 
12  * * * 
13  * * * 
14  * * * 
15  * * * 
16  * * * 
17  * * * 
18  * * * 
19  jvnca.csc.org (128.121.50.1)  390 ms !  530 ms !  490 ms ! 

and when I run ``traceroute" to ``nsfnet-relay.ac.uk", I get the following:

traceroute to nsfnet-relay.ac.uk (128.86.8.6), 30 hops max, 40 byte packets
 1  menehune.Hawaii.Net (128.171.1.6)  0 ms  0 ms  10 ms
 2  132.160.249.2 (132.160.249.2)  70 ms  70 ms  70 ms
 3  ARC1.BARRNET.NET (192.52.195.7)  60 ms  70 ms  70 ms
 4  ARC.SU.BARRNET.NET (131.119.3.6)  80 ms  70 ms  70 ms
 5  129.140.79.13 (129.140.79.13)  140 ms  140 ms  140 ms
 6  129.140.81.15 (129.140.81.15)  190 ms  200 ms  200 ms
 7  129.140.72.17 (129.140.72.17)  230 ms  240 ms  240 ms
 8  * * *
 9  ford-gateway.jvnc.net (128.121.54.73)  250 ms  260 ms  240 ms
10  fenchurch-gateway.jvnc.net (128.121.54.78)  270 ms  260 ms  270 ms
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  NSFNET-RELAY.AC.UK (128.86.8.6)  3840 ms !  930 ms ! *

Up through the seventh hop, it's clear to me what is happening. But after that,
I get kind of confused. I can't really tell how many hops there are in between
the JVNC gateways and ``nsfnet-relay.ac.uk". What I can tell is that I have
a stable RTT of about 250ms between me and the JVNC gateways. But when I try
to reach ``nsfnet-relay.ac.uk" with a ``ping", this is what I get:

----nsfnet-relay.ac.uk PING Statistics----
104 packets transmitted, 88 packets received, 15% packet loss
round-trip (ms)  min/avg/max = 930/3123/5270

And that is not so good. Even the minimum seems to indicate an RTT of almost
700ms across that little pond and even if this is a 56Kbps satellite link,
that's pretty stiff. I presume some other gateway is hiding in between plus
likely a *very* high load on that line.

Things are bad since I also have New Zealand swimming around somewhere South
of here and they're having trouble getting mail through to the UK. And they
tend to send a lot to the UK I gather :-(

						Torben

P.S. For those who care, Oz is a 56Kbps satellite hop South of here; it converts
to a 64Kbps terrestrial line (via ANZCAN) around the middle of August. Or at
least that's what the carriers tell us. But maybe they're just trying to keep
us happy while thinking up an excuse to delay a bit. Doubt it though....

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Jul 89 16:25:28 PDT
From:      page@Eng.Sun.COM (Bob Page)
To:        comp.protocols.tcp-ip
Subject:   Re: Kenmore MicroWave Oven For Sale
It's not that funny...

Outside my office door is a (serious) article on CEBus, a communications
standard for home appliances.  It's being standardized by EIA.  There's
already a CEBus chip, and the concept has been demonstrated by AT&T, Sony,
Tandy, Mitsubishi, Panasonic, Marantz and more.

CEBus has been designed for new units as well as retrofits, and it's media
independent, so it can use power lines, phone lines, TV cable, remote
control etc.

I have not seen the protocol spec so I don't know how they deal with
routing, security and the like, but CEBus <--> TCP/IP gateways can't
be too far off...

..bob

PS The article is on page 9 of the June 89 issue of _Marketing Computers_.
-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 11:14:24 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: trace route to OZ



 >>(Sputter) About that hop from ARPANET to MILNET at NASA/Ames. Either the
 >>Munchkins are upon us or the Wicked Witch ain't dead. I conclude the route
 >>to Oz is via US DoD, but who would find that surprising?
 
Dave

yes i was a little surprised at the milnet hop

 >It may be going that way, but it shouldn't be. If my understanding of the 
 >situation is correct, the UK is linked via JVNC. Now, if I run a simple thing
 >like a ``traceroute" to ``jvnc.csc.org" (and Oz is one hop South of here), I get
 >the following:

not from me it aint, the jvnc/uk link is academic traffic - i was
using the uk mod path... but below is right for nsfnet realy (i.e.
Univ of London Comp Center


 >and when I run ``traceroute" to ``nsfnet-relay.ac.uk", I get the following:
 
 >21  NSFNET-RELAY.AC.UK (128.86.8.6)  3840 ms !  930 ms ! *
 
 >Up through the seventh hop, it's clear to me what is happening. But after that,
 >I get kind of confused. I can't really tell how many hops there are in between
 >the JVNC gateways and ``nsfnet-relay.ac.uk". What I can tell is that I have
 >a stable RTT of about 250ms between me and the JVNC gateways. But when I try
 >to reach ``nsfnet-relay.ac.uk" with a ``ping", this is what I get:

Torben,

i dont understand all the extra hops either, but between JVNC and ULCC are 2
cisco gateways running X.25 (over a satellite link) which will account
for the extra delay and not a little of the loss...

 >----nsfnet-relay.ac.uk PING Statistics----
 >104 packets transmitted, 88 packets received, 15% packet loss
 >round-trip (ms)  min/avg/max = 930/3123/5270
 
 >And that is not so good. Even the minimum seems to indicate an RTT of almost
 >700ms across that little pond and even if this is a 56Kbps satellite link,
 >that's pretty stiff. I presume some other gateway is hiding in between plus
 >likely a *very* high load on that line.

also, the cisco at the UK end goes thru an X.25 swicth into a
microvax, which runs IP over X.25 (dont ask why, its history) - all
this does not help a lot - someday, we may pursuade folks here that
X.25 and IP mix like oranges and onions, then (when the line goes to
TAT-8) the performance will go reasonable...

 jon


------- End of Forwarded Message

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 12:09:00 GMT
From:      BEAME@McMaster.CA
To:        comp.protocols.tcp-ip
Subject:   Re: Revision of PC/IP scorecard


Suggestion for more table entries:

  1)    Memory resident size

  2)    What is memory resident ? (example PCNFS from SUN has only UDP and IP,
                                   not resident TCP)


        - Carl Beame
        Beame@McMaster.CA

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 12:30:09 GMT
From:      bryan@geo-works.UUCP (Bryan Ford)
To:        comp.protocols.tcp-ip
Subject:   Followup to Ignorant Question

Thanks to everyone who responded to my question!  I sent replies to all the
messages I received, but my mailer just messed up and some might have
gotten lost, so forgive me if you didn't get a response.

Anyway, sorry for boring everybody with a beginner's question. :-)  Now,
another question.  (Uh oh... :-)  About what does it take to implement
TCP, IP, and a few of the "normal" ULPs (FTP, etc.) and possibly NFS?  Is
there public domain source code out there for these protocols that I could
port?  About how much memory and disk space could these beasties be
expected to eat up on a 68xxx-based system?

I'm considering implementing TCP/IP rather than 'doing my own thing', but
if it would take years to program and megabytes to run, I'd rather give up
the standardization.

				Bryan

--

     _______________________________________
   _/   Bryan Ford - bryan@geo-works.uucp   \_
 _/  ..!utah-cs!caeco!i-core!geo-works!bryan  \_
/ ..!uunet!iconsys!caeco!i-core!geo-works!bryan \

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 13:47:13 GMT
From:      buck@DRAX.GSFC.NASA.GOV (Loren (Buck) Buchanan)
To:        comp.protocols.tcp-ip
Subject:   (none)

Hi

Below the clip line is a message I received but is not intended for me.  
The message is something that I posted to news in early July.  Hopefully 
you can figure out what is wrong with your auto mailer from the 
information contained in the header.

--------------------------snip snip snip----------------------------------------
From ames!SITSRV.STEVENS-TECH.EDU!POSTMASTER@dftsrv.gsfc.nasa.gov  Tue Jul 18 21:17:44 1989
Received: from dftsrv.GSFC.NASA.GOV by drax.gsfc.nasa.gov (5.52/5.6)
	id AA16735; Tue, 18 Jul 89 21:17:44 EDT
Received: Tue, 18 Jul 89 20:18:44 EST from ames.arc.nasa.gov by dftsrv.gsfc.nasa.gov (5.59/1.5)
Received: from [192.12.216.37] by ames.arc.nasa.gov (5.61/1.2); Tue, 18 Jul 89 18:20:48 -0700
Message-Id: <8907190120.AA01248@ames.arc.nasa.gov>
Date: Tue, 18 Jul 89 16:32:42 EDT
From: ames!VAXB.STEVENS-TECH.EDU"QMS Mail Router"!POSTMASTER@dftsrv.gsfc.nasa.gov
To: dftsrv!drax.gsfc.nasa.gov!buck@ames.arc.nasa.gov
Subject: Undeliverable mail

	Unable to deliver mail, time expired
 
Original mail text follows:
   Date: Thu, 13 Jul 89 16:02:25 EDT
   From: dftsrv!drax.gsfc.nasa.gov!buck@ames.arc.nasa.gov
   To: LOCAL-TCP-IP
   Subject: SLIP for xxx machine
   X-VMS-To: tcp-ip@sri-nic.arpa
   Message-Id: <8961316225.21800096.SYSTEM>
   
   Received: From CORNELLC(MAL) by SITVXB with Jnet id 7125
             for LOCAL-TC@SITVXB; Thu, 13 Jul 89 16:02 EDT
   Received: from CORNELLC by CORNELLC.BITNET (Mailer R2.02A) with BSMTP id 4462;
    Thu, 13 Jul 89 13:04:44 EDT
   Received: from SRI-NIC.ARPA by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.1MX)
    with TCP; Thu, 13 Jul 89 13:04:17 EDT
   Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Thu, 6 Jul 89
    19:38:08 PDT
   Received: by ucbvax.Berkeley.EDU (5.61/1.37)
   	id AA27016; Thu, 6 Jul 89 19:16:40 -0700
   Received: from USENET by ucbvax.Berkeley.EDU with netnews
   	for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
   	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
   Date: 7 Jul 89 01:42:47 GMT
   From: dftsrv!drax.gsfc.nasa.gov!buck@ames.arc.nasa.gov  (Loren (Buck) Buchanan)
   Organization: Computer Sciences Corporation @ NASA Goddard Space Flight Center
   Subject: SLIP for xxx machine
   Message-Id: <353@dftsrv.gsfc.nasa.gov>
   Sender: tcp-ip-relay@sri-nic.arpa
   To: tcp-ip@sri-nic.arpa
        
   I received the following reply to my posting: <335@dftsrv.gsfc.nasa.gov>
        
   |From: jbvb@vax.ftp.com (James Van Bokkelen)
   |
   |Commercial:
   |
   |Our PC/TCP package for DOS is available in a SLIP version.  Uses COM1 or
   |COM2 (the built-in ports), runs at up to 19.2 Kbaud, does not come with
   |dial-up support (automatic assignment of IP address to the caller when
   |the call is established).
   |
   |cisco Systems supports SLIP on their terminal concentrator box.  They
   |also re-sell PC/TCP, with a special program that works with code on the
   |concentrator to assign IP addresses when a dial-up connection opens.
   |
   |Encore supports SLIP on their Annex terminal concentrator.
   |
   |Spider Systems supports SLIP on their SysV Streams TCP/IP (sold in
   |source form to OEMs).
   |
   |Lachmann Associates (recently bought by someone) has SLIP support
   |in their SysV Streams TCP/IP (OEM source form product - I don't know
   |how many of their OEMs actually ship the code).
   |
   |TGV's VAX/VMS product supports SLIP as an option.
   |
   |Ultrix 3.0 includes an unsupported SLIP.
   |
   |SunOS includes an unsupported SLIP.
   |
   |Non-commercial:
   |
   |Rick Adams's code for 4.2 (which has evolved into 4.3 and maybe more).
   |
   |Phil Karn's KA9Q package for DOS (can act as an IP router, too).
   |
   |PC-IP for DOS (Harvard version) is said to have a SLIP driver.
   |
   |James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
   |FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
        
   Unfortunately I did not receive a response to the original request (I
   believe it was for AIX), nor did I receive a response to my request for
   the Silicon Graphics 4-D.  I have received requests for SLIP implementations
   for some of the machines in listed in James' email plus request for the
   Apple Macintosh, Amiga, and Atari.
        
   Send corrections, additions, and flames to me (I have an asbestos mailbox)
   and I will post an updated compilation to the net.
        
   Loren "Buck" Buchanan | internet: buck@drax.gsfc.nasa.gov | standard disclaimer
   CSC, 1100 West St.    | uucp: ...!ames!dftsrv!drax!buck   | "By the horns of a
   Laurel, MD 20707      | phonenet: (301) 497-2531 or 9898  | sky demon..."
   ------------
------------

--------------------------snip snip snip----------------------------------------

B C'ing U

Buck
--
Loren "Buck" Buchanan | internet: buck@drax.gsfc.nasa.gov | standard disclaimer
CSC, 1100 West St.    | uucp: ...!ames!dftsrv!drax!buck   | "By the horns of a
Laurel, MD 20707      | phonenet: (301) 497-2531 or 9898  | sky demon..."

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 13:51:18 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Kenmore MicroWave Oven For Sale

>    What sort of TCP/IP does it have??
> I think that they took the old CP/M version of Karn's code and ported it
> to an 8051.

Does it have the slow-start (defrost?) algorithm?
-- 
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Jul 89 12:14:24 +0100
From:      Jon Crowcroft <J.Crowcroft@Cs.Ucl.AC.UK>
To:        Mills@louie.udel.edu, G.Michaelson@cc.uq.oz.au, ja@Cs.Ucl.AC.UK, tcp-ip@sri-nic.arpa
Subject:   Re: trace route to OZ


 >>(Sputter) About that hop from ARPANET to MILNET at NASA/Ames. Either the
 >>Munchkins are upon us or the Wicked Witch ain't dead. I conclude the route
 >>to Oz is via US DoD, but who would find that surprising?
 
Dave

yes i was a little surprised at the milnet hop

 >It may be going that way, but it shouldn't be. If my understanding of the 
 >situation is correct, the UK is linked via JVNC. Now, if I run a simple thing
 >like a ``traceroute" to ``jvnc.csc.org" (and Oz is one hop South of here), I get
 >the following:

not from me it aint, the jvnc/uk link is academic traffic - i was
using the uk mod path... but below is right for nsfnet realy (i.e.
Univ of London Comp Center


 >and when I run ``traceroute" to ``nsfnet-relay.ac.uk", I get the following:

 >21  NSFNET-RELAY.AC.UK (128.86.8.6)  3840 ms !  930 ms ! *

 >Up through the seventh hop, it's clear to me what is happening. But after that,
 >I get kind of confused. I can't really tell how many hops there are in between
 >the JVNC gateways and ``nsfnet-relay.ac.uk". What I can tell is that I have
 >a stable RTT of about 250ms between me and the JVNC gateways. But when I try
 >to reach ``nsfnet-relay.ac.uk" with a ``ping", this is what I get:

Torben,

i dont understand all the extra hops either, but between JVNC and ULCC are 2
cisco gateways running X.25 (over a satellite link) which will account
for the extra delay and not a little of the loss...

 >----nsfnet-relay.ac.uk PING Statistics----
 >104 packets transmitted, 88 packets received, 15% packet loss
 >round-trip (ms)  min/avg/max = 930/3123/5270

 >And that is not so good. Even the minimum seems to indicate an RTT of almost
 >700ms across that little pond and even if this is a 56Kbps satellite link,
 >that's pretty stiff. I presume some other gateway is hiding in between plus
 >likely a *very* high load on that line.

also, the cisco at the UK end goes thru an X.25 swicth into a
microvax, which runs IP over X.25 (dont ask why, its history) - all
this does not help a lot - someday, we may pursuade folks here that
X.25 and IP mix like oranges and onions, then (when the line goes to
TAT-8) the performance will go reasonable...

 jon


------- End of Forwarded Message

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 13:59:58 GMT
From:      rhott@RELAY.NSWC.NAVY.MIL
To:        comp.protocols.tcp-ip
Subject:   (none)

rdn@chinet.chi.il.us (Richard Nichols) writes:


>We have a need to connect two machines together that have thick-wire
>ETHERNET connections.  Since there are only two machines in this 'network' I
>was wondering if there is such a thing as a 'null transceiver'?  In other
>words, is there a way to connect our two machines without having to actually
>connect real transceivers?
 
>Any help would be appreciated.
 
>Rick Nichols
>rdn@chinet.chi.il.us

I have a glossy for for a product called an "ANC-10 Ethernet AUI-AUI
Direct Connection Device" from American Network Connections, Inc.  I have
written in the margin a cost of ~$180.  I also have an article from Digital
Review on the device.  The article confirms the price.  I have not used
this device but it sounds like it should meet your requirements.  The
device provides 2 AUI Cable interfaces.

Configuration:
     host ----AUI Cable----- ANC-10 -----AUI Cable---- host

ANC, Inc can be reached at:
   462 Oakmead Parkway
   Sunnyvale, California 94086
   Ph #  (408) 737-1511


If you can afford one of the 8-port transceiver devices (fan-out boxes)
I would recommend doing so.  They would permit future expansion!  Anyway
hope that this helps!

- Bob -

=============================================================================

Fullname:         Robert W. (Bob) Hott
Mailing Address:  Naval Surface Warfare Center
                  Networks Branch (Code E41)
                  Dahlgren, Virginia  22448
DDN Mail:         rhott@relay.nswc.navy.mil
Telephone:        (703) 663 - 7745

"If man were not meant to play volleyball, why are there so many beaches?"
	 - Bob Hott -

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 16:14:42 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  trace route to OZ

Torben,

The NTP clocks in Norway show a most peaceful Atlantic crossing, with
stable delays, small dispersions and negligible loss most times. I 
believe those circuits depart via JvNC too, but I can't recall just now
how UCL is connected at the UK end. There is a Dod/MoD (?) line to
RSRE in Malvern and a tail to UCL, but I don't know what magic happens
at the UCL termination blocks.

Dave

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 16:17:16 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  CRC calc for Ethernet; How?

Ross,

About every couple of years since the early seventies somebody rediscovers
how to shortcut the Galois field and exchange bytes for microseconds. The
primal reference is Peterson and Weldon (Vol. 2) "Error Correcting Codes."
Happy factoring.

Dave

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 16:41:23 GMT
From:      djw@bbn.com (David Waitzman)
To:        comp.protocols.tcp-ip
Subject:   Re: Kenmore MicroWave Oven For Sale

The microwave obviously speaks TCP:
Here is the "traceroute" output to kenmore.kitchen.net from here:

traceroute to kenmore.kitchen.net (224.1.54.1), 30 hops max, 40 bite packets
 1  circe.bbn.com (128.89.0.247)  0 ms  0 ms  10 ms
 2  128.89.0.1 (128.89.0.1)  60 ms  70 ms  70 ms
 3  * * *
 4  pc.livingroom.house.ny.us (225.9.5.4)  90 ms  90 ms  90 ms
 5  fridge.kitchen.net (224.4.5.3) 140 ms  150 ms  140 ms
 6  pc.livingroom.house.ny.us (225.9.5.4)  160 ms  170 ms  160 ms
 7  fridge.kitchen.net (224.4.5.3) 300 ms  310 ms  300 ms
 8  pc.livingroom.house.ny.us (225.9.5.4)  320 ms  330 ms  320 ms
 9  fridge.kitchen.net (224.4.5.3)  340 ms  350 ms  340 ms
10  kenmore.kitchen.net (224.1.54.1)  360 ms  370 ms  360 ms

Note the temporary routing loop from the pc to the fridge.  Anyone have
any ideas on why?

-david

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Jul 89 17:07:41 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Ignorant question - multiple connections within TCP ports?

In article <1765.AA1765@geo-works> bryan@geo-works.UUCP (Bryan Ford) writes:
>I hope I've been clear enough.  I've been searching all over this book for
>information on this, but can't find anything.

Sigh, this is Comer's book, right?  You *will* actually find this important
point discussed... in the appendix on the 4.3BSD interface!  Pray for a
revised second edition sometime soon...
-- 
$10 million equals 18 PM       |     Henry Spencer at U of Toronto Zoology
(Pentagon-Minutes). -Tom Neff  | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 18:16:14 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Routing tables

My MILNET host 'lanl.gov' has 925 routing table entries, obtained via
core EGP and RIP updates from a cisco connected to NSFnet, how about yours?

Cornett

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 18:39:14 GMT
From:      dyer@spdcc.COM (Steve Dyer)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: DNS for Unix Information

In article <23572@winchester.mips.COM> djl@mips.COM (Dan Levin) writes:
>If you are using or thinking about using RFC 1034-35 style DNS for
>distributing information such as passwd, group, etc. in a UNIX
>environment, I would like to talk to you.

Do you have the Dallas USENIX paper I gave describing _Hesiod_
at Project Athena?

I'd be happy to share our (very successful) experience using the DNS
for the purposes (and more) which you mention, and with BIND in particular.

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 18:47:30 GMT
From:      medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: trace route to OZ


First off, it's rather inappropriate for this list to be used for
network debugging, so let me try and categorically explain what is going
here and then carry on a discussion if necessary offline from the tcp-ip
list.  

The Austrailian connection goes via 64 Kbps satellite to Hawaii, where
it is switched over a new 512 Kbps TPC-3 fiber link back to CONUS into
the NSN here at Ames.  From there is it sent into the NSFNET backbone,
as an interim measure through BARRNET, but as soon as the NSS connection
here is operation, directly from NSN into NSFnet.  We also have a DDN
link that is used as a path of last resort for talking to everything
else.  All NSN traffic will use a direct connection to the BMILAMES
mailbridge here at Ames as soon as that system becomes operational
(it's still a bit flaky here after an ethernet controller was
added to it).  

It appears that while 128.250 is known via the NSFNET path, it is not making
it to the UK via this path, but the UK is routing this via the ARPANET/MILNET
path instead.  Those of us who manage the Internet routing system are trying
to find out why the UK is being routed this way and not via the primary path
via NSFNET.

In any case, if you find oddities in routing or other such interesting
tidbits of information, please send this to whoever manages your 
connections to the Internet.  The tcp-ip list is too big and too diverse
to be used for network debugging.  The MERIT folks and NASA both have mailing
lists for operational issues which are appropriate for this type of discussion.

						Thanks,
						   Milo

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 19:17:29 GMT
From:      djh@cci632.UUCP (Daniel J. Hazekamp)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Network Managment Protocols


	We are currently evaluating a Retix MAC level Ethernet Bridge
	with Network Managment. Retix sells a PC package which talks
	to the bridge via a 3Com 3C501 ethernet board. 
	
	Does anyone have a Network Managment package which will run
	under 4.2 BSD Unix, and communicate with this bridge??
	The tech. rep. I spoke with said they use OSI CMIP to talk to
	the bridge.

	On another note, can anyone recommend a good IP Router in the
	3K to 4K price range?? 

	Thanks,
	dan

-- 
Dan Hazekamp					rochester!cci632!djh
Computer Consoles Inc. (CCI)			uunet!ccicpg!cci632!djh
Rochester, NY					uunet!rlgvax!cci632!djh
					Internet: cci632!djh@cs.rochester.edu

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 22:21:05 GMT
From:      zepf@optis31.UUCP (Tom Zepf)
To:        comp.protocols.tcp-ip
Subject:   Re: Ignorant question - multiple connections within TCP ports?

In article <1765.AA1765@geo-works> bryan@geo-works.UUCP (Bryan Ford) writes:
>connections - correct?  However, is there a way that there can be more than
>one connection to a single port?  For example, if someone connects to port
>21 on a host to do some FTP stuff, then someone else tries to also connect
>to port 21 on the same host while the first connection is still going, what
>happens?  Does the request get denied, or does another FTP server process
>get started up, or what?

Each TCP connection in a network is distinguished by these four items:

	Peer #1 Address
	Peer #1 Port
	Peer #2 Address
	Peer #2 Port

No two connections may exist with exactly the same values. This usually
enforced by the peers' operating systems.

FTP uses the client's address and port to distinguish multiple
connections to the same server port.

-- 
Tom Zepf					Optigraphics Corporation
scubed!optis31!zepf				9339 Carroll Park Drive
seismo!esosun!optis31!zepf			San Diego, CA 92121

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 22:21:43 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Kenmore MicroWave Oven For Sale

In article <42958@bbn.COM> djw@BBN.COM (David Waitzman) writes:
>The microwave obviously speaks TCP:
>Here is the "traceroute" output to kenmore.kitchen.net from here:
>
>traceroute to kenmore.kitchen.net (224.1.54.1), 30 hops max, 40 bite packets
> 1  circe.bbn.com (128.89.0.247)  0 ms  0 ms  10 ms
> 2  128.89.0.1 (128.89.0.1)  60 ms  70 ms  70 ms
> 3  * * *
> 4  pc.livingroom.house.ny.us (225.9.5.4)  90 ms  90 ms  90 ms
> 5  fridge.kitchen.net (224.4.5.3) 140 ms  150 ms  140 ms
> 6  pc.livingroom.house.ny.us (225.9.5.4)  160 ms  170 ms  160 ms
> 7  fridge.kitchen.net (224.4.5.3) 300 ms  310 ms  300 ms
> 8  pc.livingroom.house.ny.us (225.9.5.4)  320 ms  330 ms  320 ms
> 9  fridge.kitchen.net (224.4.5.3)  340 ms  350 ms  340 ms
>10  kenmore.kitchen.net (224.1.54.1)  360 ms  370 ms  360 ms
>
>Note the temporary routing loop from the pc to the fridge.  Anyone have
>any ideas on why?
>
>-david


	I ran an snmpsrc on kitchen.net and found this:

bu-netcop{kwe}44> snmpsrc livingroom-gw kitchen-net
Copyright (C) 1988 NYSERNet INC

Looking for source of routing of kitchen-net....

gateway=livingroom-gw   next-hop=kitchen-gw     metric=3      remote rip
gateway=kitchen-gw      next-hop=bedroom-gw     metric=205871 remote criscoIgrp
gateway=bedroom-gw      next-hop=livingroom-gw  metric=277889 remote boudoir
receive timed out.  Retrying....
bu-netcop{kwe}45>

	Obviously this kind of appliance networking has some bugs to
be ironed out.  I understand that some appliances do not yet implement
split horizon, in particular some refrigerators.  Perhaps if they
tried a link state algorithm...  Fortunately they decided to do SNMP
(after fierce lobbying from Marty Schoffstall) and didn't wait for
CMIP or else we wouldn't have been able to figure things out this far.

	--Kent England, Boston University

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 89 23:52:39 GMT
From:      torben@DORSAI.ICS.HAWAII.EDU ("Torben N. Nielsen")
To:        comp.protocols.tcp-ip
Subject:   Re:  trace route to OZ

Dave,


	Apparently, there are *two* lines to the UK. And only one goes through
JVNC. That poor line is successivley mauled by X.25 and then a Microvax. So
the delays are understandable. I'd guess the load is quite heavy too since
the ``ping" RTT's exhibit quite a high variance.

	The real problem is that it's oft hard to reach the SMTP ports over
there.

						Torben

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 89 01:07:23 GMT
From:      medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: Kenmore MicroWave Oven For Sale


Of course, this is an illegal activity, as net 224 is reserved for 
Multicast addresses.  In particular 224.0.0.5 and 224.0.0.6 are 
assigned to the OSPF IGP routing protocol.  I believe also that it
is illegal to forward a packet from or to net 224 as this is part
of the range of addresses are that are explicitly single-hop!

					Thanks,
					   Milo

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 89 03:52:37 GMT
From:      karn@jupiter (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Revision of PC/IP scorecard

>Unfortunately, the manual on flash.bellcore.com seems to be out of date;
>in particular, the hosts file has been replaced by something called
>"domain.txt", whose format doesn't seem to be defined in the manual.

As is usual with volunteer projects, the boring part of the job (the
documentation) trails the interesting part (the code) by quite a bit.
The domain.txt file is the cache of domain records maintained by
the resolver. They are in the standard domain database format, eg.,

sun.ka9q.ampr.org.	IN	A	128.96.160.1

(Note the trailing dot on the domain name.)

You need to seed domain.txt with all domain names referenced in your
autoexec.net file. However, if you have domain server(s) nearby, you can
specify it/them in one or more "domain addserver" commands. When this is
done, the responses from the server will be appended to domain.txt,
avoiding future queries to the name server for the same host.

The domain code uses linear search on this file, so it can be slow, and
I don't yet age out old entries. But the existing code has proven quite
adequate for most kinds of use. Occasionally I just edit out all but the
"bootstrap" entries in domain.txt and let them build up again. One of
these days I'll redo the domain resolver with a real database manager
(e.g., the recently released GNU dbm library).

Phil

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 89 08:54:23 GMT
From:      pvo3366@OCE.ORST.EDU (Paul O'Neill)
To:        comp.protocols.tcp-ip
Subject:   Re:  trace route to OZ (indeed!)

>	Apparently, there are *two* lines to the UK......

You've neglected the CORE route to the UK.  The DoD has recently been 
conducting experiments with this route around lunchtime on Wednsdays.

example:
-------------------------------------------------------------------------
traceroute to cs.ucl.ac.uk (128.16.6.4), 30 hops max, 40 byte packets
 1  * * * 
 2  orst-nwnet-gw.UCS.ORST.EDU (128.193.16.2)  10 ms  10 ms  10 ms
 3  ogc-gwy.ogc.edu (129.95.20.54)  40 ms  30 ms  40 ms 
 4  130.42.46.6 (130.42.46.6)  70 ms  70 ms  70 ms 
 5  192.31.173.2 (192.31.173.2)  100 ms  110 ms  100 ms 
 6  Palo_Alto.CA.NSS.NSF.NET (129.140.77.14)  120 ms  120 ms  120 ms
 7  Salt_Lake_City.UT.NSS.NSF.NET (129.140.79.13)  220 ms  200 ms  210 ms 
 8  Palo_Alto.CA.NSS.NSF.NET (129.140.77.15)  220 ms  260 ms  260 ms 
 9  Salt_Lake_City.UT.NSS.NSF.NET (129.140.79.13)  360 ms  360 ms  370 ms 
10  Palo_Alto.CA.NSS.NSF.NET (129.140.77.15)  400 ms  370 ms  330 ms 
11  Salt_Lake_City.UT.NSS.NSF.NET (129.140.79.13)  420 ms *  510 ms 
12  Palo_Alto.CA.NSS.NSF.NET (129.140.77.15)  670 ms  750 ms  770 ms 
13  Salt_Lake_City.UT.NSS.NSF.NET (129.140.79.13)  1240 ms  690 ms  550 ms 
14  Palo_Alto.CA.NSS.NSF.NET (129.140.77.15)  530 ms  570 ms  660 ms 
15  Salt_Lake_City.UT.NSS.NSF.NET (129.140.79.13)  680 ms  640 ms  650 ms 
16  Palo_Alto.CA.NSS.NSF.NET (129.140.77.15)  1360 ms  760 ms  710 ms 
17  Salt_Lake_City.UT.NSS.NSF.NET (129.140.79.13)  720 ms *  680 ms 
18  Boulder.CO.NSS.NSF.NET (129.140.71.15)  860 ms Salt_Lake_City.UT.NSS.NSF.NET (129.140.79.13)  790 ms * 
19  * La_Jolla,CA.NSS.NSF.NET (129.140.6.11)  980 ms * 
20  La_Jolla,CA.NSS.NSF.NET (129.140.6.14)  1240 ms *  1370 ms 
21  La_Jolla,CA.NSS.NSF.NET (129.140.6.11)  1390 ms  1320 ms  1460 ms 
22  192.35.180.1 (192.35.180.1)  90 ms !N La_Jolla,CA.NSS.NSF.NET (129.140.6.14)  1900 ms * 
23  La_Jolla,CA.NSS.NSF.NET (129.140.6.11)  2090 ms *  1230 ms 
24  * * * 
25  * * * 
26  Urbana_Champaign.IL.NSS.NSF.NET (129.140.76.5)  480 ms  1010 ms  490 ms 
27  Pittsburgh.PA.NSS.NSF.NET (129.140.69.12)  570 ms Ithaca.NY.NSS.NSF.NET (129.140.74.5)  650 ms Pittsburgh.PA.NSS.NSF.NET (122.52.1959.140.69.10)  620 ms 
28  Ithaca.NY.NSS.NSF.NET (129.140.74.5)  640 ms  610 ms  710 ms 
29  Pittsburgh.PA.NSS.NSF.NET (129.140.69.10)  1080 ms  580 ms * 
30  * * * 
---------------------------------------------------------------------------

By using Strict Source Routing to run packets around selected backbone sites
a phased-array emitting ELF (read "earth penetrating") syncrotron radiation 
is created.  This particular example emits a focused "pencil-beam" at 
Greenwich.  Examples of "fan-beams" directed upwards have also been reported.
Presumably these are Directed Information Energy tests.  With capabilities
like this, it's not hard to imagine reprogramming re-entry vehicles in flight
to impact harmlessly in the ocean or Canada.

Paul O'Neill                 pvo@oce.orst.edu
Coastal Imaging Lab
OSU--Oceanography
Corvallis, OR  97331         503-737-3251

ps--The traceroute output is real.

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 89 13:17:11 GMT
From:      mckee@MITRE.MITRE.ORG (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: trace route to OZ

>From: "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
>
>First off, it's rather inappropriate for this list to be used for
>network debugging ....

Well ... yes and no.  We don't need the detailed results of the
trace route routine, but we do need frequent reinforcement of the 
suspicion/notion/fact that the present (EGP) routing paradigm is
inadequate.  Something must be done, and that something will likely be
painful.  The community will not accept painful unless convinced of the
need, and "trace route to OZ" is convincing.

Regards - Craig  (standard disclaimers)

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 89 13:36:57 GMT
From:      sgf@brunix (Sam Fulcomer)
To:        comp.protocols.tcp-ip
Subject:   Re: Ignorant question - multiple connections within TCP ports?

In article <11902@ulysses.homer.nj.att.com> smb@ulysses.homer.nj.att.com (Steven M. Bellovin) writes:
>In article <4908@ucdavis.ucdavis.edu>, heberlei@iris.ucdavis.edu (Todd) writes:
>> In article <1765.AA1765@geo-works> bryan@geo-works.UUCP (Bryan Ford) writes:
>> >It appears to me from reading this book that you can have one separate TCP 
>> >connection for each port on a single host.  

Unfortunately some implementations of IP do not allow multiple connections
on listening ports (but then they're not real implementations...). Exos on
a Plexus comes to mind...

Try it, and if it doesn't work it's broken.

Sam
sgf@cfm.brown.edu

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Jul 89 13:46:06 DST
From:      "Jesper L. Lauritsen" <IBTJLL%vm.ibt.dk@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Bridge Terminal Server
>Has anyone had any luck connecting a printer to a bridge terminal
>server??
We have a printer connect like this (cs/200 is a bridge terminal server):
    mini --> cs/200 <--> net <--> cs/200 --> printer
This uses the permanent virtual circut facility and has proven to be
very robust. I have also experimented with a connection like this:
    mini <--> net <--> cs/200 --> printer
This should definitly be feasible but will require changes in the host
spooler depending on the operating system.

>Also, We have a spectrometer that will run kermit. I'd like to be able
>to have it run kermit and be connected to a port on a bridge terminal
>server. My question is: Could any other node on the ethernet gain access
>to the spectrometer, assuming it was running kermit and in "server"
>mode?
Don't know much about this, but the cs/200 can be highly invisible. If you
can connect two PCs directly with a RS232 cable you should be able to
put two cs/200's and a net in between.

I believe a cs/100 is functionally equivalent to a cs/200.

--Jesper

---------------------------------------------------
Jesper L. Lauritsen, system programmer
Domain addr: ibtjll@vm.ibt.dk;  BITNET/EARN: IBTJLL AT DKIBT
K:benhavns Universitet        /    University of Copenhagen
Center for Anvendt Datalogi   /    Center for Applied Datalogy
Studiestr{de 6 o.g.           /    Studiestraede 6 o.g.
1455 K:benhavn K              /    DK-1455 Copenhagen K, Denmark
33 12 01 15                   /    +45 33 120115
-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 89 14:43:44 GMT
From:      FASTEDDY@DFTNIC.GSFC.NASA.GOV (John McMahon - NASA GSFC ADFTO - 301-286-2045)
To:        comp.protocols.tcp-ip
Subject:   Comparison...

Recently there was a "comparison list" posted on the merits of the various
flavors of TCP/IP for PCs and their ilk.  Has anyone ever compiled a similar
item for VAX/VMS systems (and their ilk) ?

My prime concerns would be:

1 - Applications (Telnet, FTP, NFS, SMTP, FINGER, Etc.)
2 - System Overhead (Some products use a "smart" board for the lower-level IP
    stuff, etc.)
3 - Standards Compliance (At least one manufacturer does not support the 
    format of HOSTS.TXT [argh])
4 - Nameserver support
5 - Support for connections "other than Ethernet"

If one hasn't been done...  I'll work on it...

+-------------------------------------+----------------------------------------+
| John "Fast Eddie" McMahon           |    Span: SDCDCL::FASTEDDY (Node 6.9)   |
| Advanced Data Flow Technology Office|    Arpa: FASTEDDY@DFTNIC.GSFC.NASA.GOV |
| Code 630.4 - Building 28/W255       |  Bitnet: FASTEDDY@DFTBIT               |
| NASA Goddard Space Flight Center    |GSFCmail: JMCMAHON                      |
| Greenbelt, Maryland 20771           |   Phone: x6-2045                       |
 +-------------------------------------+----------------------------------------+

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 89 15:17:42 GMT
From:      OLE@CSLI.STANFORD.EDU (Ole J. Jacobsen)
To:        comp.protocols.tcp-ip
Subject:   August ConneXions


You won't want to miss the August issue of ConneXions (Volume 3, No. 8).
It is  a 56 page special issue on Internet Routing and tells you almost
everything you'll want to know about routing. (I realize the serious
omission on my part in not discussing Kenmore Microwave oven topics in
this issue, but a followup is planned....)  Contact me for subscription
information.

Ole J Jacobsen,
Editor, ConneXions--The Interoperability Report
-------

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 89 15:29:44 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  trace route to OZ (indeed!)

Paul,

Your synchrotron radiation was apparently intended to detect CONUS
emitters. The ionospheric heating experiments are being conducted in
Alaska. You are maybe on the wrong frequency. Perhaps whistlers are
to blame.

Dave

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 89 16:47:22 GMT
From:      meggers@orion.cf.uci.edu (mark eggers)
To:        comp.protocols.tcp-ip
Subject:   Slip and routing

Folks,
     I have a nonordinary requirement. What I need to be able to
do is use a slip link to connect and route between two networks. A
picture of what I need is shown below:

 | World
 |
 +------[Cisco]
 |         |
 |         | Our net
 |       --+-----------+----
 |                     |         9600 baud
                    [Something]-----/
                                   /------->[Something]
                                                  |
                                           -------+----------
						Their net

     I've looked at KA9Q on two PCs, but it appears that you have to do
proxy ARP by host. I've heard that Northwestern has router code for
PCs, but the last announcement that I read indicated that slip would
be ready 'real soon now'.
     I realize that we could use a 'real' router, but the people that
want to connect want to minimize cost.

Any thoughts on this would be greatly appreciated.

/mde/

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 89 18:57:11 GMT
From:      IBTJLL@VM.IBT.DK ("Jesper L. Lauritsen")
To:        comp.protocols.tcp-ip
Subject:   Re: Bridge Terminal Server

>Has anyone had any luck connecting a printer to a bridge terminal
>server??
We have a printer connect like this (cs/200 is a bridge terminal server):
    mini --> cs/200 <--> net <--> cs/200 --> printer
This uses the permanent virtual circut facility and has proven to be
very robust. I have also experimented with a connection like this:
    mini <--> net <--> cs/200 --> printer
This should definitly be feasible but will require changes in the host
spooler depending on the operating system.

>Also, We have a spectrometer that will run kermit. I'd like to be able
>to have it run kermit and be connected to a port on a bridge terminal
>server. My question is: Could any other node on the ethernet gain access
>to the spectrometer, assuming it was running kermit and in "server"
>mode?
Don't know much about this, but the cs/200 can be highly invisible. If you
can connect two PCs directly with a RS232 cable you should be able to
put two cs/200's and a net in between.

I believe a cs/100 is functionally equivalent to a cs/200.

--Jesper

---------------------------------------------------
Jesper L. Lauritsen, system programmer
Domain addr: ibtjll@vm.ibt.dk;  BITNET/EARN: IBTJLL AT DKIBT
K:benhavns Universitet        /    University of Copenhagen
Center for Anvendt Datalogi   /    Center for Applied Datalogy
Studiestr{de 6 o.g.           /    Studiestraede 6 o.g.
1455 K:benhavn K              /    DK-1455 Copenhagen K, Denmark
33 12 01 15                   /    +45 33 120115

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jul 89 02:50:38 PDT
From:      cire|eric <cire@cisco.com>
To:        sun.soe.clarkson.edu!nelson@tcgould.tn.cornell.edu (Russ Nelson)
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: TCP/IP on HP-IL?

This is a little bizzare Russ.  How you doing bud?  I think
I knew you from some time earlier.  Perhaps a previous life....


>> >From tcp-ip-RELAY@SRI-NIC.ARPA  Fri May  5 09:10:54 1989
>> Date: 4 May 89 02:36:50 GMT
>> From: sun.soe.clarkson.edu!nelson@tcgould.tn.cornell.edu  (Russ Nelson)
>> Organization: Clarkson University, Postdam NY
>> Subject: TCP/IP on HP-IL?
>> References: <1989May3.180345.6936@utzoo.uucp>
>> Sender: tcp-ip-relay@sri-nic.arpa
>> To: tcp-ip@sri-nic.arpa
>> 
>> Has anyone ever played with the idea of doing TCP/IP over HP-IL?
>> (HP-IL, for those unfamiliar with it, is a 1 Mbps asynchronous
>> current- loop ring network meant for small low-power devices such as
>> the HP-41 calculator; I recently picked up an HP-IL interface for the
>> IBM-PC.)  SLIP and friends should be directly applicable.
>> 
>> (Henry -- I'm only partially teasing -- it would be an interesting hack --
>> maybe I could start a competition for the smallest machine on the Internet?
>> But anyway, Phil Karn's NET would work nicely as a router -- all you would
>> need is a MIDI packet driver.  Send me a MIDI interface for the PC and
>> programmer's docs and I'll write one.)
>> --
>> --russ (nelson@clutx [.bitnet | .clarkson.edu])
>> I'm a right-to-lifer -- everyone has a right to earn a living sufficient to
>> feed himself and his family.

-c
cire|eric

Eric B. Decker
Token Ring Development
cisco Systems - engineering
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941
-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 89 20:09:55 GMT
From:      cdobbins@ncrcae.Columbia.NCR.COM (Charlie Dobbins)
To:        comp.protocols.tcp-ip
Subject:   bridge suggestions


I am requesting some help from those with networking experience with bridges. Our current engineering network is growing rapidly (400 plus nodes) and we feel it is time to isolate some of the traffic. We think that bridges will help solve some of the high traffic problems we are seeing which we think leads to large delays and constant jams. We also have two networks which we need to bridge together. One is a secure network(has been isolated physically from the engineering network and supports the XNS proto


col family) and the other is the tcp/ip engineering network previously mentioned.

Question 1 - What name brand bridges should we consider for dividing the tcp/ip network up into smaller segments? Our current engineering network runs steady at around 20% of the bandwidth with peaks of 60% with no bridges. Packet rates average around 1000 packets/sec but do go higher at peak times.

Question 2 - What bridge would be recommended for the secure net to engineering net problem. The secure net does not have a great deal of traffic but it most important to restrict access into the secure network. Does the fact that the sec ure network runs the XNS protocol suite and the engineering network runs a combination of tcp/ip and XNS make a difference?

Any suggestions or help based on your own experience will be greatly appreciated
We have installed a Retix model 2200 to help in one area ofthe engineering network as of yesterday. Is this a good start? Has anyone had experience with this product? 


Thanks in advance......... Charlie Dobbins (cdobbins@Columbia.NCR.COM)
                                           (voice 803-791-6541)

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 89 01:15:56 GMT
From:      mike@lll-lcc.UUCP (mike hummell)
To:        comp.protocols.tcp-ip
Subject:   3COM 3c503: what software under msdos 3.31 runs it?

I'm not ethernet-knowledgeable, so excuse naive questions, but where can I 
find/buy software to use a 3com 3c503 etherlink2 card?  3com doesn't seem to 
know and the vendors I've called don't know.  They say to ask friends.   So,
friends, I'm asking!  Are they're versions of Ftp, telnet, (others?) that
will run on a Compaq Deskpro 386/20  , under Compaq's MSDOS 3.31, with a 
3COM 3c503 etherlink2 card  connected to an ethernet network ?

Thanks in advance   ... Mike Hummell

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 89 01:48:26 GMT
From:      tony@rata.vuw.ac.nz (Tony Martindale)
To:        comp.dcom.lans,comp.sys.mac,comp.protocols.tcp-ip,comp.protocols.appletalk
Subject:   Summary: Backup via network


	 BACKUP VIA NETWORK, REQUEST FOR INFO. SUMMARY
	 =============================================

 Original Message:
 ----------------

     We have recently invested in a campus wide network.  At the moment 
 the network is Ethernet running on optical fibre, in the future we hope 
 to upgrade this to FDDI.

     One of the services we hope to offer users of the network is remote
 backup of their personal computers, file-servers, departmental computers 
 etc, onto our central machine(s) with disk farm(s) attatched.  

 *Question*:  Is there any software out in netland that exists, or is being 
 developed that does this sort of thing?  

 Software using TCP/IP would be of the most interest to us, however info. on 
 any software would be appreciated.  If there is no software out there at all
 we are considering developing the software.

 *Questions*:  If we were to develop our own software, what functions, apart 
 from full and partial backup/restore, would people like to see in such a 
 system?  Are there other people/organisations, out there, who would be 
 interested in a backup system like this?

	 If we were to "roll our own" the intitial environment would probably 
 be a Unix server backing up, Macs on appletalk via Kinetics/Multigate, IBM PC
 clones and Unix workstations on Ethernet.
     Software that we know about is by Dan Tappan, at BBN Corporate Computer
 Resource Centre.  This software backs up a Mac via a Kinetics FastPath 
 bridge to a Unix machine running CAP.
     Replies via email please.  If there is enough response I will post a
 summary.  Many thanks in advance ...


 Comments:
 --------

     Thanks to everone who replied to my posting, I received 19 replies in
 total.  In this summary only those replies with relevant information have 
 been included.  Those people who replied asking for replies to be sent to 
 them I have/will mail/ed them a copy of this summary.
     Some replies have been edited, mainly formatting and cutting down
 signatures.
     I would be interested in any more information regarding this subject,
 please reply via email.
     In short there is no software that fits our needs exactly.  There are
 backup capabilites with some network software packages, and some 
 people/organisations that have written software for their own particular 
 needs.  The final reply in this summary suggests someone may be developing 
 a commercial product.
     If we choose to develop our own system, I will keep those people who
 replied informed.


 Replies:
 -------


 From: Jim Lowe <james@csd4.milw.wisc.EDU>
 Organization: University of Wisconsin-Milwaukee

 If you find out anything from your query I would be interested in hearing
 about it.  We are in the process of either writing a backup system from
 scratch or purchasing one.  Our computer center here would like to do
 the same things that you are talking about (backing up other peoples files,
 large disk farm, nfs, etc).

 We may end up writing the backup system ourselfs, but that is still waiting
 for management approval.

 There is a package called BUMP that Terry Slatery (tcs@brl.mil) is working
 on.  BUMP is used to migrate files on and off a filesystem to tape.  If
 we write our own backup system we will probably pilfer as much BUMP code
 as we can into it.

 -- 
	- Jim
 Internet: james@csd4.milw.wisc.edu		Uucp:	   uwmcsd4!james
 Bitnet:	  james%csd4.milw.wisc.edu@INTERBIT


 From: dab@vax.ftp.COM
 Organization: FTP Software, Inc.

 Your message wasn't clear if you were only interested in MACs or
 wanted to be able to backup IBM PCs as well.  This message is about
 how to backup IBM PCs.  Our product, PC/TCP, comes with an
 implementation of TAR which uses the Berkeley rmt and rsh or rexec
 protocols.  As an extension to TAR I've added the ability to do
 incremental dumps (a la dump/restore) so TAR could be more useful for
 doing backups.  In the next version, I intend to be able to do
 incremental backups using the DOS archive bit as well.  If you have
 UNIX hosts around as servers, this is a pretty easy system to use.  If
 you don't, I know of one group who has written the appropriate server
 code for VMS or I can tell you the protocol if you'd like to implement
 it anywhere else.

						 David Bridgham
						 FTP Software, Inc.
						 (617) 246-0900


 From: frog!barr@uunet.UU.NET
 Organization: Charles River Data, Framingham MA

 I don't know of existing products, other than Novell stuff, but you
 remind me of an interesting proposal at Apollo to use their NCS for
 this purpose:  use their location broker(s) and remote procedure calls (RPCs)
 to backup via TCP/IP sockets (UDP/IP sockets).  

 It would indeed be relatively easy & platform-independent to do.  I last year
 used NCS on Prime & MSDOS PC systems, for database front/backend RPCs, all 
 talking over NCS via UDP/IP sockets.  The contractors who supplied NCS 
 for MSDOS, now called 'Course-6' (?), in Cambridge MA, proposed writing 
 this backup software in conjunction with Apollo.  I don't know what came 
 of it, but NCS (Network Computing System) functionality would do a lot of 
 the work by itself.


 From: thumper!pff@bellcore.bellcore.COM
 Organization: Bellcore MRE

 Sounds as if we have a mutual interest in this.  We are now having all new
 systems include an Ethernet card (Dove FastPath III, or Apple[ 3Com's]) in
 hopes that some day we will figure out how to implement Dan Tappan's product.
 The problem is, is that I'm a "Mac" person, and the Unix-eese person only 
 speaks
 Unix.  Neither one of us really understands the others "lingo / language".  
 We're getting there.  According to one Tappan product user upstairs (BIG 
 R&D facility = another world upstairs!) Tappan's Dumper, etc; are not 
 without fault - somewhat ambiguous as to what error occurred, etc.  
 Nevertheless it seems to be the (only / best) game in town.

 I'd be very interested in what you find out.  

 TOPS ala Unix is better than a sharp stick in the eye, but not "automatic".
 We can't trust our users to even do a simple finder level "drag" to the TOPS 
 (Unix) volume.  The process that we end up with must be "automated" and fast.
 But I believe the Ethernet cards will be fast enough.  Hint: It seems to 
 me that even the Ethernet cards don't use full Ethernet bandwidth, when 
 compared to say a Sun 3 or 4.  Nowhere near the "normal" 10MB/S capacity of 
 Ethernet.  Still, a helluva lot faster than Atalk.

 Someday, SOMEONE will figure out that there are some serious Mac users here,
 that know what Ethernet & Unix are...

 Please let me know of any "intelligent" responses you might get - e-mail 
 is preferred since I don't read this group every day.

 Best Regards,
 Pete Ferris


 From: mcvax!cgch!whwb@uunet.UU.NET

 Hi Tony,
 I am looking for such a product as well. I should run on top of TCP/IP and 
 be able to backup UNIX to central DEC systems. If you connect the systems 
 with NFS you can write the backup with standard system backups to the
 central site. Retrieving a certain file for restore is awkward using
 NFS since the most backup routines scan through the whole backup (assuming
 it is a tape) to find the file. This delivers a high network load with a 
 low outcome.

 There is one similar solution around on top of Hyperchannel (at least for 
 VAX'es and IBM's) named HYPERTAPE (contact: MultiStream Systems 
 Incorporated, Denise Yegge, P.O.Box 497, Excelsior, Minnesota 55331, USA). 
 They had the plan to run it also on top of TCP/IP. This information is from 
 Feb. 1988, you may check if it is still true.

 Please send me any answers you get in this subject.

 Hans W. Barz, R.1032.3.34, CIBA-GEIGY, 4002 Basel, Switzerland
 mail: whwb@cgch.uucp


 From: George Bray <geo@surf.sics.bu.oz>

 > *Question*:  Is there any software out in netland that exists, or is being 
 > developed that does this sort of thing?  

 I've heard of a program called Redux that a LocalTalk user can run to
 backup his hard disk to an AFP server, but this is for small installations.

 We have a similar setup to you. Bond Uni is mainly a UNIX environment
 with many Macs. We're just getting the CAP stuff running on some VAXen
 and would like to solve the backup problem too.

 > all we are considering developing the software.

 Yes! Do it!

 > *Questions*:  If we were to develop our own software, what functions, apart 
 > from full and partial backup/restore, would people like to see in such a 
 > system?  Are there other people/organisations, out there, who would be 
 > interested in a backup system like this?

 Have an INIT running in the background detecting the shutdown sequence.
 The machine will ask you if you want to backup.
 Settings for incremental and full backups in the chooser. You choose a
 device to back up on.

 Restoration: The ability to restore only a file or folder from backup
 is selected from a tree heirarchy (Like HFS Backup). Or maybe a 
 FontDA Mover interface?

 >     If we were to "roll our own" the intitial environment would probably 
 >be a Unix server backing up, Macs on appletalk via Kinetics/Multigate, IBM PC
 >clones and Unix workstations on Ethernet.

 Yup

 Use MacTCP. MacNFS will be out soon. Maybe you could interface with that.

 George Bray           AppleLink: AUST0287      MacNet: GEO   Pager:075-50-7004
 Byte Technologies     ClubMac: GEO   CompuServe: 72711,253   Phone:075-95-1111
 at Bond University    Internet:     geo@surf.sics.bu.oz.au   Fax:  075-95-1160


 From: Bjorn Satdeva <bjorn@sysadm.sysadmin.COM>

 >     One of the services we hope to offer users of the network is remote
 > backup of their personal computers, file-servers, departmental computers 
 > etc, onto our central machine(s) with disk farm(s) attatched.  
 > 
 > *Question*:  Is there any software out in netland that exists, or is being 
 > developed that does this sort of thing?  
 > 

 Hi Tony 

 We have some shell scripts, which we are using at some client sites to
 provide backup accross the network.  They are using the remote shell
 for execution and data transfer, and the archives is created using
 cpio and compress.  They are of cause not able to work with non-Unix
 systems, and have the draw-back, that the central backup machine(s) must be
 trusted (in /.rhost on the remote machine)

 We are planning on rewirting them "some time real soon now", using C and
 Kerberos for autentication.  If you want the scripts, send me mail.

 Bjorn Satdeva

 ---
 Bjorn Satdeva --  email: bjorn@sysadm.sysadmin.com or uunet!sysadm!bjorn


 From: jerry@athena.arc.nasa.GOV,

 There is a new version of Unitech's backup program that is designed to
 do backups over the net. This is only for Unix boxes, and we are to Beta
 test is in less than a month.

 Jerry Scharf
 Nasa Ames research center


 From: jerry@olivey.ATC.Olivetti.COM

 In article <1989Jun8.220321.13679@comp.vuw.ac.nz> you write:
 >    One of the services we hope to offer users of the network is remote
 >backup of their personal computers, file-servers, departmental computers 
 >etc, onto our central machine(s) with disk farm(s) attatched.  

 Sun's PC/NFS with the extra "lifeline" package supports doing PC packups
 to the central server.


 From: msd@bo.ind.TRW.COM

 Tony:

 I am currently working on such a thing, with the intention that it become
 a commercial product.  The specs are currently proprietary, so I can't
 let them out.  If you have done any kind of requirements survey though,
 I might be able to tell you what kind of match there may be with what
 you're after.

 Sorry for the vagueness here.

 ++msd -- msd@TRW.Com -- Marc S. Dye (ayuda Company)
 1393 Stonemeadow Ct.; Camarillo, CA  93010; USA  (805)987-0433


			 END OF SUMMARY
			 ==============

Tony Martindale                            Computing Services Centre,
Domain: tony@rata.vuw.ac.nz                Victoria University of Wellington,
Path: ...!uunet!vuwcomp!rata!tony          P.O. Box 600,
Tel: +64 4 721-000  Fax: +64 4 712-070     Wellington, New Zealand.

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 89 05:13:35 GMT
From:      eloranta@tukki.jyu.fi (Jussi Eloranta)
To:        comp.protocols.tcp-ip
Subject:   Re: Bridge Terminal Server

In article <8907201856.AA25243@ucbvax.Berkeley.EDU> IBTJLL@VM.IBT.DK ("Jesper L. Lauritsen") writes:
>>Has anyone had any luck connecting a printer to a bridge terminal
>>server??
 (text deleted...)
>This should definitly be feasible but will require changes in the host
>spooler depending on the operating system.
>

We have system running under BSD UNIX that allows access to printers that
are connected to bridges... It's available via anon. ftp from tukki.jyu.fi
(128.214.7.5). The file name is /pub/local/etherprint.tar.Z.

This program is not complete but it works :-)

-jme
-- 
============================================================================
Jussi Eloranta               Internet(/Bitnet):
University of Jyvaskyla,     eloranta@tukki.jyu.fi
Finland                      [128.214.7.5]

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 89 05:39:16 GMT
From:      miket@bnrmtv.UUCP (Michael Thompson)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   Question regarding 'bootp' protocol


Hello,

I am looking for any sources of information regarding the 'bootp'
Ethernet protocol.  Quite frankly I know very little about it, but
what I did here makes it sound like it may be useful to me.  Are
there any archive sites which have a document or sources that I
can get a hold of which describe 'bootp'?  Is it a publically available
protocol?  Is it related to Sun's 'nd' protocol?  

I would be grateful for any information regarding this subject.

Mike

-----------------------------------------------------------------------------
			  |  Michael P. Thompson, Member Scientific Staff   |
		 ###      |  Northern Telecom, Dept. 4Z32                   |
####  #####    #########  |  685A E. Middlefield Road                       |
############ ###########  |  Mountain View, CA  94039-7277                  |
####    ####    ####      |  PH. (415) 940-2575  FAX. (415) 966-1067        |
####    ####### ########  |        amdahl! --\                              |
####     #####   ######   |  UUCP. ames! ----->-- bnrmtv!miket              |
			  |        hplabs! --/                              |
-----------------------------------------------------------------------------

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jul 89 13:02:17 CDT
From:      "Linda Winkler,   312-972-7236" <B32357@ANLVM.CTD.ANL.GOV>
To:        <TCP-IP@SRI-NIC.ARPA>
We are looking for SNMP software.  Our lawyers could not (or would
not as the case may be) agree on the Nysernet license.  Can anyone
suggest other sources of software?  Thanks,             Linda
-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 89 14:07:13 GMT
From:      dorl@vms.macc.wisc.edu (Michael Dorl - MACC)
To:        comp.protocols.tcp-ip
Subject:   Appropriate use of net - Sample documents wanted

I've been asked to prepare a page for our campus principle
investigator handbook stating appropriate use policies for
the Internet and BITNet.

I'd appreciate anything you might have along these lines or
pointers to official Internet or BITNet policies.

Michael Dorl (608) 262-0466    fax (608) 262-4679
dorl@vms.macc.wisc.edu
dorl@wiscmacc.bitnet

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1989 19:24-EDT
From:      CERF@A.ISI.EDU
To:        iris!heberlei@UCDAVIS.UCDAVIS.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Ignorant question - multiple connections within TCP ports?
The CALLING PORT is supposed to be selected at Host A to be distinct
for each TCP connection initiated. Thus, the well-known target
Host B port (513) can be the same for both connections, but the
two are distinguished by the port pairs:

Connection 1: Port A1 on Host A, Port 513 on HOst B
Connection 2: Port A2 on Host A, port 513 on Host B.

The second option you cite is flat wrong.

Vint Cerf
-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 89 15:43:01 GMT
From:      DIXON-R@OSU-20.IRCC.OHIO-STATE.EDU (Bob Dixon)
To:        comp.protocols.tcp-ip
Subject:   Novell and TCP/IP

Novell sells a product developed by Micom-Interlan, called their tcp/ip
gateway. We have had it here for about a year, working with Novell to test
and debug it. There were many many problems with their early implementations
of tcp/ip. But to their credit they have stuck with it and fixed all the
problems we kept telling them about. Now it is to the point that we can declare
it a basically working and useable product for our campus internet.
 It is not yet in wide use here, as we have been primarily a Banyan campus.

                                        Bob Dixon
                                        Ohio State University
-------

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 89 17:19:40 GMT
From:      brunner@bullhead.uucp
To:        comp.protocols.tcp-ip
Subject:   Re: Need info on U. of Wisconsin 3798-FAL Product.


Yesterday Jay Elinsky (IBM Yorktown) rang me up after a user here had
mentioned to him that I was chasing what appears to be an ip reassembly
bug in either AIX 2.2.1 or in the VM ip implementation...  Jay is not
the contact for the initial query, but for technical queries which are
sent to this list, I think that he's a good person to ask.



Eric Brunner
uunet!ibmsupt!brunner

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 89 18:02:17 GMT
From:      B32357@ANLVM.CTD.ANL.GOV ("Linda Winkler,   312-972-7236")
To:        comp.protocols.tcp-ip
Subject:   (none)

We are looking for SNMP software.  Our lawyers could not (or would
not as the case may be) agree on the Nysernet license.  Can anyone
suggest other sources of software?  Thanks,             Linda

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 89 20:13:14 GMT
From:      pasteur!talvola@ucbvax.Berkeley.EDU  (Erik Talvola)
To:        tcp-ip@sri-nic.arpa
Subject:   Setting up a pseudo-domain on a Sun network


  I have a question about how to set up a new "fake" domain on a network of Sun
systems here.  It won't be happening for a while, but I would like some input
on how to do this.  Note, I have no experience with setting up nameservers
or anything like that - so any references will help.  

  What I need is this:  We have a network of 60 Suns here set up on 4 fileservers.
They are called widow.berkeley.edu, weaver.berkeley.edu, wolf.berkeley.edu and
rosebud.berkeley.edu for reference.  The first 3 have 16 machines, rosebud has
12.  Right now, students (only class accounts are on the machines) have to log
into a specific workstation - i.e., no accounts on the servers.  However, we
want to set things up so that people can pretend they are logging onto a server,
and have the server call a fake nameserver which doesn't look in a list, but
rather calls a program (which is already written) which returns the lowest loaded
server, and then returns that, so that the user is logged onto the individual
station.

  Right now, I am not sure how to do this.  One suggestion was to, instead of
using the server name, make a new domain, web.berkeley.edu (which is an alias
to widow right now), and have people log on like web1.web.berkeley.edu, which
would then call the alternate nameserver.

  Anyway, I am a complete beginner at this, and possibly could answer my own
questions anyway, but I thought I'd throw this out.  Just any comments on
documentation on the nameserver would be nice too.  The Suns will be running
SunOS 3.5 when I have to set this up - right now it is 3.2 I think.

  Sorry if this is the wrong group, but it sounded possibly correct.  Many
thanks in advance for any information.


--
---------------------------+
Erik Talvola               | "It's just what we need... a colossal negative 
talvola@cory.berkeley.edu  | space wedgie of great power coming right at us
...!ucbvax!cory!talvola    | at warp speed." -- Star Drek
-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 89 20:27:04 GMT
From:      steve@NOTE.NSF.GOV (Stephen Wolff)
To:        comp.protocols.tcp-ip
Subject:   Computer security report available


COMPUTER SECURITY: Virus Highlights Need for Improved Internet Management
(GAO/IMTEC-89-57) is the first U.S. General Accounting Office report that
has been made available on a wide-area computer network.  The report is
particularly relevant to Internet users -- it examines Internet security
and vulnerability to issues and factors relating to the the prosecution of
virus crimes.

     **************************************************************
     *   This is the first GAO report to be made available over   *
     *   the Internet.  GAO wants to know how many people         *
     *   acquire the report this way.  If you do, please send     *
     *   mail to me <swolff@nsf.gov> and I'll keep count for      *
     *   them.  Your name will not be saved or used.              *
     **************************************************************

The report is available by anonymous ftp from the NSF Network Service
Center on host nnsc.nsf.gov <128.89.1.178> in directory pub, from the NSF
Information Services host nis.nsf.net <35.1.1.48> in directory nsfnet, and
on host umd5.umd.edu <128.8.10.5> in directory pub.  In all cases, log in
as user anonymous, with password guest. The file is about 104 kilobytes.

If you would prefer a printed copy, send me your mailing address and GAO
will post one to you directly.

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 89 20:49:01 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Terminology deplored

>Recently I have noticed the rise of the word "gate" as a contraction of
>"gateway" ...  The English language is too marvelous a machine to deserve
such maltreatment.

Here, here.  Although vigorous writing is concise, it is also precise.
The term "gate," and the term "gateway" when used in the loose ARPAnet
style, should both be banned when the intent is an IP-level router.
There is a perfectly good term, "router" that should be used instead,
so that "gateway" may be reserved for "application level gateways," one
step up the ARM from routers.

Only partially in jest, I remain,
    JQ Johnson, Dir., Network Services	voice:     503-686-4394
    Office of University Computing	Internet:  jqj@oregon.uoregon.edu
    University of Oregon		Bitnet:    jqj@oregon
    Eugene, OR  97403			UUCP:	   ...!uoregon!jqj

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 89 20:57:49 GMT
From:      urjlew@ecsvax.UUCP (Rostyk Lewyckyj)
To:        comp.protocols.tcp-ip
Subject:   Whose error message is this?


  
I tried to use tn3270 on a CONVEX C220 to access an
IBM system with      running VM CMS and IBM's TCP/IP product.
The Convex tn3270 connected to the IBM system and flashed the
VM logon screen at me. However it immediately displayed the
error message
  LOGON ERR from mvaddch at 1899 (23,59)    59)
and    nd left me back at the UNIX    Convex system prompt. I.e. quit tn3270
program.
  
I then tried to connect to a second IBM VM system at a  nother
site and got the same result.
The Convex site is GIBBS.acs.unc.edu, and the IBM sites I tried
are UNCVM1.ace.  s.unc.edu and CORNELLF.tn.cornell.edu
No one here has any ideas on who is issuing this message.
Can ano yone on the net provide an answer?
Please e-mail.
-----------------------------------------------
  Reply-To:  Rostyslaw Jarema Lewyckyj
             urjlew@ecsvax.UUCP ,  urjlew@unc.bitnet
       or    urjlew@uncvm1.acs.unc.edu    (ARPA,SURA,NSF etc. internet)
       tel.  (919)-962-9107

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 89 21:26:03 GMT
From:      ww0n+@ANDREW.CMU.EDU (Walter Lloyd Wimer III)
To:        comp.protocols.tcp-ip
Subject:   Re: Ignorant question - multiple connections within TCP ports?



From RFC 793 (Transmission Control Protocol):

 Multiplexing:

    To allow for many processes within a single Host to use TCP
    communication facilities simultaneously, the TCP provides a set of
    addresses or ports within each host.  Concatenated with the network
    and host addresses from the internet communication layer, this forms
    a socket.  A pair of sockets uniquely identifies each connection.
    That is, a socket may be simultaneously used in multiple
    connections.


So in other words, just as two points determine a line in mathematics,
two sockets determine a connection in TCP.


Walt Wimer
Network Development
Carnegie Mellon University

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 89 21:51:36 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Announcing a little board-room shakeup


At its July meeting, the Internet Activities Board made some modifications
in the management structure for the Internet.  An outline of the new
structure is given below.  These changes resulted from an appreciation
of our successes, especially as reflected in the growth and vigor of the
IETF, and in rueful acknowledgment of our failures (which I will not
enumerate).  Many on these lists are concerned with making the Internet
architecture work in the real world.  We believe the new structure will
provide a more effective organization and better leadership, to give us
all more leverage in solving present issues and evolving for the future.

Vint Cerf is unable to attend the IETF meeting next week, but he
will be present via video tape to elaborate on these matters, and
Dave Clark will be present in the flesh to answer questions.

Bob Braden, for the IAB



             
            The Internet Activities Board and its Task Forces
            
                             July 1989
                             

A. INTRODUCTION

The Internet, begun as a DARPA-funded experiment in internetworking, has
become the prototype national research network, forming a major fraction
of the networking infrastructure for the research community and,
increasingly, the government and business sectors.  The TCP/IP technology
has been propagated even more widely into business and industry.

Networking and internetting are now entering a new era with the emergence
of extremely high speed packet switching technology and with the steadily
growing availability of OSI software.  The decade of the 1990's is likely
to prove as revolutionary in network technology development as the
ARPANET was almost twenty years ago.

The Internet Activities Board (IAB) functions as a Board of Directors for
the Internet.  The IAB itself set technical policy and standards for the
Internet protocols and architecture, and reviews the work of its two
major task forces: the Internet Engineering Task Force (IETF) and the
Internet Research Task Force (IRTF).

Representatives of the government agencies that sponsor important
segments of Internet research and infrastructure are members of the
Federal Research Internet Coordinating Committee (FRICC).  The FRICC
is concerned with the present Internet and the future National
Research Network.  The IAB and the FRICC work closely together.

B. THE IAB

The IAB is an independent committee whose members generally share a
long-term involvement in, and responsibility for, Internet design,
engineering, and management.  The IAB members were chosen for the
specific roles they play ( e.g., the chairs of the IETF and IRTF), to
represent major groups in the Internet community (e.g, national
network, vendor, government, and international groups), and for specific
areas of expertise (e.g., security).  They are deeply committed to
making the Internet function effectively and to evolving the Internet
to meet a large scale, high speed future.  All IAB members are required
to have at least one other major role in the Internet community in
addition to their IAB membership.

The IAB chair serves for a period of two years.  The current IAB chair
is Vint Cerf of NRI, who has been called the "father of the Internet".
In 1974, he co-authored with Bob Kahn the original paper on the
Internet architecture.  As a program manager at DARPA he directed the
research effort that resulted in development of the TCP/IP protocol
suite, and directed the construction of the prototype of today's
Internet.

The IAB membership is currently as follows:

    Vint Cerf         - Chairman
    Dave Clark        - IRTF Chairman
    Phill Gross       - IETF Chairman
    Jon Postel        - RFC Editor
    Bob Braden        - Executive Director
    Hans-Werner Braun - NSFNET Liaison
    Barry Leiner      - CCIRN Liaison
    Dan Lynch         - Vendor Liaison
    Steve Kent        - Security
    
The IAB typically meets four times a year, to supplement its work by
electronic mail.   Whenever possible, and at least once a year, the IAB
plans to hold its meetings in conjunction with an IETF meeting.

In more detail, the IAB performs the following functions:

   *  Sets Internet Standards

   *  Manages the RFC publication process

   *  Reviews the operation of the IETF and IRTF

   *  Performs strategic planning for the Internet, identifying
      long-range problems and opportunities

   *  Acts as external policy representative for the Internet
      community.
      
   *  Resolves technical issues which cannot be treated within
      the IETF or IRTF frameworks.  

   
C.  The Internet Engineering Task Force

The Internet has grown to encompass a large number of widely
geographically dispersed networks in academic and research communities.
It now provides an infrastructure for a broad community of interest.
Moreover, the family of Internet protocols and system components has
moved from experimental to commercial development.  To help coordinate
the operation and management of the Internet, the IAB established the
Internet Engineering Task Force with the charter to:

1.  Act as a clearinghouse to promote the exchange of information
    within the Internet community.  This community includes Internet
    software and hardware developers, Internet operators and Internet
    research and development groups.

2.  Identify pressing and relevant short- to mid-range problem areas
    and convene Working Groups to develop solutions.  Working Groups
    might deal with a wide range of Internet issues, such as operational
    management problems or protocol enhancements that would improve
    Internet performance or extend the range of application of the
    architecture.

3.  Report Working Group results and recommendation to the IAB and 
    to the Internet community at large.

The Internet Engineering Task Force is a large open community of network
designers, operators, vendors, and researchers concerned with the Internet
and the Internet protocol suite.  The work of the IETF is governed by
a board known as the Internet Engineering Steering Group, or IESG.  The
chairman of the IETF and of the IESG is Phill Gross of NRI.

The work of the IETF is performed by subcommittees known as Working
Groups.  There are currently more than 20 of these.  Working Groups tend
to have a narrow focus and a lifetime bounded by completion of a specific
task, although there are exceptions.  The IETF is generally the major
source of proposed protocol standards, for final approval by the IAB.

The IAB has delegated to the IETF general responsibility for making the
Internet work, and, to the IESG in particular, responsibility for the
resolution of all short- and mid-range protocol and architectural issues
required to make the Internet function effectively.

The members of the IESG are, in addition to the IETF chairman, Area
Technical Directors (ATDs).  Each ATD has primary responsibility for
one area of Internet engineering activity, and hence for a subset of
the Working Groups.  The ATDs perform a technical management function
that is vital to the function and development of the Internet; they
are selected not only for their technical expertise but also for
their managerial skills and judgment.

For more information on the Internet Engineering Task Force, on attending
meetings and proposing or joining Working Groups, contact Phill Gross,
Corporation for National Research Initiatives (gross@SCCGATE.SCC.COM
pgross@NRI.RESTON.VA.US, 703-620-8990).

D.  The Internet Research Task Force

The IAB is concerned with promoting research in networking, to develop
the technology that the IETF will need; this is the job of the Internet
Research Task Force, or IRTF.  

In the area of network protocols, the distinction between research and
engineering is not always clear, so there will sometimes be overlap
between activities of the IETF and the IRTF. There is, in fact,
considerable overlap in membership between the two.  This overlap is
regarded as vital for cross-fertilization and technology transfer.  In
general, the distinction between research and engineering is one of
viewpoint and sometimes (but not always) time-frame.  The IRTF is
generally more concerned with understanding than with products or
standard protocols, although specific experimental protocols may have to
be developed in order to gain understanding.

The IRTF is a community of network researchers, generally with an
Internet focus.  The work of the IRTF is governed by a board known as
the Internet Research Steering Group or IRSG.  The chair of the IRTF
and of the IRSG is Dave Clark of the MIT Laboratory for Computer
Science.  Clark played a seminal role in development of the Internet
architecture, and for nearly 10 years guided the Internet development
and deployment as chair of the IAB and as "the Internet Architect".

As befits their research goals, the IRTF and IRSG are organized in a
much less formal manner than are their engineering counterparts.  The
IRTF is organized into a number of Research Groups (RG's), and the
chairs of these RG's sit on the IRSG.  These groups typically have 10
to 20 members, and each covers a broad area of research, pursuing
specific topics, determined at least in part by the interests of the
members as well as recommendations from the IAB and IETF.

===============================================================================

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 89 23:24:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Ignorant question - multiple connections within TCP ports?

The CALLING PORT is supposed to be selected at Host A to be distinct
for each TCP connection initiated. Thus, the well-known target
Host B port (513) can be the same for both connections, but the
two are distinguished by the port pairs:

Connection 1: Port A1 on Host A, Port 513 on HOst B
Connection 2: Port A2 on Host A, port 513 on Host B.

The second option you cite is flat wrong.

Vint Cerf

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 89 23:36:56 GMT
From:      mike@lll-lcc.UUCP (mike hummell)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   SUMMARY: 3com's 3c503: what software under msdos 3.31 runs it?

I posted this (following) query yesterday and got super-fast and very good
replies (5 of them),  just what I needed to know.  THANKYOU  very much!

Original Posting:
----------------
I'm not ethernet-knowledgeable, so excuse naive questions, but where can I 
find/buy software to use a 3com 3c503 etherlink2 card?  3com doesn't seem to 
know and the vendors I've called don't know.  They say to ask friends.   So,
friends, I'm asking!  Are they're versions of Ftp, telnet, (others?) that
will run on a Compaq Deskpro 386/20  , under Compaq's MSDOS 3.31, with a 
3COM 3c503 etherlink2 card  connected to an ethernet network ?

------------------------------------------------------------------------------
From @CUNYVM.CUNY.EDU:RAF@NIHCU.BITNET Fri Jul 21 08:14:28 1989
Return-Path: <@CUNYVM.CUNY.EDU:RAF@NIHCU.BITNET>
From: "Roger Fajman" <RAF%NIHCU.BITNET@CUNYVM.CUNY.EDU>
Subject:  Re:  3COM 3c503:  what software under msdos 3.31 runs it?

FTP Software's PC/TCP supports the 3C503.  I think that recent
versions of NCSA Telnet may also support it, but I'm not
absolutely certain of that.

------------------------------------------------------------------------------
From @bridge2.ESD.3Com.COM,@vax.SPD.3Com.COM,@gw3com:Eric_Siegel@DSD.3Mail.3Com.COM Fri Jul 21 09:04:53 1989
Return-Path: <@bridge2.ESD.3Com.COM,@vax.SPD.3Com.COM,@gw3com:Eric_Siegel@DSD.3Mail.3Com.COM>
From: ames!DSD.3Mail.3Com.COM!Eric_Siegel
Subject: 3COM 3c503: what software under msdos 3.31 runs it?
Cc: COMP.DCOM.LANS_FOLKS@spd.3Mail.3Com.COM, Joe_Reddish@mkt.3Mail.3Com.COM

I am a software product manager at 3Com Corporation and was concerned 
that you were not able to find out which software applications support 
the 3Com EtherLink II (3C503) adapter. 3Com has the broadest third-party 
software support of any vendor which includes support for such 
applications as 3+Open, NetWare, DECnet-DOS, VINES, PC-NFS, SCO XENIX, 
FTP's PC/TCP, etc..... In the "public" domain, there are PDS drivers 
available, support within NCSA Telnet, etc... All of the drivers for the 
commericial applications mentioned above are written, tested, supported, 
and shipped by the repsective third-party software vendor. Please let me 
know if you need any further specific information.

Eric Siegel
Product Manager
3Com Corporation

------------------------------------------------------------------------------
From mahan@ncsa.uiuc.edu Fri Jul 21 10:14:55 1989
Return-Path: <mahan@ncsa.uiuc.edu>
From: mahan@ncsa.uiuc.edu (Kurt Mahan)
Subject: 3COM 3c503: what software under msd

Hi -- the current version of NCSA Telnet 2.2 on ftp.ncsa.uiuc.edu 
(128.174.20.50) supports the 3Com 3c503.  This should do most of what you
want.

------------------------------------------------------------------------------
From fks@ky.ftp.com Fri Jul 21 10:47:18 1989
Return-Path: <fks@ky.ftp.com>
From: fks@ky.ftp.com (Frances Selkirk)
Subject: TCP/IP for 3C503

We have a TCP/IP package, available for a 3C503, which has telnet, the 
berkeley r-functions, client and server ftp, tftp, and smtp, and several
terminal emulators. If you are interested in more information on this
package, send your postal address or call 617-246-0900. 
	
frances selkirk
ftp software, inc.

------------------------------------------------------------------------------
From gaurang@sunengg1.eng.wayne.edu Fri Jul 21 11:41:26 1989
Return-Path: <gaurang@sunengg1.eng.wayne.edu>
From: gaurang@sunengg1.eng.wayne.edu (Gaurang Shah)
Subject: Re:3com 3c503 :software under msdos 3.31

Sun PC-NFS, available from Sun microsystems can run on IBM-PC or it`s compitable machine which uses 3c501,3c503,3c505,3c523 card. You can use PC-NFS software
for ftp,telnet,ping,.....

gaurang
Wayne State University

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 89 23:56:25 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Terminology deplored

Bob,

Most fond that I am of nuance and mischief using our native tongue, may I
suggest that neither "gateway" is yours to keep nor "gate" any less
precious or more slovenly than "bridge," "router" or "intermediate system."
If it swings, opens, turns, switches or forwards, it's a gate; if it quacks
call it a duck.

Dave

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 89 00:13:00 GMT
From:      ljm@TWG.COM (Leo J McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   Re: Carl Beame's  Re: PC/IP scorecard


>
>Suggestion for more table entries:
>
>  1)    Memory resident size
>
>  2)    What is memory resident ? (example PCNFS from SUN has only UDP and IP,
>                                   not resident TCP)
>

Indeed.  It should also list the memory resident size in terms of 
<Amount of memory which may not be unloaded> / <Amount which may>
if applicable.

leo j mclaughlin iii
Project Manager
The Wollongong Group
ljm@twg.com

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1989 1502-PDT (Saturday)
From:      Philip Almquist <almquist@jessica.Stanford.EDU>
To:        iris!heberlei@ucdavis.ucdavis.edu  (Todd)
Cc:        almquist@jessica.Stanford.EDU, tcp-ip@sri-nic.arpa
Subject:   Re: Ignorant question - multiple connections within TCP ports?
Todd,
> ...if two people from host A
> login into host B, the port on B for both connections will be port
> 513 (the default port for login I believe).  Host B can then separate
> the connections by:
>
> (1) source ports of the originating connection (from host A)
>         or
> (2) sequence / acknowledgement numbers of the separate connections
>
> I was once told that (2) was the correct answer.
> The question I have is: If the connections are separated by seq/ack
> numbers as I have been told, what would happen if the seq. number from
> one connection passed the seq. number for another connection?

	You were told wrong; (1) is the correct answer (see RFC 793,
page 5, first paragraph).  Your question points out well why (2)
wouldn't work.
							Philip
-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 89 08:06:23 GMT
From:      epsilon@wet.UUCP (Eric P. Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: 3COM 3c503: what software under msdos 3.31 runs it?

NCSA Telnet 2.3 for the IBM PC (to be released later this summer)
will support the 3C503.  A beta test version is available now.

Sun's PC-NFS definitely supports it.  I believe Stanford's PC/IP
does as well.  I'm sure there are others.

					-=EPS=-

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 89 23:03:10 GMT
From:      zweig@p.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Ignorant question - multiple connec


   On the subject of <Addr1, Port1, Addr2, Port2> 4-tuples being the
way of specifying a connection, does anyone know of a good (in the sense
of actually saving time) way of hashing these 12 bytes to 4?
   I was thinking of describing each connection in the TCP I'm writing by
a single (possibly non-unique) 32-bit word that would speed things up
when running down the list of active connections when trying to decide
what to do with an incoming packet. Simply XOR-ing the source-IP Address,
both Ports (concatenated nicely in the datagram already) and ignoring the
destination IP-address (since it has to be unique for the TCP module doing
the check -- that's guaranteed by my lower-layer) seems like the most
straightforward thing to do to minimize comparisons. Plus I was thinking
of throwing in a lookaside buffer of the 1 or 2 last touched connection-
descriptors....
   My question is: do people have experience with this sort of thing, and
can I actually get a performance increase on list-checking this way? I
am tempted to say "there's typically only a few connections open at any
time" and "the lookaside will probably have a very high hit rate since
traffic tends to be bursty" but maybe that means that no tricks are
required. Certainly just checking 4 or 5 connection-descriptors the
"long way" wouldn't be much work. Now, if some idiot were to open 400 or
500 connections, maybe some hasing and caching would pay off...
   Another alternative would be to store a linked-list through the
connection-descriptors that would be reordered with the connection just
touched moving to the front, so that the most active connections would
be checked first. Costs an extra pointer per descriptor, but seems pretty
cheap....


-Johnny Zweig
 University of Illinois at Urbana-Champaign
 Department of Computer Science
--------------------------------Disclaimer:------------------------------------
   Rule 1: Don't believe everything you read.
   Rule 2: Don't believe anything you read.
   Rule 3: There is no Rule 3.
-------------------------------------------------------------------------------

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 89 23:03:12 GMT
From:      zweig@p.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Kenmore MicroWave Oven For Sale


> Written  Jul 19, 1989 by medin@NSIPO.NASA.GOV in comp.protocols.tcp-ip
> 
> Of course, this is an illegal activity, as net 224 is reserved for 
> Multicast addresses.  In particular 224.0.0.5 and 224.0.0.6 are 
> assigned to the OSPF IGP routing protocol.  I believe also that it
> is illegal to forward a packet from or to net 224 as this is part
> of the range of addresses are that are explicitly single-hop!
         ^^^^^
	 Speaking of kitchen-appliances....
> 
> 					Thanks,
> 					   Milo

-Johnny Z ;-)

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 89 04:23:22 GMT
From:      rpbert@phoenix.Princeton.EDU (Raymond Pierrehumbert)
To:        comp.protocols.tcp-ip
Subject:   MacII FTP speeds on Ethernet

Can somebody tell me what the bottleneck is on FTP transfer rates for
a MacII on ethernet?  I am running two MacII's on a subnet in the 
Atmospheric Sciences program here at Princeton, with a Sun 3/280
file server also on the net.  I have the Apple ethernet cards in
the machines, and am running NCSA Telnet 2.3 (which has server
FTP support).  Basically, between the mac and the server I am
getting no better than about 35K bytes/sec for binary transfers,
no matter how I tweak the protocol parameters.  On the same net,
Sun 3/50's routinely do about 70K bytes/sec at the same time. On
the TCP/IP scorecard posted here earlier, I have seen speeds of
up to 100K bytes/sec posted for IBM PC ftp speeds.  Are my
experiences typical?  Is there anything I can do to speed things
up?  Is the problem in software or in hardware?

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Sun, 23 Jul 89 13:13:51 EDT
From:      Charles Lynn <clynn@BBN.COM>
To:        m.cs.uiuc.edu!p.cs.uiuc.edu!zweig@uxc.cso.uiuc.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  Ignorant question - multiple connec
One trick is to use the <n> high-order bits of the received acknowledgement
field as the hashing function, where <n> is selected based on the number
of simultaneous connections the implementation is intended to support.
Recall that the TCP gets to pick an initial sequence number "based on a
clock"; one "clock" might be an <n> bit counter that gets incremented
each time a new connection is created (skipping over values which are
still "in use").  One has to be a little careful, however, since all
received connection attempts will fall into bucket "0" (some might call
that a "feature"!) and would have to be moved to the appropriate bucket
when the SYN/ACK is sent, and if a connection sends enough data the
ACK will move to the "next bucket".  E.g., for <n> equal to 8 (a load
byte instruction), there would be 256 buckets, and a connection would
have to be moved to the next bucket (actually, it is in "two buckets"
for a little while) after 16 MBytes of data had been sent.
-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 89 12:24:54 GMT
From:      HANK@BARILVM.BITNET (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Pc/Ip Scorecard - Revision 7

I guess I'm ready.  Many thanks to the *dozens* of people who sent me their
suggestions for what needs to be added to the scorecard.  As can be imagined,
there is no way I can incorporate all the suggestions but I think I was
able to use about 70% of them.  Now I need for each user who is either
very familiar with a specific package or happens to a vendor of that package,
to extract the specific line(s) of their product, make the changes to
line (a total of 6 line), indicate which table it is from and then send me
those changes lines.

Under no condition send me the entire scorecard with your changes entered
into the scorecard and even worse, do not send me your changes in textual
format.  I will only accept changes in tabular format.

Please reply only to me.  The revised table will be posted on August 6th,
so please reply as soon as possible.  Afterwards, your comments won't be
included.


                         The Pc/Ip Scorecard
                        revision 7: 08/??/89
                        ---------------------

    This scorecard will  be like a  PC Magazine analysis  of of hard
disks or printers.  But  I need help in  filling in the boxes.   So,
here is what the scorecard looks like.  Please send me your  replies
and  I  will  integrate  all  answers  and  comments and publish the
finalized scorecard in the weeks to come.

------------------------------------------------------------------------
TABLE #1:
---------

Vendor        TFTP SMTP VT-  3270 FTP  max    cost    packet
                         100      Clnt FTP     ($)    driver
-------------+----+----+----+----+----+----+---------+------+
Beame        | Yes| No | Yes| No | Yes| 75k|    @    |      |
Clarkson NCSA|    |    |    |    |    |    |         |      |
Cornell      |  No| No | No | Yes| No |    |  25@site|      |
CMU          | Yes| No | No | No | No |    |   0@    |      |
Excelan 3.3  | No | No | Yes| No | Yes| 88k| 250@cpu |      |
FTP  2.02    | Yes| Yes| Yes| Yes| Yes|114k| 400@cpu |      |
FUSION 3.2   | Yes| Yes| Yes| No | Yes| 85k| 300@    |      |
IBM  V1.1    | Yes| Yes| No | Yes| Yes| 90k| 200@cpu |      |
KA9Q         | No | Yes| No | No | Yes| 74k|   0@    |      |
MIT          | Yes| No | No | No | No |    |  50@site|      |
NCSA  V2.2   | No | No | Yes| No | Yes|    |   0@    |      |
Stanford 3.0 | No | Yes| Yes| No | Yes|    | 100@site|      |
SUN PC-NFS   | No |Xtra| Yes| No | Yes|167k| 395@cpu |      |
UB TCP-PC v16|    | No | Yes| Yes| Yes| 74k| 495@cpu |      |
WIN/TCP 3.2  | Yes| Yes| Yes| No | Yes|200k| 395@cpu |      |

Notes: 1) All versions must support ARP, ICMP and UDP
       2) Max FTP is for the fastest FTP to a PC (*not* from) in
          Kbytes/sec.  The sending machine can be any machine.
          The origin and destination of the FTP must be disk or
          ramdisk.  NUL is not a valid destination.
       3) Packet driver column can have either a value of 'Yes' for
          supporting the FTP Software spec for packet driver or
          'Ndis' for supporting Microsoft/3Com's spec for the same
          function or 'Odi' for supporting the Novell/Apple spec,
          or 'ASI' for supporting the IBM TOKREUI spec.
       4) The VT100 column can have a value of Yes for supporting
          VT100 or the highest Digital terminal - i.e. VT220, VT240,
          VT330, etc. supported.

------------------------------------------------------------------------
TABLE #2A:


    The  following  tables list   the  most  popular  Ethernet cards
available and whether the Pc/Ip implementation works with the stated
card.

Vendor      3com  Excelan  Inter   UB    WD   3Com  UB NIC  3com  MICOM
            3C501 EXOS205  NI5010 2273A 8003  3C523  PS/2   3C503 NI5210
-----------+-----+--------+------+-----+-----+-----+------+------+------+
Beame      | Yes |  No    |  No  | No  | No  | No  | No   | No   | No
Clarkson   |     |        |      |     |     |     |      |      |
Cornell    | Yes |  No    |  No  | No  | No  | No  | No   | No   | No
CMU        | Yes |  No    |  Yes | No  | Yes | No  | No   | No   | No
Excelan    | No  |  Yes   |  No  | No  | No  | No  | No   | No   | No
FTP        | Yes |  Yes   |  Yes | Yes | Yes | Yes | No   | Yes  | Yes
FUSION     | Yes |  No    |  Yes | No  | Yes | No  | No   |      | Yes
IBM        | Yes |  No    |  No  | Yes | No  | No  | Yes  | No   | No
KA9Q       | Yes |  No    |  No  | No  | No  | No  | No   |      | Yes
MIT        | Yes |  No    |  Yes | No  | No  | No  | No   |      |
NCSA       | Yes |  No    |  No  | Yes | Yes | No  | No   | No   | Yes
Stanford   | Yes |  No    |  No  | No  | Yes | Yes |      | Yes  |
Sun        | Yes |  No    |  Yes | Yes | Yes | Yes | No   | Yes  | Yes
UB         | No  |  Yes   |  No  | Yes | No  | No  | Yes  |      |
Wollongong | Yes |  No    |  Yes | No  | No  | Yes | No   | Yes  | No


TABLE #2B:

Vendor      3com     WD     Tiara  IBM  D-
            3C505 8003ET/A LANcard TR    Link
-----------+-----+--------+-------+----+-----+
Beame      |     |        |       |    |     |
Clarkson   |     |        |       |    |     |
Cornell    |     |        |       |    |     |
CMU        |     |        |       |    |     |
Excelan    |     |        |       |    |     |
FTP        |     |        |       |    |     |
FUSION     |     |        |       |    |     |
IBM        |     |        |       |    |     |
KA9Q       |     |        |       |    |     |
MIT        |     |        |       |    |     |
NCSA       |     |        |       |    |     |
Stanford   |     |        |       |    |     |
Sun        |     |        |       |    |     |
UB         |     |        |       |    |     |
Wollongong |     |        |       |    |     |

------------------------------------------------------------------------
TABLE #3A:

    This table is  called the "Nice  to Have" table.   The functions
listed  here  are  not  mandatory   but  are  useful  in  a   Tcp/Ip
environment:

            domn time fing whoi NFS  gate srce Net- ping SLIP POP  Tek
Vendor      name srvr                way  code BIOS
            srvr                               1001
-----------+----+----+----+----+----+----+----+----+----+----+----+----+
Beame      | Yes| Yes| Yes| No | No | No | No | No | No | No | No |    |
Clarkson   |    |    |    |    |    |    |    |    |    |    |    |    |
Cornell    |  No|  No|  No| No | No | No | No | No | Yes| No | No |    |
CMU        | Yes| Yes| Yes| No | No | No | Yes| No | Yes| Yes| No |    |
Excelan    | No | No | No | No | No | No | No | Yes| No | No | No |    |
FTP        | Yes| Yes| Yes| Yes| No | No |Xtra|Xtra| Yes| Yes| No |    |
FUSION     | No | Yes| Yes| Yes| No | No | Yes| No | Yes| No | No |    |
IBM        | Yes| Yes| Yes| Yes| No | Yes| Yes| No | Yes| No | Yes|    |
KA9Q       | No | No | No | No | No | Yes| Yes| No | Yes| Yes| No |    |
MIT        | Yes| Yes| Yes| Yes| No | No | Yes| No | Yes| No | No |    |
NCSA       | Yes| No | No | No | No | Yes| Yes|    | Yes| No | No |    |
Stanford   | No | Yes| Yes| Yes| No | No | No |    | Yes| No | Yes|    |
Sun        | Yes| No | No | No | Yes| No |Xtra| No | Yes| Yes|Xtra|    |
UB         | Yes| No |    |    | No | Yes| No | Yes| Yes| No |    |    |
Wollongong | No | No | No | No | No | Yes| No | No | Yes| No | No |    |

Notes: 1) POP refers to RFC937
       2) gateway refers to IP forwarding capability
       3) Xtra refers to an item that is available but at an added cost
       4) Tek column refers to supporting Tektronix terminals.  Specify
          highest level of terminal supported, i.e. 4014.

TABLE #3B:

Vendor      INT  gra- mem-
            14   phic ory
-----------+----+----+----+
Beame      |    |    |    |
Clarkson   |    |    |    |
Cornell    |    |    |    |
CMU        |    |    |    |
Excelan    |    |    |    |
FTP        |    |    |    |
FUSION     |    |    |    |
IBM        |    |    |    |
KA9Q       |    |    |    |
MIT        |    |    |    |
NCSA       |    |    |    |
Stanford   |    |    |    |
Sun        |    |    |    |
UB         |    |    |    |
Wollongong |    |    |    |

Notes: 1) INT14 refers to the ability to support INT14 over Telnet.
       2) Graphics column can either have the value of Yes, meaning
          that the software supports some kind of graphics terminal
          emulation; No; or Xtra.  The specific 'graphics emulation'
          is left vague on purpose.
       3) Memory column refers to the amount of memory required to
          load the specific Pc/Ip implementation.

------------------------------------------------------------------------
TABLE #4:

This table is meant to service users of the network in gaining more
information about a product.  In order to limit the "commercialism"
that is inherent in this Scorcard, each vendor is allowed to supply
either a single Internet address or in the event of a lack of a valid
e-mail address, a FAX number.  Only one will be accepted per vendor and
it is the vendor's choice to decide which will provide an easier method
for users to gain further information about their product.

In addition, by limiting it to one or the other, I will be neutralizing
the advantage shared by those that have Internet access as opposed to
those companies that do not have Internet access.

Beame      |
Clarkson   |
Cornell    |
CMU        |
Excelan    |
FTP        |
FUSION     |
IBM        |
KA9Q       |
MIT        |
NCSA       |
Stanford   |
Sun        |
UB         |
Wollongong |


------------------------------------------------------------------------
Final Notes:

1) FTP Software is OEMed to BICC Data Networks, Fibronics, Proteon,
   cisco, Spider Systems, MICOM-Interlan, Scope, Univation and Western
   Digital.
2) Clarkson software is an offshoot of the NCSA product.

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 89 15:14:32 GMT
From:      mark@spider.co.uk (Mark Valentine)
To:        comp.protocols.tcp-ip
Subject:   Graphical SNMP Tools

A number of our development groups are looking for graphical tools to help
them understand the numbers they get from the SNMP code they've developed.
Has anyone developed socket-based applications which do this kind of thing?
(Preferably X11 based, but we could live with suntools.)

The kind of applications I envisage would be capable of interrogating a
number of SNMP agents on the network and would use graph and histogram
widgets to present the data in a meaningful way.

I'd be grateful for any information relating to the existence and availability
of such applications.  If there's anything out there I'll pass the info on...

	Thanks in Advance,

		Mark.
__
Mark Valentine, Senior Software Engineer, Spider Systems Limited    /\oo/\
Mail: mark@spider.co.uk    UUCP: ukc!spider!mark    Phone: +44 31 554 9424

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 89 17:13:51 GMT
From:      clynn@BBN.COM (Charles Lynn)
To:        comp.protocols.tcp-ip
Subject:   Re:  Ignorant question - multiple connec

One trick is to use the <n> high-order bits of the received acknowledgement
field as the hashing function, where <n> is selected based on the number
of simultaneous connections the implementation is intended to support.
Recall that the TCP gets to pick an initial sequence number "based on a
clock"; one "clock" might be an <n> bit counter that gets incremented
each time a new connection is created (skipping over values which are
still "in use").  One has to be a little careful, however, since all
received connection attempts will fall into bucket "0" (some might call
that a "feature"!) and would have to be moved to the appropriate bucket
when the SYN/ACK is sent, and if a connection sends enough data the
ACK will move to the "next bucket".  E.g., for <n> equal to 8 (a load
byte instruction), there would be 256 buckets, and a connection would
have to be moved to the next bucket (actually, it is in "two buckets"
for a little while) after 16 MBytes of data had been sent.

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 89 17:54:25 GMT
From:      amanda@intercon.uu.net (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: MacII FTP speeds on Ethernet

In article <9559@phoenix.Princeton.EDU>, rpbert@phoenix.Princeton.EDU (Raymond
Pierrehumbert) writes:
> Can somebody tell me what the bottleneck is on FTP transfer rates for
> a MacII on ethernet?

There are a number of factors.  The biggest ones are (in no particular order):

 - SCSI Disk speed:  You will get a speed improvement by using a good
   disk cache or transferring to or from a RAMdisk.

 - Ethernet board & driver:  The faster the board (and .ENET driver) can
   move bits around, the better.  The fastest I have seen in action
   personally are the Dove FastNet III and the Asante MacCon II/E.

 - TCP/IP implementation:  The native NCSA TCP/IP kernel runs in what
   would be "user time" under UNIX.  In other words, most of the protocol
   processing happens during the main event loop.  MacTCP, on the other hand,
   does most of its processing at interrupt time, which means among other
   things that ACKs go out immediately, which keeps the other end's idea of
   the RTT low.  Using MacTCP will give you a significant performance
   improvement "right out of the box."

Hope this helps,

--
Amanda Walker
InterCon Systems Corporation
--
amanda@intercon.uu.net  |  ...!uunet!intercon!amanda

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Sun, 23 Jul 89 15:24:54 P
From:      Hank Nussbacher <HANK%BARILVM.BITNET@CUNYVM.CUNY.EDU>
To:        PC/IP Forum <pcip@louie.udel.EDU>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Pc/Ip Scorecard - Revision 7
I guess I'm ready.  Many thanks to the *dozens* of people who sent me their
suggestions for what needs to be added to the scorecard.  As can be imagined,
there is no way I can incorporate all the suggestions but I think I was
able to use about 70% of them.  Now I need for each user who is either
very familiar with a specific package or happens to a vendor of that package,
to extract the specific line(s) of their product, make the changes to
line (a total of 6 line), indicate which table it is from and then send me
those changes lines.

Under no condition send me the entire scorecard with your changes entered
into the scorecard and even worse, do not send me your changes in textual
format.  I will only accept changes in tabular format.

Please reply only to me.  The revised table will be posted on August 6th,
so please reply as soon as possible.  Afterwards, your comments won't be
included.


                         The Pc/Ip Scorecard
                        revision 7: 08/??/89
                        ---------------------

    This scorecard will  be like a  PC Magazine analysis  of of hard
disks or printers.  But  I need help in  filling in the boxes.   So,
here is what the scorecard looks like.  Please send me your  replies
and  I  will  integrate  all  answers  and  comments and publish the
finalized scorecard in the weeks to come.

------------------------------------------------------------------------
TABLE #1:
---------

Vendor        TFTP SMTP VT-  3270 FTP  max    cost    packet
                         100      Clnt FTP     ($)    driver
-------------+----+----+----+----+----+----+---------+------+
Beame        | Yes| No | Yes| No | Yes| 75k|    @    |      |
Clarkson NCSA|    |    |    |    |    |    |         |      |
Cornell      |  No| No | No | Yes| No |    |  25@site|      |
CMU          | Yes| No | No | No | No |    |   0@    |      |
Excelan 3.3  | No | No | Yes| No | Yes| 88k| 250@cpu |      |
FTP  2.02    | Yes| Yes| Yes| Yes| Yes|114k| 400@cpu |      |
FUSION 3.2   | Yes| Yes| Yes| No | Yes| 85k| 300@    |      |
IBM  V1.1    | Yes| Yes| No | Yes| Yes| 90k| 200@cpu |      |
KA9Q         | No | Yes| No | No | Yes| 74k|   0@    |      |
MIT          | Yes| No | No | No | No |    |  50@site|      |
NCSA  V2.2   | No | No | Yes| No | Yes|    |   0@    |      |
Stanford 3.0 | No | Yes| Yes| No | Yes|    | 100@site|      |
SUN PC-NFS   | No |Xtra| Yes| No | Yes|167k| 395@cpu |      |
UB TCP-PC v16|    | No | Yes| Yes| Yes| 74k| 495@cpu |      |
WIN/TCP 3.2  | Yes| Yes| Yes| No | Yes|200k| 395@cpu |      |

Notes: 1) All versions must support ARP, ICMP and UDP
       2) Max FTP is for the fastest FTP to a PC (*not* from) in
          Kbytes/sec.  The sending machine can be any machine.
          The origin and destination of the FTP must be disk or
          ramdisk.  NUL is not a valid destination.
       3) Packet driver column can have either a value of 'Yes' for
          supporting the FTP Software spec for packet driver or
          'Ndis' for supporting Microsoft/3Com's spec for the same
          function or 'Odi' for supporting the Novell/Apple spec,
          or 'ASI' for supporting the IBM TOKREUI spec.
       4) The VT100 column can have a value of Yes for supporting
          VT100 or the highest Digital terminal - i.e. VT220, VT240,
          VT330, etc. supported.

------------------------------------------------------------------------
TABLE #2A:


    The  following  tables list   the  most  popular  Ethernet cards
available and whether the Pc/Ip implementation works with the stated
card.

Vendor      3com  Excelan  Inter   UB    WD   3Com  UB NIC  3com  MICOM
            3C501 EXOS205  NI5010 2273A 8003  3C523  PS/2   3C503 NI5210
-----------+-----+--------+------+-----+-----+-----+------+------+------+
Beame      | Yes |  No    |  No  | No  | No  | No  | No   | No   | No
Clarkson   |     |        |      |     |     |     |      |      |
Cornell    | Yes |  No    |  No  | No  | No  | No  | No   | No   | No
CMU        | Yes |  No    |  Yes | No  | Yes | No  | No   | No   | No
Excelan    | No  |  Yes   |  No  | No  | No  | No  | No   | No   | No
FTP        | Yes |  Yes   |  Yes | Yes | Yes | Yes | No   | Yes  | Yes
FUSION     | Yes |  No    |  Yes | No  | Yes | No  | No   |      | Yes
IBM        | Yes |  No    |  No  | Yes | No  | No  | Yes  | No   | No
KA9Q       | Yes |  No    |  No  | No  | No  | No  | No   |      | Yes
MIT        | Yes |  No    |  Yes | No  | No  | No  | No   |      |
NCSA       | Yes |  No    |  No  | Yes | Yes | No  | No   | No   | Yes
Stanford   | Yes |  No    |  No  | No  | Yes | Yes |      | Yes  |
Sun        | Yes |  No    |  Yes | Yes | Yes | Yes | No   | Yes  | Yes
UB         | No  |  Yes   |  No  | Yes | No  | No  | Yes  |      |
Wollongong | Yes |  No    |  Yes | No  | No  | Yes | No   | Yes  | No


TABLE #2B:

Vendor      3com     WD     Tiara  IBM  D-
            3C505 8003ET/A LANcard TR    Link
-----------+-----+--------+-------+----+-----+
Beame      |     |        |       |    |     |
Clarkson   |     |        |       |    |     |
Cornell    |     |        |       |    |     |
CMU        |     |        |       |    |     |
Excelan    |     |        |       |    |     |
FTP        |     |        |       |    |     |
FUSION     |     |        |       |    |     |
IBM        |     |        |       |    |     |
KA9Q       |     |        |       |    |     |
MIT        |     |        |       |    |     |
NCSA       |     |        |       |    |     |
Stanford   |     |        |       |    |     |
Sun        |     |        |       |    |     |
UB         |     |        |       |    |     |
Wollongong |     |        |       |    |     |

------------------------------------------------------------------------
TABLE #3A:

    This table is  called the "Nice  to Have" table.   The functions
listed  here  are  not  mandatory   but  are  useful  in  a   Tcp/Ip
environment:

            domn time fing whoi NFS  gate srce Net- ping SLIP POP  Tek
Vendor      name srvr                way  code BIOS
            srvr                               1001
-----------+----+----+----+----+----+----+----+----+----+----+----+----+
Beame      | Yes| Yes| Yes| No | No | No | No | No | No | No | No |    |
Clarkson   |    |    |    |    |    |    |    |    |    |    |    |    |
Cornell    |  No|  No|  No| No | No | No | No | No | Yes| No | No |    |
CMU        | Yes| Yes| Yes| No | No | No | Yes| No | Yes| Yes| No |    |
Excelan    | No | No | No | No | No | No | No | Yes| No | No | No |    |
FTP        | Yes| Yes| Yes| Yes| No | No |Xtra|Xtra| Yes| Yes| No |    |
FUSION     | No | Yes| Yes| Yes| No | No | Yes| No | Yes| No | No |    |
IBM        | Yes| Yes| Yes| Yes| No | Yes| Yes| No | Yes| No | Yes|    |
KA9Q       | No | No | No | No | No | Yes| Yes| No | Yes| Yes| No |    |
MIT        | Yes| Yes| Yes| Yes| No | No | Yes| No | Yes| No | No |    |
NCSA       | Yes| No | No | No | No | Yes| Yes|    | Yes| No | No |    |
Stanford   | No | Yes| Yes| Yes| No | No | No |    | Yes| No | Yes|    |
Sun        | Yes| No | No | No | Yes| No |Xtra| No | Yes| Yes|Xtra|    |
UB         | Yes| No |    |    | No | Yes| No | Yes| Yes| No |    |    |
Wollongong | No | No | No | No | No | Yes| No | No | Yes| No | No |    |

Notes: 1) POP refers to RFC937
       2) gateway refers to IP forwarding capability
       3) Xtra refers to an item that is available but at an added cost
       4) Tek column refers to supporting Tektronix terminals.  Specify
          highest level of terminal supported, i.e. 4014.

TABLE #3B:

Vendor      INT  gra- mem-
            14   phic ory
-----------+----+----+----+
Beame      |    |    |    |
Clarkson   |    |    |    |
Cornell    |    |    |    |
CMU        |    |    |    |
Excelan    |    |    |    |
FTP        |    |    |    |
FUSION     |    |    |    |
IBM        |    |    |    |
KA9Q       |    |    |    |
MIT        |    |    |    |
NCSA       |    |    |    |
Stanford   |    |    |    |
Sun        |    |    |    |
UB         |    |    |    |
Wollongong |    |    |    |

Notes: 1) INT14 refers to the ability to support INT14 over Telnet.
       2) Graphics column can either have the value of Yes, meaning
          that the software supports some kind of graphics terminal
          emulation; No; or Xtra.  The specific 'graphics emulation'
          is left vague on purpose.
       3) Memory column refers to the amount of memory required to
          load the specific Pc/Ip implementation.

------------------------------------------------------------------------
TABLE #4:

This table is meant to service users of the network in gaining more
information about a product.  In order to limit the "commercialism"
that is inherent in this Scorcard, each vendor is allowed to supply
either a single Internet address or in the event of a lack of a valid
e-mail address, a FAX number.  Only one will be accepted per vendor and
it is the vendor's choice to decide which will provide an easier method
for users to gain further information about their product.

In addition, by limiting it to one or the other, I will be neutralizing
the advantage shared by those that have Internet access as opposed to
those companies that do not have Internet access.

Beame      |
Clarkson   |
Cornell    |
CMU        |
Excelan    |
FTP        |
FUSION     |
IBM        |
KA9Q       |
MIT        |
NCSA       |
Stanford   |
Sun        |
UB         |
Wollongong |


------------------------------------------------------------------------
Final Notes:

1) FTP Software is OEMed to BICC Data Networks, Fibronics, Proteon,
   cisco, Spider Systems, MICOM-Interlan, Scope, Univation and Western
   Digital.
2) Clarkson software is an offshoot of the NCSA product.
-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 89 04:50:03 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  trace route to OZ

Milo,

I don't regard the discussion of interesting routing phenomena between the
furtherst outflings of the Internet as operational issues at all; in fact,
some of the oddities being discovered may have very real impact on the
understanding and solving of basic problems for users and operators of
campus, regional and backbone networks. Your comments are out of place and
leave the misleading impression that if our users simply call their
network gurus everything will get well.

Dave

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Jul 89 13:38:33 CDT
From:      texbell!utafll!robin@cs.utexas.edu (Robin Cover)
To:        texbell!cs.utexas.edu!sri-nic.arpa!tcp-ip
Cc:        texbell!sri-nic.arpa!tcp-ip
Subject:   please unsubscribe
unsubscribe tcp-ip
(unsubscribe Robin Cover from tcp-ip)
-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 89 11:36:11 GMT
From:      jacobson@delta.eecs.nwu.edu (Dan Jacobson)
To:        comp.protocols.tcp-ip
Subject:   Implementation of RFC 1078 (TCPMUX) Available


I have made an implementation of RFC 1078 (TCP Port Service
Multiplexor (TCPMUX)) which I call "An Internet 'Directory Assistance'
Server", as a Master's project.  The C source (4.2 BSD UNIX) and LaTeX
documentation are available for the asking.  I do not plan to offer
"support" for the software however.

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 89 12:31:00 GMT
From:      WHITESID@McMaster.CA (Fred Whiteside)
To:        comp.protocols.tcp-ip
Subject:   Re:  trace route to OZ


        Dave Mills write:
>  Milo,
>
>  I don't regard the discussion of interesting routing phenomena between
>  the furtherst outflings of the Internet as operational issues at all;
>  in fact, some of the oddities being discovered may have very real
>  impact on the understanding and solving of basic problems for users
>  and operators of campus, regional and backbone networks. Your comments
>  are out of place and leave the misleading impression that if our users
>  simply call their network gurus everything will get well.
>
>  Dave

        It is worthy of note that this is the *very* first note from
Dave that I have understood in its entirety and (as I long suspected)
I find that I agree completely with what he has to say.

        Those who feel that this list should not have discussion of
any of the real-world application difficulties of the topic of the
list, please feel free to vent your spleen elsewhere.

        Thank you for your attention

Fred Whiteside               POSTMAST@MCMASTER.BitNet
McMaster NetNorth Postmaster POSTMASTER@McMaster.CA
Development Analyst          WHITESID@SSCvax.McMaster.CA
McMaster University          ...!uunet!utai!utgpu!maccs!fred
Hamilton, Canada

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 89 12:34:33 GMT
From:      heker@JVNCA.CSC.ORG (Sergio Heker)
To:        comp.protocols.tcp-ip
Subject:   Re: trace route to OZ

Jon,

The link between JvNC and JANET is provided by *one* cisco router in our
end, connected through a 56kbps link to an x.25 switch in London.  The
"nsfnet-relay" gateway is a SUN connected to the x.25 switching system.
The *very* high delay seems to be mostly due to the x.25 switch (the
satellite delay only accounts to approximately 500 msec).  In the case
of our link to NORDUnet, which is also satellite, we use a cisco router
at each end and we get a delay of approximately 600msec (average).  There
are discussions to add a cisco router at the JANET end in order to reduce
the delay.  

I ran ping to 128.86.8.6 and to 128.86.8.1.  The first address is the address
of the "nsfnet-relay" in England, while the second one is the address of 
the cisco router at JvNC.  Note below the round trip delays and packets
lost for each.

Mon Jul 24 08:23:03 EDT 1989
PING 128.86.8.6: 10 data bytes
----128.86.8.6 PING Statistics----
100 packets transmitted, 96 packets received, 4% packet loss
round-trip (ms)  min/avg/max = 7560/11579/16280


Mon Jul 24 08:23:14 EDT 1989
PING 128.86.8.1: 10 data bytes
----128.86.8.1 PING Statistics----
100 packets transmitted, 100 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 10/46/1750

The routing and delay to the 128.86 network (our side of the point to 
point link) is reasonably good.  While the other side of the point to
point link, is extremly slow and there are some packets lost.

We have two Technical Reports (TRs) describing the connection between JvNC
and JANET and between JvNC and NORDUnet.  These two TRs are, at this point
drafts and are being "certified".  For more information on either of these
international links, please send mail to "nisc@nisc.jvnc.net".

					-- Sergio
-----------------------------------------------------------------------------
|		John von Neumann National Supercomputer Center		    |
|  Sergio Heker				tel:	(609) 520-2000		    |
|  Director for Networking		fax:	(609) 520-1089		    |
|  Internet: "heker@jvnca.csc.org"	Bitnet:	"heker@jvnc"		    |
-----------------------------------------------------------------------------

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 89 12:51:34 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: trace route to OZ



Sergio, et al

 >The link between JvNC and JANET is provided by *one* cisco router in our
 >end, connected through a 56kbps link to an x.25 switch in London.  The
 >"nsfnet-relay" gateway is a SUN connected to the x.25 switching system.

not quite according to ja,
its a microvax connected to the x.25 switch...it will be a sun someday
soon, possiblyu onm a 'null' ethernet with a cisco - still all under
negotiation/decision...

sorry about the misinformation on two cisco's - I was anticipating
what *will* be the setup at ULCC

 >The *very* high delay seems to be mostly due to the x.25 switch (the
 >satellite delay only accounts to approximately 500 msec).  In the case
 >of our link to NORDUnet, which is also satellite, we use a cisco router
 >at each end and we get a delay of approximately 600msec (average).  There
 >are discussions to add a cisco router at the JANET end in order to reduce
 >the delay.  

yep, the x.25 switch + the uVax ahave pretty appalling performance

this is due to the window of 2, limit of 1 on number of X.25 VCs the
switch/uVax can support, and 128 byte X.25 packet size amongst other
things...(this from john Andrews who manages the nsfnet-relay
machine).

 >I ran ping to 128.86.8.6 and to 128.86.8.1.  The first address is the address
 >of the "nsfnet-relay" in England, while the second one is the address of 
 >the cisco router at JvNC.  Note below the round trip delays and packets
 >lost for each.

if i use my defense path (ucl - rsre - (different satellite path)- bbn - 
nsfnet backbone - jvnc - ulcc), i get similar effects, although exaggerated:

Mon Jul 24 13:42:56 BST 1989

---128.86.8.6 PING Statistics----
17 packets transmitted, 11 packets received, 35% packet loss
round-trip (ms)  min/avg/max = 1760/3483/6300


----128.86.8.1 PING Statistics----
11 packets transmitted, 10 packets received, 9% packet loss
round-trip (ms)  min/avg/max = 1140/1291/1479


 >We have two Technical Reports (TRs) describing the connection between JvNC
 >and JANET and between JvNC and NORDUnet.  These two TRs are, at this point
 >drafts and are being "certified".  For more information on either of these
 >international links, please send mail to "nisc@nisc.jvnc.net".

will do,

thanks for info...

(now of course none of this has anything to do with OZ anymore, or my
traceroute which was via our *defense* path - has nayone got a
traceroute for the original "furthest telnet" path from OZ to
scandinavia?)

 jon

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Jul 89 17:36:22 EDT
From:      Rudy.Nedved@RUDY.FAC.CS.CMU.EDU
To:        tony%rata.vuw.ac.nz@relay.cs.net
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Summary: Backup via network

CMU CS:
-------

I am working on and putting the finishing details on a 4.3BSD Unix oriented
backup system so we can change from manually running backups on 80+ machines
to automatically running backups on 500+ machines.

It takes a modified version of dump/rdump called edump and a modified version
of rshd called oprshd (uses real passwords to break system administrator
bounds) and backs the data up on tape drives.

It is a prototype system and internally very ugly. After I have gained some
experience oriented insight I will rewrite it and clean it up.

Sun file servers:
-----------------

A company called Trimachi I believed based in Stage College, PA has a system
for backing up SunOS file servers.

super saver:
------------

I saw the source code for a system from Berkeley I believe called super
saver. It had limited confiuguration options but looked workable.

Epoch:
------

There is an integrated system from a company I think is called Epoch that
uses WORM disks and other disks and automatically migrates old data to the
WORM disks for permanent archival.

-Rudy



-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 89 14:32:13 GMT
From:      buck@drax.gsfc.nasa.gov (Loren (Buck) Buchanan)
To:        comp.protocols.tcp-ip
Subject:   Re: apology and mailers

In article <8907191347.AA16994@drax.gsfc.nasa.gov> buck@DRAX.GSFC.NASA.GOV (Loren (Buck) Buchanan) writes:
>Hi
>
>Below the clip line is a message I received but is not intended for me.  
>The message is something that I posted to news in early July.  Hopefully 
>you can figure out what is wrong with your auto mailer from the 
>information contained in the header.
>
...rest deleted...

I am sorry to see this mess get posted, but when I mailed it last week I
did not expect it to get posted to news.

However, around every dark cloud is a silver lining, and the silver lining
here is that someone will fix their mailers.  

I am rather new to netland, so could someone tell me what I should have
done with the misdirected mail I received?  I will post a summary of
the responses here and in the proper newsgroup (with follow ups to the
proper newsgroup).

B C'ing U

Buck

Loren "Buck" Buchanan | internet: buck@drax.gsfc.nasa.gov | standard disclaimer
CSC, 1100 West St.    | uucp: ...!ames!dftsrv!drax!buck   | "By the horns of a
Laurel, MD 20707      | phonenet: (301) 497-2531 or 9898  | sky demon..."

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 89 14:46:05 GMT
From:      schoff@SOLBOURNE.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   (none)

Digital Equipment Corporation Inc.

Marty
    We are looking for SNMP software.  Our lawyers could not (or would
    not as the case may be) agree on the Nysernet license.  Can anyone
    suggest other sources of software?  Thanks,             Linda

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Jul 89 13:51:34 +0100
From:      Jon Crowcroft <J.Crowcroft@Cs.Ucl.AC.UK>
To:        Sergio Heker <heker@jvnca.csc.org>
Cc:        G.Michaelson@cc.uq.oz.au, J.Crowcroft@Cs.Ucl.AC.UK, Mills@louie.udel.edu, ja@Cs.Ucl.AC.UK, tcp-ip@sri-nic.arpa
Subject:   Re: trace route to OZ


Sergio, et al

 >The link between JvNC and JANET is provided by *one* cisco router in our
 >end, connected through a 56kbps link to an x.25 switch in London.  The
 >"nsfnet-relay" gateway is a SUN connected to the x.25 switching system.

not quite according to ja,
its a microvax connected to the x.25 switch...it will be a sun someday
soon, possiblyu onm a 'null' ethernet with a cisco - still all under
negotiation/decision...

sorry about the misinformation on two cisco's - I was anticipating
what *will* be the setup at ULCC

 >The *very* high delay seems to be mostly due to the x.25 switch (the
 >satellite delay only accounts to approximately 500 msec).  In the case
 >of our link to NORDUnet, which is also satellite, we use a cisco router
 >at each end and we get a delay of approximately 600msec (average).  There
 >are discussions to add a cisco router at the JANET end in order to reduce
 >the delay.  

yep, the x.25 switch + the uVax ahave pretty appalling performance

this is due to the window of 2, limit of 1 on number of X.25 VCs the
switch/uVax can support, and 128 byte X.25 packet size amongst other
things...(this from john Andrews who manages the nsfnet-relay
machine).

 >I ran ping to 128.86.8.6 and to 128.86.8.1.  The first address is the address
 >of the "nsfnet-relay" in England, while the second one is the address of 
 >the cisco router at JvNC.  Note below the round trip delays and packets
 >lost for each.

if i use my defense path (ucl - rsre - (different satellite path)- bbn - 
nsfnet backbone - jvnc - ulcc), i get similar effects, although exaggerated:

Mon Jul 24 13:42:56 BST 1989

---128.86.8.6 PING Statistics----
17 packets transmitted, 11 packets received, 35% packet loss
round-trip (ms)  min/avg/max = 1760/3483/6300


----128.86.8.1 PING Statistics----
11 packets transmitted, 10 packets received, 9% packet loss
round-trip (ms)  min/avg/max = 1140/1291/1479


 >We have two Technical Reports (TRs) describing the connection between JvNC
 >and JANET and between JvNC and NORDUnet.  These two TRs are, at this point
 >drafts and are being "certified".  For more information on either of these
 >international links, please send mail to "nisc@nisc.jvnc.net".

will do,

thanks for info...

(now of course none of this has anything to do with OZ anymore, or my
traceroute which was via our *defense* path - has nayone got a
traceroute for the original "furthest telnet" path from OZ to
scandinavia?)

 jon

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 89 17:43:53 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  trace route to OZ

Sergio,

Some clue to the interesting behavior of our burgeoning Euroswamps may
lie in the far different behavior of the JvNC-Oslo circuit compared to the
JvNC-London circuit. The data I have here is collected with a Network
Time Protocol peer path between time servers in Delaware and Oslo and
over the last few weeks. The delays are about 850 ms and clock offsets
about 10 ms, not bad at all for any circuit, domestic or otherwise. The
servers ping each other about once every 17 minutes and run continuously,
so make a useful record of connectivity and congestion. If the path
becomes flaky the delay, offset or dispersion quickly reflect the fact,
so these time-server gizmos make good tripwires for detecting waves in the
swamps.

Okay, now the shoe drops. Jon, who would you like to bring up NTP on one
of your Gower Street munchkins? While at it, you might interest Robert
Cole at HP Labs in joining chimes. This way we could all watch each other's
clocks and get a better handle on (a) what is going on and (b) assess how
well precision time capability can help in cases like this. Come to think of
it, I'm sure you and Robert know each other and may have already discussed
this.

Perhaps further discussion should be offline.

Dave

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 89 18:15:35 GMT
From:      sgb@SPARTA.COM (Scott Bramhall)
To:        comp.protocols.tcp-ip
Subject:   Evaluating Network Performance

I am posting this for a co-worker who has not subscribed
to the mailing list.  Please address replies via e-mail
to 
	caf@sparta.com

Thanks!
------------------------------------

I am interested in measuring network throughput given different
implementations of network security services.  Before jumping
blindly into the fray, I am trying to determine what has already
been done in the area.  Does anyone know helpful methods or tools
for measuring network performance?  Can anyone tell me about 
previous work performed evaluating network implementations?
Suggested reading would also be appreciated.  Please respond
directly to   caf@sparta.com   and I will have a summary posted
later.
		Thank you,

		Craig Franklin

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 89 18:18:00 GMT
From:      mishkin@apollo.COM (Nathaniel Mishkin)
To:        comp.sys.apollo,comp.protocols.tcp-ip,comp.protocols.nfs,comp.sys.hp,comp.protocols.misc
Subject:   Re: A comparison of Commercial RPC Systems

In article <6569@joshua.athertn.Atherton.COM> joshua@Atherton.COM (Flame Bait) writes:
>I've finished work on a paper entitled "A Comparison of Commercial RPC
>Protocols" which I gave at NCF: The Network Computing Forum, and also
>as a work in progress at USENIX.
>
>It compares RPC (Remote Procedure Call) systems from Apollo, Sun and 
>Netwise for speed and dependablity.  I'm posting the paper (in troff 
>format) to comp.misc, so interested people can get it.  ...

I am seeking to end any cross-posting concerning this article by
posting my response to comp.protocols.misc.  I suggest all further
discussion take place there.

-- 
                    -- Nat Mishkin
                       Apollo Computer Inc., Chelmsford, MA
                       mishkin@apollo.com

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 89 18:50:46 GMT
From:      jps@wucs1.wustl.edu (James Sterbenz)
To:        comp.protocols.tcp-ip
Subject:   Re: Terminology deplored

In article <8907181741.AA00283@zmb.isi.edu> braden@VENERA.ISI.EDU writes:
>Recently I have noticed the rise of the word "gate" as a contraction of
>"gateway", first in speech, then in messages, and recently in a draft
>RFC.  To my eye and ear, this usage seems precious and slovenly.  The
>English language is too marvelous a machine to deserve such
>maltreatment.

It also overloads with the operating system usage for access into a
higher authorisation protection domain.  This usually would be clear from
context, but no reason to possibly confuse things when "gateway" is 
already widely used and well understood.

Besides, as operating systems and communications become more integrated,
it is more likely that "gate" and "gateway" will have use in the same
document.





-- 
James Sterbenz  Computer and Communications Research Center
                Washington University in St. Louis      314-726-4203
INTERNET:       jps@wucs1.wustl.edu                   128.252.123.12
UUCP:           wucs1!jps@uunet.uu.net

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 89 20:46:06 GMT
From:      heker@JVNCA.CSC.ORG (Sergio Heker)
To:        comp.protocols.tcp-ip
Subject:   Re:  trace route to OZ

Dave,

It would have been very useful to get more data, like the data that NTP
can provide, to better understand the behavior of all these networks,
domestic and foreign.  By the way, the JvNC link to the Scandinavian
countries ends in Sweden.  The fact that you are getting good response
from Oslo, is due to the fact of the good connectivity, which not only exists
here but within the NORDUnet network.  NORDUnet provides for connectivity 
between Sweden and Norway.  Cheers!.


						-- Sergio


-----------------------------------------------------------------------------
|		John von Neumann National Supercomputer Center		    |
|  Sergio Heker				tel:	(609) 520-2000		    |
|  Director for Networking		fax:	(609) 520-1089		    |
|  Internet: "heker@jvnca.csc.org"	Bitnet:	"heker@jvnc"		    |
-----------------------------------------------------------------------------

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 89 21:36:22 GMT
From:      Rudy.Nedved@RUDY.FAC.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Summary: Backup via network


CMU CS:
-------

I am working on and putting the finishing details on a 4.3BSD Unix oriented
backup system so we can change from manually running backups on 80+ machines
to automatically running backups on 500+ machines.

It takes a modified version of dump/rdump called edump and a modified version
of rshd called oprshd (uses real passwords to break system administrator
bounds) and backs the data up on tape drives.

It is a prototype system and internally very ugly. After I have gained some
experience oriented insight I will rewrite it and clean it up.

Sun file servers:
-----------------

A company called Trimachi I believed based in Stage College, PA has a system
for backing up SunOS file servers.

super saver:
------------

I saw the source code for a system from Berkeley I believe called super
saver. It had limited confiuguration options but looked workable.

Epoch:
------

There is an integrated system from a company I think is called Epoch that
uses WORM disks and other disks and automatically migrates old data to the
WORM disks for permanent archival.

-Rudy

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 89 00:03:09 GMT
From:      baw@sharkey.cc.umich.edu (Brian Wolfe)
To:        comp.protocols.tcp-ip
Subject:   Summary of Ethernet Bridge Recommendations!


Well, here it is, a summary of the Ethernet bridge recommendations 
I've received from the net. Thanks to all for their suggestions,
now it looks like I can make a more educated decision...

Thanks so much,
 
Brian.


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



- - - - - - - - - - C - U - T - - H - E - R -E - - - - - - - - - - - - - - - - -










From: Brad Turner <mbt@bridge2.ESD.3Com.COM>
Subject: Re: Ethernet bridge recommendations?
Newsgroups: comp.dcom.lans
Organization: 3Com Corp., Mt. View, CA

In article <2926@sharkey.cc.umich.edu> you write:
>
>Are there any bridges that I should avoid like the plague?            
> 

Brian,
   Check out 3Com's IB/2000 and IB/2001 MAC layer bridges. While you are
evaluating the bridges from all vendors in addition to looking at the
packets/sec figures see what sort of filtering and management features are
available. The software that is running the bridge is where you really
want to focus your attention. You can get more info on the 3Com product
line by calling 1-800-NET-3COM 

-brad-

-- 
v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v
Brad Turner	2081 Shoreline Blvd.	(415) 969-2099	| I speak for myself
3Com Corp.	Mtn. View, CA 95043 	mbt@bridge2	| NOT for my employer.

From: ian@lassen.wpd.sgi.com (Ian Clements)
Subject: Re: Ethernet Bridge Recommendations?


 You might look at cisco Systems for bridge products.  They enjoy a good
reputation in 'netland'.  Then there's always Vitalink (expensive but, you
get wehat you pay for), 3Com (used to Bridge--avoid like plague).

	cisco Systems: 

		1360 Willow Road
		Menlo Park, CA 94025
		415/326 1941
		eileen@mathom.cisco.com (Our Sales rep)

	Vitalink:

		6607 Kaiser Drive.
		Fremont, CA  94536
		415/794 1100

	3Com (Bridge):

		181 Metro Drive, Suite 600
		San Jose, CA 95110
		408/452 2900
		James Leslie (Again, our rep)


	Cheers,

	Ian


From: sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz)
Subject: Re: Ethernet bridge recommendations?
Newsgroups: comp.dcom.lans
Organization: Contel Federal Systems

In article <2926@sharkey.cc.umich.edu> you write:
>
>I have about $6000 (at most $8000) to bridge 3 standard ethernet subnets,
>so far the best deal I can find is on 2 of Retix' low-end bridges that
>are rated for 6000 'frames/second'... is that fast enough for joining segments
>that have about 10 hosts each?? Security is something of an issue since
>there is clinical data on some hosts and research data on others, so I would
>like some control over access. 

	The Retix bridges are fantastic!  We've been using them here for
	some time now, and have had 0 problems.

	Yes, they can be used to bridge segments that have 10 hosts - one
	site i maintain has 3 segments with numbers of hosts ranging from
	5 to 10 and everything is fine.

	Steven M. Schultz
	sms@wlv.imsd.contel.com

From: steve@polyslo.CalPoly.EDU (Steve DeJarnett)
Subject: Re: Ethernet bridge recommendations?
Newsgroups: comp.dcom.lans
Organization: Lab Rat Rumpus Room -- Cal Poly SLO

In article <2926@sharkey.cc.umich.edu> you write:
>So far I've looked at bridges from Micom, Raycom, Retix and DEC, are there
>any other vendors that I should try?

	I don't remember what their prices are, but you should look into 
cisco bridges.  They are fast (I think something like 10K-12K frames/sec).
They are on the Internet (cisco.com), so you should be able to get some info
from them.  We use their routers and haven't had any problems (except one to
do with a huge X.25 network that uncovered a major bug in their software, but
they fixed it in 2 days and had a patch to us for free -- their good about
customer service).

>Henry Ford Hospital 	       Voice:    (313)-876-7461
>Detroit, MI 48202              FAX:      (313)-875-0315

	Good old Henry Ford.  My birthplace.  

	Good luck in your search.

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

From: paul%gill.uucp@uunet.UU.NET (Paul Nordstrom)
Subject: Re: Ethernet bridge recommendations?
Newsgroups: comp.dcom.lans
Organization: Gill & Co., L.P., San Francisco

In article <2926@sharkey.cc.umich.edu> you write:
>
>I have about $6000 (at most $8000) to bridge 3 standard ethernet subnets,
>so far the best deal I can find is on 2 of Retix' low-end bridges that
>are rated for 6000 'frames/second'... is that fast enough for joining segments
>that have about 10 hosts each?? Security is something of an issue since
>there is clinical data on some hosts and research data on others, so I would
>like some control over access. 
> 
>So far I've looked at bridges from Micom, Raycom, Retix and DEC, are there
>any other vendors that I should try?
>
>Are there any bridges that I should avoid like the plague?            
> 
>I would appreciate any recommendations you may have and I will gladly
>post a summary to the net!
> 

I have been doing considerable work with respect to bridging my 2 ethernets.  One is in San Francisco and one is in Chicago, so my problem is a little more complicated than yours (I presume your nets are all local).  At any rate, all I have to offer is that my actual experience so far is with Microcomm, with whom I have only had problems; however, many if not most of those are related to the long distance nature of my bridge.  I also would suggest that you add Wellfleet to your list of bridges considered. 

 I have heard that they have good products and a new low end model.

I would be interested in what you find.  If you don't post to the net, I would appreciate mail.

Paul Nordstrom
Gill & Co., L.P.
uunet!gill!paul


To: baw@terminator.cc.umich.edu
Subject: Re: Ethernet bridge recommendations?
Newsgroups: comp.dcom.lans
Organization: Northwestern Univ. Evanston, Il.

Hello,

Just thought that I would put my 2 cents worth in.  If you are
expecting to connect IP networks, you may want to use a router.

We have been using code here that turns a PC into a IP router.
With this you can put together a IP router for about $800.  (by
using an XT).  This router will have a throughput of 1000 Packets/sec.
(you can use a faster AT clone and get 5000 Packets/sec).

Thus, if it is price that decided that you should go with a
bridge, I would reconsider.  If you need to pass Decnet or XNS or
other non-IP protocols, well, thats different.

Let me know if you are interested and I can tell you where to
get the software.

Vance Morrison
Network Administrator
Northewestern Univ.


From: jeff%b11%ingr.uucp@uunet.uu.net
Subject: Re: Ethernet bridge recommendations?

> 
> I have about $6000 (at most $8000) to bridge 3 standard ethernet subnets,
> so far the best deal I can find is on 2 of Retix' low-end bridges that
> are rated for 6000 'frames/second'... is that fast enough for joining segments
> that have about 10 hosts each??
     
  Should be.
		                   Security is something of an issue since
> there is clinical data on some hosts and research data on others, so I would
> like some control over access. 

  The low end retix bridge doesn't have any managament capabilities.  In
addition, they base their routing table on the last 2 bytes in the
ethernet address (can be a problem.  Our ethernet addresses increment
the 2nd and 3rd byte, the last byte remains 00). 
  BICC and CMC also make bridges (CMC is low in performance, high in
security).  I cannot recommend any of these products.  Hope this helps.


From: George Marshall <mar@bridge2.ESD.3Com.COM>
Subject: Re: Ethernet Bridge Recommendation?
Newsgroups: comp.dcom.lans
Organization: 3Com Corp., Mt. View, CA

Brian, 3Com has a family of local (ethernet to ethernet) and remote (ethernet 
to telecom line with a lot of nice features, including lots of security 
features that prvide considerable control over whose packets can go thru the 
bridge.  The lowest price local bridge has a list price of about $5K, you can 
probably get it for less.

Call 800-net-3com for starter info.

George

From: bob@rel.mi.org (Bob Leffler)
Subject: Re: Ethernet Bridge Recommendation?

Take a look at Cabletron.......    

Their low end bridge may be within your budget.  I don't have a number handy,
but they have a local sales office on Orchard Lake in Farmington Hills.

They can advise you with your speed concerns.

Ask for Rudy Schmidt.

bob


---
Bob Leffler - Electronic Data Systems, Financial Information Services Division
3044 West Grand Blvd., Room 11-101, Detroit, MI 48202 (313) 556-4474
bob@rel.mi.org or {uunet!edsews, rutgers, sharkey}!rel!bob
Opinions expressed may not be those of my employer.


From: brf@philabs.Philips.Com  (Bill Friday)
Subject: Re: Ethernet Bridge Recommendations?
Newsgroups: comp.protocols.tcp-ip
Organization: Philips Laboratories, Briarcliff Manor, NY

In article <2952@sharkey.cc.umich.edu> you write:
>
>I have about $6000 (at most $8000) to bridge 3 standard ethernet subnets,
>so far the best deal I can find is on 2 of Retix' low-end bridges that
>are rated for 6000 'frames/second'... is that fast enough for joining segments
>that have about 10 hosts each?? Security is something of an issue since
>there is clinical data on some hosts and research data on others, so I would
>like some control over access. 
> 
>So far I've looked at bridges from Micom, Raycom, Retix and DEC, are there
>any other vendors that I should try?
>
>Are there any bridges that I should avoid like the plague?            
> 
>I would appreciate any recommendations you may have and I will gladly
>post a summary to the net!
> 
>Thanks,
> 
>Brian.
> 
>
>-- 
>Brian Wolfe                    Internet: baw@terminator.cc.umich.edu
>Systems Analyst                UUCP:     {rutgers,uunet}!sharkey!brian
>Henry Ford Hospital 	       Voice:    (313)-876-7461
>Detroit, MI 48202              FAX:      (313)-875-0315


Cabletron makes (2) spanning tree algorithm type bridges. Their
forwarding and filtering rates are superb. I think one is 24000/12000
and the other is 12000/?????.


-----------------------------------------------------------------------------
Bill Friday					
Computer Resources				brf@philabs.philips.com
Philips Laboratories				Voice (914) 945-6087
Briarcliff Manor, NY 10510
-----------------------------------------------------------------------------

From: Mike Rackley <RACKLEY%MSSTATE.BITNET@CUNYVM.CUNY.EDU>
Subject:    Re: Ethernet Bridge Recommendations?

We have been using the Retix 2244M bridges for about a year, and have
no complaints.  We use them to isolate building ethernets from our
campus fiber optic backbone.  It is hard to say if they are fast
enough for joining ethernet segments.  That would depend upon how
much traffic is on your ethernets.  Although our ethernets are not
heavily congested, the bridges have not been a problem so far.

By the way, I was told a couple of months ago that Retix has a newer,
faster, more expensive bridge.  It is called something like 2265.  As
I recall, it was rated at 8000 packets/second, and was about 15% more
expensive than the 2244M.

Mike Rackley                         |  Rackley@MsState.BITNET
Mgr. Systems & Networks Programming  |  Rackley@CC.MsState.EDU
P.O. Drawer CC                       |  Phone:   (601)325-2942
Mississippi State, MS 39762          |  FAX:     (601)325-3299

From: jam%LONEX.RADC.AF.MIL%mailrus.uucp@mailgw.cc.umich.edu (Joel A. Mussman)
Subject: Re:  Ethernet Bridge Recommendations?

>I have about $6000 (at most $8000) to bridge 3 standard ethernet subnets,
>so far the best deal I can find is on 2 of Retix' low-end bridges that
>are rated for 6000 'frames/second'... is that fast enough for joining segments
>that have about 10 hosts each?? Security is something of an issue since
>there is clinical data on some hosts and research data on others, so I would
>like some control over access. 
> 
>So far I've looked at bridges from Micom, Raycom, Retix and DEC, are there
>any other vendors that I should try?
>
>Are there any bridges that I should avoid like the plague?            

Brian,

	I have three buildings with local basebands linked by fibers.
	Before the days of bridges we had unix-based gateways at
	each end of the fiber, but a while back we poped in the Retix
	bridges in place of them.

	We haven't had any problems with the Retix bridges.  They seem
	more than adequate to handle a significant amount of traffic
	(I have from two to 10 hosts on each net, and while my machines
	all are tcp/ip, one end of one of the basebands is plugged into
	a DECNET, which is a whopping big load).  I couldn't give you
	an exact figure because it depends on the average packet length
	on your network, but if you have a decent size packet (not everything
	sent is one byte long) then the bridges will probably outstrip
	the effective bandwidth of the ethernet (10mb ether tops out
	at about 7mb in reality).

	You might look at 3-Comm which makes a bridge, and possible
	talk to Chipcom (they are in the Boston area somewhere).

	I don't think you even want to approach the security issue
	at the bridge level.  It would take a really smart bridge
	to limit traffic to and from certain hosts and that really
	isn't feasible.  Note that when you use bridges you are creating
	one big logical network.  Routers would create multiple logical
	networks, and then you probably could limit traffic based on
	network address.  But if you had that scenerio, why would you
	want to plug in the "at risk" network in the first place?

	I think you have two things to consider:

		a) security is best handled by the host protecting itself
		b) the only totally secure system is in a tempest vault
			by itself with no terminal and the door welded
			shut.  Being at a military base, I realize you
			can't even trust the Marines guards anymore...
	
	Good luck with your endeavor!

Joel Mussman
jam@lonex.radc.af.mil

From: Paul C. Nunnally <pnunnal@cabell.vcu.edu>
Subject: Re: Ethernet Bridge Recommendations


Brian,

We use 3Com Bridge products which seem to work very well. Bridge was a seperate
company just recently bought by 3Com.  The Bridge products seem to be fairly
maintainance free.

You did not give enought information in you mail message.  I would need to
know what are the distances between the Segments.  

If you don't want to spend very much money you could also use PCROUTE.  It is a
public domain software which run on an XT with 2 Western Digital cards in it.

I have tested it out and it seem to work fine as an ip router. You can get the
software by anonymous ftp from off the network.  I am not sure of the location
but if you an interested send me a message back and I will send you the address.


Good luck and if you get the chance let me know what you decide on.

Paul C. Nunnally

Virginia Commonwealth University

internet -- pnunnal@cabell.vcu.edu


From: Mike Morris <morris@jade.Jpl.Nasa.Gov>
Subject: Re: Ethernet bridge recommendations?

In article <2926@sharkey.cc.umich.edu> you write:
>
>So far I've looked at bridges from Micom, Raycom, Retix and DEC, are there
>any other vendors that I should try?

Sytek, for one.  Was recently bought by Hughes, now knows as Hughes LAN systems
or something like that.

>Are there any bridges that I should avoid like the plague?            

DEC LANbridge!  Ask for a copy of the archive of the hatemail to be mailed
to you.  There was quite a message thread going here for a while.



From: haas@wasatch.utah.edu (Walt Haas)
Subject: Re: Ethernet bridge recommendations?
Organization: University of Utah, College of Engineering

I would advise you to check out the BICC Isolan bridge.


From: goodloe%b11%ingr.uucp@uunet.uu.net
Subject: Re: Ethernet bridge recommendations?

Try BICC. We really like their products.

tony goodloe


To: baw%sharkey%mailrus.uucp@mailgw.cc.umich.edu
Subject: Re: Ethernet bridge recommendations?

    I'm not a big Ethernet jock, but I have had to spec some
    Ethernet equipment for a project I'm responsible for here.
    One vendor I didn't see in your list was 3Com--they have 
    some bridging and routing products.  Their IB/3 product is
    fairly intelligent, and they also have an IB/2000 which is
    somewhat cheaper.  Our sales rep in Greensboro is pretty
    helpful, and was also flexible on price because he wants
    to break into our (fairly large) company.  I hope
    this helps --
                                  Tom Groot
                                  (919) 992-2610


From: Tom Cervenka    <CTCT100%UICVMC.BITNET@UICVM.uic.edu>
Subject:      Ethernet Bridges



 > So far I've looked at bridges from Micom, Raycom, Retix and DEC, are there
 > any other vendors that I should try?

 You might want to look at 3Com (formerly Bridge Communications). They make a
 couple of Ethernet bridges as well as gateways. I used their SNA product
 in my previous job, but I don't have any real experience with the bridges
 except to say that I've heard they're well designed and reliable.
 3Com: 408-562-6400 , Santa Clara, CA I think.
 ---------------------------------------------------------------
 Tom Cervenka - University of Illinois at Chicago
 Internet: ctct100@uicvmc.aiss.uiuc.edu   Bitnet: ctct100@uicvmc


-- 
Brian Wolfe                    Internet: baw@terminator.cc.umich.edu
Systems Analyst                UUCP:     {rutgers,uunet}!sharkey!brian
Henry Ford Hospital 	       Voice:    (313)-876-7461
Detroit, MI 48202              FAX:      (313)-875-0315

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 89 00:09:31 GMT
From:      rick@sbcs.sunysb.edu (Rick Spanbauer)
To:        comp.protocols.tcp-ip
Subject:   Re: trace route to OZ

In article <89Jul24.083917edt.57352@ugw.utcs.utoronto.ca>, WHITESID@McMaster.CA (Fred Whiteside) writes:
> >  Milo,
> >
> >  I don't regard the discussion of interesting routing phenomena between
> >  the furtherst outflings of the Internet as operational issues at all;
> >  in fact, some of the oddities being discovered may have very real
> >  impact on the understanding and solving of basic problems for users
> >  and operators of campus, regional and backbone networks. Your comments
> >  are out of place and leave the misleading impression that if our users
> >  simply call their network gurus everything will get well.
> >
> >  Dave

	Just want to file my $0.02 on this subject.  I've found the
	recent routing discussions that have taken place here to be
	both informative and useful.  Useful at least in so far as
	I might not have been motivated to install traceroute and
	use it to investigate problems with our regional network,
	Nysernet :-)  I don't think it does anyone a favour to insist
	that the Internet be thought of in the same inviolate black
	box model the telephone companies like us to think of their system
	as.  Let's continue the free flow of information and tools - our
	regional networks and Internet in general can only stand to
	gain by the exposure!

					Rick Spanbauer
					SUNY/Stony Brook

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 89 01:03:35 GMT
From:      sob@harvisr.harvard.edu (Scott Bradner)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP request

from MIT:
	allspice.lcs.mit.edu
	pub/snmp/snmp.tar

from CMU:
	lancaster.andrew.cmu.edu
	pub/cmu-snmp.9.tar
	pub/kip-snmp.9.tar

Scott

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 89 01:24:24 GMT
From:      bzs@ENCORE.COM (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   MacII FTP speeds on Ethernet


>Can somebody tell me what the bottleneck is on FTP transfer rates for
>a MacII on ethernet?  I am running two MacII's on a subnet in the 
>Atmospheric Sciences program here at Princeton, with a Sun 3/280
>file server also on the net.  I have the Apple ethernet cards in
>the machines, and am running NCSA Telnet 2.3 (which has server
>FTP support).  Basically, between the mac and the server I am
>getting no better than about 35K bytes/sec for binary transfers,
>no matter how I tweak the protocol parameters.

I believe if you run benchmarks writing the disk locally you'll find
it peaks at around 50K bytes/sec. With the additional overhead of the
network activity (those disks are all PIO, right?) you're probably
doing well at those speeds.

	-Barry Shein

Software Tool & Die, Purveyors to the Trade
1330 Beacon Street, Brookline, MA 02146, (617) 739-0202

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 89 02:59:26 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: trace route to OZ

In article <8907191847.AA06030@cincsac.arc.nasa.gov> medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) writes:
> The tcp-ip list is too big and too diverse to be used for network debugging.
> The MERIT folks and NASA both have mailing lists for operational issues
> which are appropriate for this type of discussion.

	While this may "officially" be true, I'd like to point out that I
for one have no objection to this on tcp-ip.  While I don't have any direct
involvement with routing issues, I am interested in knowing as much as I
can about it.  Listening in on the discussions about problems seems like a
good way of picking stuff up.
-- 
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 89 04:03:57 GMT
From:      joaquin@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: Announcing a little board-room shakeup


Dear IABers:

Shakeups are always interesting, specially when your are not part of
the bunch being shaken. I have a few questions:

1.  Can we expect the IRTF to meet in a similar fashion as the IETF
(maybe not as often, please)??? .....There is no question that the
success of the IETF over the past couple of years is due to Phil's
great job as a chair.  However, I also think it is due in part to the
fact that multiple working groups meet at the same time, which helps
tremendously in fostering the creation of new working groups when they
are needed, and in disseminating ideas. In addition, it is much easier
for some of us to find funding to attend larger (fewer) meetings.

2. I think that part of the IRTF goals should be to serve as a
clearinghouse of research ideas in internetworking.  This function
will be SOOOO important as we migrate to the future NREN!....and I
don't see any better forum that can be used to foster internetworking
research (the usual conferences cannot have a very clear focus over
the years).

3. Should we have an Annual IAB Workshop (i.e., a joint meeting of the
IRTF and IETF) once a year to bring together the latest
accomplishements in our community regarding research results and
engineering?......of course, with the best presentations during the
year from both groups.

4. I am confused about the IAB structure (not that it matters to
anyone, of course). Bob Braden explained what IRTF and IETF were meant
to be, but what is the role of the other members? 

5.  Why is "Security" not part of IRTF or IETF concerns (or both)? why
not have "Privacy" or "Billing" there too?

6. Why do we have liasons for the NSFNET and vendors, but not for the
academia at large, standards groups, research centers, or the
government (i.e., FRICC and DCA)?  This becomes particularly important
when one looks at the IAB functions!!! At a time when the government
is pushing for OSI standards, it is hard for me to see why vendors and
NSFNET have direct participation in the IAB, while organisms like NIST
and ANSI (for example) don't. I'd really like to have some folks from
the standars groups collaborating with the Internet very closely, so
that developments in the IETF and IRTF can impact the standarization
process "from within" (e.g., X500 and the handling of distributed
queries) and viceversa.

7.  What is meant by " [The IAB] Resolves technical issues which
cannot be treated within the IETF or IRTF frameworks."????? 

8. What is meant by "[The IAB] Acts as external policy representative
for the Internet community."???? who is the target audience of the IAB?

9. What is the detailed structure of the IETF and IRTF?????? Which are
the ATDs in IETF? which are the RGs of the IRTF? inquiring minds want
to know!


Looking forward to tomorrow.

Confusedly yours,

JJ

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 89 05:20:40 GMT
From:      rdp@pbseps.UUCP (Richard Perlman)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Macintosh SLIP

[]
I am planning on "bridging" a remote located Mac to the Office LAN.  I
have developed a variety of possibilities...  and would like some help.  

I should note the following 'facts':
	Connection will be at 9600 over async modems (actually Data 
	Over Voice 'modems'; 'DOVs') at each end connected through an
	X.25 Packet switch.  (Connection could be raised to 19.2 
	in the future.)

	Office LAN consists of one LocalTalk zone bridged to
	one ethernet LAN through a FastPath 4.  There is a Shiva
	NetSerial on the LocalTalk and an Annex II terminal server 
	on the e-net.  The Annex can run SLIP.

	One spare Shiva net serial is available for use at the
	remote location if necessary.  The Shiva AppleTalk 'modem'
	driver is installed on the remote.

	My major interest is connecting with our UNIX minicomputer, 
	so getting AppleTalk to work isn't essential if a "really
	good" tcp/ip solution is available.  By the way, we are 
	running CAP on the UNIX box.

Diagram of proposed network possibilities:

        Remote                 9.6 remote/office link         Office
        ^^^^^^                 ^^^^^^^^^^^^^^^^^^^^^^         ^^^^^^
AppleTalk or SLIP
          v
 +-----+  v
 | mac |  v +---------+     packet switched x.25 net     +---------+
 +-----+-_-_| 9.6 DOV |-_-_([][][][][][][][][][][][])-_-_| 9.6 DOV |==rs232
 |_____| x  +---------+                                  +---------+ 
         ^---<Note: Could place NetSerial here

~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-

 Office (cont'd)    {  +-----------+    +----------+
 ^^^^^^^^^^^^^^^    {  | NetSerial |-_-_| FastPath |-_-_-(LocalTalk LAN)
                    {  +---------+-+    +----------+
		    {   AppleTalk+
		    {      +
(rs232 from DOV)-_-_{-_-_-_+         or
                    {      +
                    {    SLIP+
		    {  +-----+----+     {   +-----------+
		    {  |     rs232|-_-_ { -_| NetSerial |-_-_-(LocalTalk LAN)
		    {  |          |     {   + ----------+
		    {  | Annex II |     { or
		    {  |          |     {  
		    {  |  ethernet|xxxx { xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
		    {  +----------+     {            X                 X
		                        { +----------X---------+  +----X-----+
		                        { | UNIX mini computer |  | FastPath |
		                        { +--------------------+  +----------+

So, does anyone know of an "EtherTalk" SLIP driver, or even plain
SLIP for the MAC?  Could I connect to the Annex using slip and
then go back out of the annex serially to the NetSerial?  And what 
experience have you had using 1 (or 2) Net Serials to create a bridge?

Or, what other bright ideas do you have... ?

Preferred; replies by e-mail.  I will summarize and post/forward
results as interest warrants.

Thnx...
-- 
Richard Perlman * rdp@pbseps.pacbell.com || {ames,sun,att}!pacbell!pbseps!rdp
180 New Montgomery St. rm 602,  San Francisco, CA  94105  |*| 1(415) 545-0233

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 89 05:24:36 GMT
From:      att!pacbell!pbseps!rdp@ucbvax.Berkeley.EDU  (Richard Perlman)
To:        tcp-ip@sri-nic.arpa
Subject:   Macintosh SLIP
[]
I am planning on "bridging" a remote located Mac to the Office LAN.  I
have developed a variety of possibilities...  and would like some help.  

I should note the following 'facts':
	Connection will be at 9600 over async modems (actually Data 
	Over Voice 'modems'; 'DOVs') at each end connected through an
	X.25 Packet switch.  (Connection could be raised to 19.2 
	in the future.)

	Office LAN consists of one LocalTalk zone bridged to
	one ethernet LAN through a FastPath 4.  There is a Shiva
	NetSerial on the LocalTalk and an Annex II terminal server 
	on the e-net.  The Annex can run SLIP.

	One spare Shiva net serial is available for use at the
	remote location if necessary.  The Shiva AppleTalk 'modem'
	driver is installed on the remote.

	My major interest is connecting with our UNIX minicomputer, 
	so getting AppleTalk to work isn't essential if a "really
	good" tcp/ip solution is available.  By the way, we are 
	running CAP on the UNIX box.

Diagram of proposed network possibilities:

        Remote                 9.6 remote/office link         Office
        ^^^^^^                 ^^^^^^^^^^^^^^^^^^^^^^         ^^^^^^
AppleTalk or SLIP
          v
 +-----+  v
 | mac |  v +---------+     packet switched x.25 net     +---------+
 +-----+-_-_| 9.6 DOV |-_-_([][][][][][][][][][][][])-_-_| 9.6 DOV |==rs232
 |_____| x  +---------+                                  +---------+ 
         ^---<Note: Could place NetSerial here

~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-

 Office (cont'd)    {  +-----------+    +----------+
 ^^^^^^^^^^^^^^^    {  | NetSerial |-_-_| FastPath |-_-_-(LocalTalk LAN)
                    {  +---------+-+    +----------+
		    {   AppleTalk+
		    {      +
(rs232 from DOV)-_-_{-_-_-_+         or
                    {      +
                    {    SLIP+
		    {  +-----+----+     {   +-----------+
		    {  |     rs232|-_-_ { -_| NetSerial |-_-_-(LocalTalk LAN)
		    {  |          |     {   + ----------+
		    {  | Annex II |     { or
		    {  |          |     {  
		    {  |  ethernet|xxxx { xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
		    {  +----------+     {            X                 X
		                        { +----------X---------+  +----X-----+
		                        { | UNIX mini computer |  | FastPath |
		                        { +--------------------+  +----------+

So, does anyone know of an "EtherTalk" SLIP driver, or even plain
SLIP for the MAC?  Could I connect to the Annex using slip and
then go back out of the annex serially to the NetSerial?  And what 
experience have you had using 1 (or 2) Net Serials to create a bridge?

Or, what other bright ideas do you have... ?

Preferred; replies by e-mail.  I will summarize and post/forward
results as interest warrants.

Thnx...
-- 
Richard Perlman * rdp@pbseps.pacbell.com || {ames,sun,att}!pacbell!pbseps!rdp
180 New Montgomery St. rm 602,  San Francisco, CA  94105  |*| 1(415) 545-0233
-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 89 07:15:40 GMT
From:      ggm@brolga.cc.uq.oz (George Michaelson)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   UK OSI promotion methods (sigh)


According to an OSI appraisal/newsletter which shall remain nameless
the UK Government is releasing a boardgame with the theme of OSI to
be issued to Industry managers as part of a UKStg 12m package of
promotions.

The mind boggles. 

Has anybody out there received a copy of "7-layer Monopoly" yet?

	If you put 3 red modems and a Green Brouter on Park Lane can
	you charge CCITT tarrif rates?

	Can I be the little silver breakout box?

	Do not pass state <ready>. Do not collect 700Mb. Go directly to
	Bogonland.

On a more serious note the same issue carries a resume of a presentation
by Prof. Linington (UKC/JNT/RARE) which seems to commit RARE-based activity
to CONS. I thought this was still an open issue. Will *all* EC funding be
directed at CONS based WAN or is there any hope of CNLS? Some of the
statements about security/scaleability/speed are (in my mind) still open.

[Ok it was Open Systems Newsletter V3 Issue 5  May 1989. Mail delivery
 in Australia is sloooooow]

	-George
ACSnet: ggm@brolga.cc.uq.oz                    Phone: +61 7 377 4079
Postal: George Michaelson, Prentice Computer Centre
          Queensland University, St Lucia, QLD 4067 

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 1989 14:33:15 EDT (Tue)
From:      Dan Hoey <hoey@aic.nrl.navy.mil>
To:        TCP-IP@SRI-NIC.ARPA, comp.protocols.tcp-ip
Cc:        Postmaster@Merit.EDU, Postmaster@DEVVAX.TN.Cornell.EDU
Subject:   Re:  trace route to OZ (indeed!)
In article <8907200854.AA02438@sapphire.oce.orst.edu> pvo3366@OCE.ORST.EDU (Paul O'Neill) writes:
...
>20  La_Jolla,CA.NSS.NSF.NET (129.140.6.14)  1240 ms *  1370 ms 
>21  La_Jolla,CA.NSS.NSF.NET (129.140.6.11)  1390 ms  1320 ms  1460 ms 

Say what you like about the bad old host table days, but at least we
didn't get any commas in the host names back then.  I can't even find
out the mail address for whatever zone 14.6.140.129.IN-ADDR.ARPA is in,
but I can hope that the postmasters at the authoritative servers may be
able to figure it out.

Considering what would happen if this name got into a mail header, I
just wonder if it's possible to get CRLFs into the canonical name,
leading to wholesale rewriting of mail headers through host name
canonicalization.  But surely that's impossible....

Dan

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jul 89 16:27:57 CDT
From:      "Linda Winkler,   312-972-7236" <B32357@ANLVM.CTD.ANL.GOV>
To:        <TCP-IP@SRI-NIC.ARPA>
Is anyone aware of a TCP/IP terminal server which can
also run TN3270?
-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 89 12:33:36 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   ethernet bridge recommendations


wow!  quite a list of recommendations...  a few comments:

-- about those "incredible" forwarding/filtering rates.  
   many of them are BUNK!  there is no good standard for measuring
   bridge performance now.  the chair you are sitting in could currently
   be said to have a filtering rate of 1 Gigapacket per second.  

   forwarding rates can be misleading as well.  what happens when
   your destination ethernet is busy?  are packets dropped?  
   buffering and load-smoothing characteristics are important and
   can be largely independent of filtering/forwarding rates...

-- the DEC bridge had a bug -- but it is still the standard by 
   which bridges are measured, with regard to performance.  it's quick.

steve elias, software engineer (bridging)
chipcom corporation




-- 
 ...... Steve Elias (eli@spdcc.com);(6178591389);(6178906844) {}
 /* so much entropy, so little time */

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 89 14:36:08 GMT
From:      hal@GATEWAY.MITRE.ORG (Hal Feinstein)
To:        comp.protocols.tcp-ip
Subject:   Re:  Terminology deplored

We've been using the word "gate" in security work as a specific 
kind of network security guard function.  The history of it's use goes back
at least a decade. The notion of gate in gateway seems to go back to
it's metaphorical core: For example, "Vienna, the gateway to the 
West (East)"  etc. indicating a passage or entrance. Gate brings to 
mind a security role, good for our use of the term but bad as a
shortcut for an entrance. 

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 89 16:36:32 GMT
From:      bin@primate.wisc.edu (Brain in Neutral)
To:        comp.protocols.tcp-ip
Subject:   Re: Computer security report available

From article <8907211627.aa28013@note.nsf.gov>, by steve@NOTE.NSF.GOV (Stephen Wolff):
> The report is available by anonymous ftp from the NSF Network Service
> Center on host nnsc.nsf.gov <128.89.1.178> in directory pub, from the NSF

That's nnsc.nsf.net, not .gov, I believe.

Paul DuBois
dubois@primate.wisc.edu

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 89 18:33:15 GMT
From:      hoey@aic.nrl.navy.mil (Dan Hoey)
To:        comp.protocols.tcp-ip
Subject:   Re:  trace route to OZ (indeed!)

In article <8907200854.AA02438@sapphire.oce.orst.edu> pvo3366@OCE.ORST.EDU (Paul O'Neill) writes:
...
>20  La_Jolla,CA.NSS.NSF.NET (129.140.6.14)  1240 ms *  1370 ms 
>21  La_Jolla,CA.NSS.NSF.NET (129.140.6.11)  1390 ms  1320 ms  1460 ms 

Say what you like about the bad old host table days, but at least we
didn't get any commas in the host names back then.  I can't even find
out the mail address for whatever zone 14.6.140.129.IN-ADDR.ARPA is in,
but I can hope that the postmasters at the authoritative servers may be
able to figure it out.

Considering what would happen if this name got into a mail header, I
just wonder if it's possible to get CRLFs into the canonical name,
leading to wholesale rewriting of mail headers through host name
canonicalization.  But surely that's impossible....

Dan

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 89 21:27:57 GMT
From:      B32357@ANLVM.CTD.ANL.GOV ("Linda Winkler,   312-972-7236")
To:        comp.protocols.tcp-ip
Subject:   (none)

Is anyone aware of a TCP/IP terminal server which can
also run TN3270?

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 1989 01:29-EDT
From:      CERF@A.ISI.EDU
To:        joaquin@SRI-NIC.ARPA
Cc:        ietf@VENERA.ISI.EDU, tcp-ip@SRI-NIC.ARPA ddc@XX.LCS.MIT.EDU
Subject:   Re: Announcing a little board-room shakeup

1. IRTF will meet on a schedule to be determined by Dave Clark.
   He is just as interested as you are in reducing the number of meetings
   we all have to attend.

2. IRTF will have access to the same clearinghouse mechanisms that
   the rest of the IAB system has (RFCs, Internet-Drafts Directory,
   etc.)

3. Annual IAB meeting... In some sense, the Interop meetings
   seem to fill a part of that need. And the IETF meeting 
   minutes are reported quarterly. I'm not sure we need another
   meeting...

4. The IAB itself is responsible for technical policy, for
   setting the objectives for IRTF and IETF (which are reduced
   to practice by the IRSG and IESG), dealing with external
   liaison (e.g. with FRICC, CCIRN, RARE, NIST, ...), breaking
   logjams impeding progress on standards for the Internet, and
   so on. The members of IAB proper have other roles in the Internet
   community, as should be obvious from the list that Braden provided.

5. Security has become such a visible issue for the Internet
   (see GAO report and recent hearings on the Hill) that I wanted
   top-level attention to policy matters. There may, indeed, 
   continue to be an IRTF group focused on security/privacy
   chaired by Steve Kent - but this remains to be seen as Dave
   Clark works out the structure of IRTF.

6. IAB has liaison with FRICC in several ways. I am generally
   invited to FRICC meetings except when they are for gov't only;
   Phill Gross runs the special FRICC engineering planning group;
   FRICC is invited to IAB meetings ex officio. IAB has had
   NIST visitors and will be working out specific IETF and possibly
   IRTF working group/research group joint efforts with them.
   Network management and white pages registrations are examples
   of areas where we expect some specific work. It is not clear
   that we need a NIST representative on the IAB if we can work out
   specific working group interactions.

   Collaboration with ANSI and IEEE is under consideration but, again,
   I suspect that we may find this working better through specific
   IETF working groups or IRTF research groups because ANSI and IEEE
   are not easily representable by a single individual. Rather, they are
   represented by each working group on particular topics, which matches
   our IRTF and IETF structure.

7. IAB will resolve standards matters when they cannot be resolved
   within the IETF or IRTF.

8. IAB will represent the Internet community and its standards,
   when necessary, before the Defense Protocol Standards Steering
   Group, ANSI, NIST, CCIRN, FRICC, RARE, and so on.

9. IETF and IRTF structures are being worked out in detail and
   will be reported by Phill Gross and Dave Clark as soon as these
   details are settled.

Vint Cerf
Chairman
IAB
-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 89 02:47:38 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  trace route to OZ

Sergio,

Yummy, you sailed right into that one. I hear you say you appreciate the
value of accurate clock synchronization. You have a weenie Fuzzball chiming
second-class time right in the middle of your swamp that just begs for a
first-class radio to improve the quality of chime to the max. Do you think
you could add such a thing to your rate base? Then we can both gang up on
our Norse friends and try to talk them into hooking a cesium clock I know
about near Oslo (NTARE) into our chime network. Tempus frugit or something
like that.

Dave

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 89 02:53:46 GMT
From:      doherty@vax1.tcd.ie
To:        comp.protocols.tcp-ip
Subject:   class b IP addresses

I wish to apply for a class B IP address for the
University of Dublin, Ireland.
     
Can anyone tell me how I go about this please.
I have been given a number of e-mail addresses
by local sources but they have not been correct.
Help would be much appreciated.
regards Michael Doherty, Computer Lab.,
                         Trinity College, University of dublin,
                         Dublin 2, Ireland
                         Doherty@vax1.TCD.IE
                         TEL. 353-1-772941 X 1751. FAX +353-1-792587.
.
QUIT

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 89 03:47:00 GMT
From:      ljm@TWG.COM (Leo J McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   Re: PC scorecard (and the NIC)



>This table is meant to service users of the network in gaining more
>information about a product.  In order to limit the "commercialism"
>that is inherent in this Scorcard, each vendor is allowed to supply
>either a single Internet address...

We are writing TCP/IP software, right???  I quick telnet to sri-nic.arpa
and a few WHOISs reveals the address (and usually much more) of every
'vendor' on the list.  (Assuming you know that the FUSION package is NRC's,
KA9Q is Phil Karn's, and Wollongong is really *The* Wollongong Group.
These tidbits of information should probably be added to the scorecard.)
Those vendors without much additional information (including TWG to my
dismay) will usually answer to sales@address or support@address.

Adding the NIC's address and a bit of information about who it is
and what does would be a good deal more useful to users and the Internet
than a list of our FAX numbers.  Perhaps some site might get IP addresses
assigned BEFORE they installed their network (8^)).


Moreover, the whole point of 'limiting the commercialism' is that this
forum is designed to promote a safe and sane Internet with TCPs that work.
Promoting the NIC certainly meets those criteria.  Providing the addresses
of Phil Karn, James B. VanBokkelen, myself, or anyone else who does real,
live protocol work to future protocol builders who might not have access
to the NIC meets those criteria.
(Though if you read this list how could you not know our addresses?).

The PC/IP Scorecard is a sales slick, albeit a multi-vendor one.  The
entries are not "is IP reassembly supported", "may user set 0 or 1 for
IP broadcast", or "may user set Time-to-live", the sort of question one
would like ask to keep the Internet from melting down, but are instead a
listing of product features a potential customer might find useful.

If you believe that dispersing information about and making readily
available as many TCP/IP implementations as possible comes under the
heading of promoting TCPs that work (which appears to be the justification
for the PC Scorecard) then it is counterproductive to limit the information
about the vendors.  Phone numbers, FAX numbers, email addresses, and mail
addresses could all be useful to make available a particular package to
some potential TCP/IP user.  On the other hand, if you believe that
dispensing any information about how to obtain a product is 'commerical'
for the purposes of the net then justifing a breach of that policy by
limiting it to one piece is absurd.


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

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Jul 89 08:27:36 EDT
From:      Douglas Greenwald <R1DAG%AKRONVM.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Cabling Feasability Question
Hello patient readers,
Here in the Engineering building of University of Akron, we have bunches
of cable run from our lab to offices.  the cable is NOT 'true' twisted
pair, it is just straight  serial cabling.  Therefore, any of the twisted
pair ethernet boxes will not function.  Is there any way of using this
wiring to connect offices to our thin-net?  We are looking to aviod
having to re-cable the building for time and monetary considerations.

I've heard of SLIP, would this be something to look into?

In case vendors matter, our thin-net is a group of HP 9000/340 work-
stations attached to the campus backbone thru a Cisco gateway.

                        Thanx for any info.

                        Douglas Greenwald,
                        Computer Network Analyst,
                        Engineering Computer Graphics Facility,
                        College of Engineering,
                        University of Akron.

Bitnet:  R1DAG@AKRONVM
Internet:  r1dag@vm1.cc.uakron.edu, doug@vax1.cc.uakron.edu

P.S.  Sorry if this comes thru twice.  I never saw it the first time.
-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 89 05:29:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Announcing a little board-room shakeup


1. IRTF will meet on a schedule to be determined by Dave Clark.
   He is just as interested as you are in reducing the number of meetings
   we all have to attend.

2. IRTF will have access to the same clearinghouse mechanisms that
   the rest of the IAB system has (RFCs, Internet-Drafts Directory,
   etc.)

3. Annual IAB meeting... In some sense, the Interop meetings
   seem to fill a part of that need. And the IETF meeting 
   minutes are reported quarterly. I'm not sure we need another
   meeting...

4. The IAB itself is responsible for technical policy, for
   setting the objectives for IRTF and IETF (which are reduced
   to practice by the IRSG and IESG), dealing with external
   liaison (e.g. with FRICC, CCIRN, RARE, NIST, ...), breaking
   logjams impeding progress on standards for the Internet, and
   so on. The members of IAB proper have other roles in the Internet
   community, as should be obvious from the list that Braden provided.

5. Security has become such a visible issue for the Internet
   (see GAO report and recent hearings on the Hill) that I wanted
   top-level attention to policy matters. There may, indeed, 
   continue to be an IRTF group focused on security/privacy
   chaired by Steve Kent - but this remains to be seen as Dave
   Clark works out the structure of IRTF.

6. IAB has liaison with FRICC in several ways. I am generally
   invited to FRICC meetings except when they are for gov't only;
   Phill Gross runs the special FRICC engineering planning group;
   FRICC is invited to IAB meetings ex officio. IAB has had
   NIST visitors and will be working out specific IETF and possibly
   IRTF working group/research group joint efforts with them.
   Network management and white pages registrations are examples
   of areas where we expect some specific work. It is not clear
   that we need a NIST representative on the IAB if we can work out
   specific working group interactions.

   Collaboration with ANSI and IEEE is under consideration but, again,
   I suspect that we may find this working better through specific
   IETF working groups or IRTF research groups because ANSI and IEEE
   are not easily representable by a single individual. Rather, they are
   represented by each working group on particular topics, which matches
   our IRTF and IETF structure.

7. IAB will resolve standards matters when they cannot be resolved
   within the IETF or IRTF.

8. IAB will represent the Internet community and its standards,
   when necessary, before the Defense Protocol Standards Steering
   Group, ANSI, NIST, CCIRN, FRICC, RARE, and so on.

9. IETF and IRTF structures are being worked out in detail and
   will be reported by Phill Gross and Dave Clark as soon as these
   details are settled.

Vint Cerf
Chairman
IAB

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 89 08:40:16 GMT
From:      eloranta@tukki.jyu.fi (Jussi Eloranta)
To:        comp.protocols.tcp-ip
Subject:   New and cleaned version of etherprint available


New (and cleaned) version of etherprint (epr) is available from 
tukki.jyu.fi (128.214.7.5).

Everything is now in english not finnish :-)

-jme
-- 
============================================================================
Jussi Eloranta               Internet(/Bitnet):
University of Jyvaskyla,     eloranta@tukki.jyu.fi
Finland                      [128.214.7.5]

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 89 08:44:34 GMT
From:      grn@stl.stc.co.uk (Gary Nebbett)
To:        comp.protocols.tcp-ip
Subject:   inverting source routes

When a machine running SunOS 4.0.1 replies to a packet received with an IP
source route option it appears to correctly invert the source route but it does
not seem to reset the pointer.

I have looked at the 4.3BSD sources posted to comp.bugs.4bsd.ucb-fixes last
year and they seem to have the same problem.

Sorry to post this to such a large list but I have heard that the "well known
names" associated with the 4.3BSD networking software have unmanagably large
email in-trays.

Regards,
        Gary Nebbett           STL, London Road, Harlow, Essex  CM17 9NA, UK
        Voice +44-279-29531  Email grn@stl.stc.co.uk | PSI%234237100122::GRN

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 89 12:27:36 GMT
From:      R1DAG@AKRONVM.BITNET (Douglas Greenwald)
To:        comp.protocols.tcp-ip
Subject:   Cabling Feasability Question

Hello patient readers,
Here in the Engineering building of University of Akron, we have bunches
of cable run from our lab to offices.  the cable is NOT 'true' twisted
pair, it is just straight  serial cabling.  Therefore, any of the twisted
pair ethernet boxes will not function.  Is there any way of using this
wiring to connect offices to our thin-net?  We are looking to aviod
having to re-cable the building for time and monetary considerations.

I've heard of SLIP, would this be something to look into?

In case vendors matter, our thin-net is a group of HP 9000/340 work-
stations attached to the campus backbone thru a Cisco gateway.

                        Thanx for any info.

                        Douglas Greenwald,
                        Computer Network Analyst,
                        Engineering Computer Graphics Facility,
                        College of Engineering,
                        University of Akron.

Bitnet:  R1DAG@AKRONVM
Internet:  r1dag@vm1.cc.uakron.edu, doug@vax1.cc.uakron.edu

P.S.  Sorry if this comes thru twice.  I never saw it the first time.

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 89 15:39:31 GMT
From:      jos@idca.tds.PHILIPS.nl (Jos Vos)
To:        comp.protocols.tcp-ip
Subject:   Info wanted about Wollongong's WIN/TCP socket library

I'm interested in experiences with Wollongong's socket library
in their WIN/TCP package for UNIX V.3 systems, especially concerning
the 3.0 release of WIN/TCP for UNIX V.3.2.

With "experiences" I mean: problems detected concerning incompatibility
with BSD4.3 sockets. Other problems are "welcome" (...) too.

-- 
-- ######   Jos Vos   ######   Internet   jos@idca.tds.philips.nl   ######
-- ######             ######   UUCP         ...!mcvax!philapd!jos   ######

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 89 15:52:52 GMT
From:      heker@JVNCA.CSC.ORG (Sergio Heker)
To:        comp.protocols.tcp-ip
Subject:   Re:  trace route to OZ

Dave,

I am certainly interested. This is in my list of things to explore.

Cheers!.


						-- Sergio


-----------------------------------------------------------------------------
|		John von Neumann National Supercomputer Center		    |
|  Sergio Heker				tel:	(609) 520-2000		    |
|  Director for Networking		fax:	(609) 520-1089		    |
|  Internet: "heker@jvnca.csc.org"	Bitnet:	"heker@jvnc"		    |
-----------------------------------------------------------------------------

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 89 17:10:00 GMT
From:      zweig@p.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: trace route to OZ


> Written Jul 24, 1989 by roy@phri.UUCP in comp.protocols.tcp-ip
> In article <8907191847.AA06030@cincsac.arc.nasa.gov> medin@NSIPO.NASA.GOV
>    ("Milo S. Medin", NASA ARC NSI Project Office) writes:
> > The tcp-ip list is too big and too diverse to be used for network debugging.
> > The MERIT folks and NASA both have mailing lists for operational issues
> > which are appropriate for this type of discussion.
> 
> 	While this may "officially" be true, I'd like to point out that I
> for one have no objection to this on tcp-ip.  While I don't have any direct
> involvement with routing issues, I am interested in knowing as much as I
> can about it.  Listening in on the discussions about problems seems like a
> good way of picking stuff up.
> -- 

  I agree very strongly with this and the other similar opinions that have
been expressed recently. Finding problems people are having can be very
instructive about complex software systems like communication protocol
subsystems. I think the "we don't have the time for your silly little
problems" sentiment would be more appropriate in comp.protocols.ivory-tower.


-Johnny Zweig
 University of Illinois at Urbana-Champaign
 Department of Computer Science
--------------------------------Disclaimer:------------------------------------
   Rule 1: Don't believe everything you read.
   Rule 2: Don't believe anything you read.
   Rule 3: There is no Rule 3.
-------------------------------------------------------------------------------

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 89 18:19:14 GMT
From:      nf@cel.UUCP (Noah Freedman)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP etc on "strange" hosts

John McMahon <FASTEDDY@dftnic.gsfc.nasa.gov> in a message dated 20 Jul 89 
asked -
>>Recently there was a "comparison list" posted on the merits of the various
>>flavors of TCP/IP for PCs and their ilk.  Has anyone ever compiled a
>>similar item for VAX/VMS systems (and their ilk) ?

At the risk of being boring, is/was there such an analysis done for (Q-bus)
PDP-11 machines, running RSX-11 and/or RT-11? There are a number of Q-bus
boards, but virtually all of the software support is Vax/VMS.

Areas of interest:

*    TCP-TCP performance
*    FTP performance
*    RSX-11-based interworking with NFS hosts
*    RT-11-based interworking with NFS hosts - client only, I presume.
     (An equivalent of PC-NFS?)

I'll publish our own results if there is any interest shown!

Noah Freedman <nf@cel.uucp>
Crosfield Electronics Ltd
Hemel Hempstead
UK




My prime concerns would be:

1 - Applications (Telnet, FTP, NFS, SMTP, FINGER, Etc.)
2 - System Overhead (Some products use a "smart" board for the lower-level
IP
    stuff, etc.)
3 - Standards Compliance (At least one manufacturer does not support the 
    format of HOSTS.TXT [argh])
4 - Nameserver support
5 - Support for connections "other than Ethernet"

If one hasn't been done...  I'll work on it...

+-------------------------------------+-------------------------------------
--+
| John "Fast Eddie" McMahon           |    Span: SDCDCL::FASTEDDY (Node 6.9)
  |
| Advanced Data Flow Technology Office|    Arpa:
 FASTEDDY@DFTNIC.GSFC.NASA.GOV |
| Code 630.4 - Building 28/W255       |  Bitnet: FASTEDDY@DFTBIT
           |
| NASA Goddard Space Flight Center    |GSFCmail: JMCMAHON
                  |
| Greenbelt, Maryland 20771           |   Phone: x6-2045
                      |
+-------------------------------------+-------------------------------------
--+

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 89 19:03:43 GMT
From:      seth@ctr.columbia.edu (Seth Robertson)
To:        comp.protocols.tcp-ip
Subject:   Re: New and cleaned version of etherprint available

In article <1052@tukki.jyu.fi> eloranta@tukki.jyu.fi (Jussi Eloranta) writes:
>
>New (and cleaned) version of etherprint (epr) is available from 
>tukki.jyu.fi (128.214.7.5).


There is a version available for anonymous ftp in the United States.

sol.ctr.columbia.edu [128.59.64.40] in the directory /pub


-- 
					-Seth Robertson
					 seth@ctr.columbia.edu

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 89 19:54:58 GMT
From:      gnu@hoptoad.uucp (John Gilmore)
To:        comp.protocols.tcp-ip
Subject:   Re: Worm report fails to address the problem

I found the OTA worm report to not be very helpful.

It recommends central control of Internet security.  Of course, this is
what a government would tend to recommend -- centralization of authority.
We have several centralized authorities  for security and privacy now --
the NSA, NIST, and CERT.  NSA is habitually silent (protecting its own
security, not anyone else's), NIST doesn't seem to have the expertise,
and CERT seems to be following the NSA model (all information flows
inward).

It discussed several research projects, including the use of cryptography
for email; Kerberos; and formal proofs of programs.  What it forgot to point
out was that none of this research would have had any effect on the worm.

It talks about existing laws and proposed bills that would criminalize the
release of a worm -- while conveniently ignoring that these bills would
criminalize things that all of us do daily.

I think that *responsibility* for security should still rest on the
individual hosts and networks.  However, there should be public *testing*
of security by any interested parties, in the spirit of fire drills.

Responsibility for security should remain decentralized because one
model is not appropriate for all sites.  A central bureacracy will not
have experts in each type of machine on the Internet.  And central rules
will necessarily be compromises -- too loose for some sites, too strict
for others.

The key to making decentral security work is public testing.  On the
third Tuesday of each month, say, it's open season on breaking into
other peoples' machines over the Internet -- IF you provide a
transcript of your actions afterward.  Organizations with particular
security concerns can fund people to test their own security, or can
swap with another organization and test each others' security.  DARPA
and NSF can fund a few people to do more widespread "scattergun"
testing.  And there will always be plenty of volunteers because people
like to solve puzzles.

The key is to make this a regularly scheduled, publicly sanctioned
event.  You could even award prizes, as in the computer Go tournaments
or the Obfuscated C contest -- highest volume of systems cracked, most
obscure hole found, hardest to fix problem, least visible intrusion,
etc.  These could even carry cash prizes -- if you break into a NASA
computer during such a fire drill, and document your breakin, we'll pay
you $1000.  This would fund the best crackers so they could afford to
continue providing high quality testing.  Entire classes of
undergraduates and grad students could do security testing projects,
using the Internet as their testbed.  This would educate lots of folks
about how to provide good security, and make the Internet the most
secure network, by constantly testing and fixing its security.

Of course, people who didn't *want* to fix their security could just
drop off the net one Tuesday a month.  But public disclosure of the holes
found in other systems would make their systems more vulnerable the
rest of the time, and they would have strong incentive to either clean
up their security, or drop off the Internet.  In either case the Internet
is left more secure.

The only way I can see to keep the Internet secure is "eternal vigilance".
A central security bureau will not be eternally vigilant -- it will become
bureaucratic and lazy.  And it will have no incentive to reveal what it
has learned about security, except to small numbers of people (e.g. the
people who maintain 'sendmail' at various vendors).  In fact, revealing
breakins will DECREASE its reputation -- "No one has ever escaped from
Stalag 13!"

There seems to be a meme loose today that wants to criminalize all sorts
of activities -- that views making something illegal a "fix" for the problems
it presents.  But the problems persist regardless of what the laws say.
I think something closer to a "fix" would be to bring the activity out
of the underground and diffuse it through society, in a cooperative rather
than combative situation.

*If we keep treating security testing as someting only criminals will do,
only criminals will do it!*
-- 
John Gilmore      {sun,pacbell,uunet,pyramid}!hoptoad!gnu      gnu@toad.com
      "And if there's danger don't you try to overlook it,
       Because you knew the job was dangerous when you took it"

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 89 20:08:30 GMT
From:      gnu@hoptoad.uucp (John Gilmore)
To:        comp.protocols.tcp-ip,misc.legal
Subject:   Prosecution in the Internet Worm case

GAO/IMTEC-89-57 report:
>                                                        As of
> March 23, 1989, there have been no indictments in the Internet
> virus case.  Because it is an open matter, Justice officials
> would not provide any specific information about the case.

Do they plan to leave it "open" until the statute of limitations runs out?

I don't think Mr. Morris should be left hanging like this.  They have all
the evidence they are likely to get.  If there is a case, fine, indict the
guy.  If not, drop it.  The current situation bears no resemblance to
"Justice".
-- 
John Gilmore      {sun,pacbell,uunet,pyramid}!hoptoad!gnu      gnu@toad.com
      "And if there's danger don't you try to overlook it,
       Because you knew the job was dangerous when you took it"

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 89 21:49:00 GMT
From:      patterso@hardees.rutgers.edu (Ross Patterson)
To:        comp.protocols.tcp-ip
Subject:   Re: Announcing a little board-room shakeup

Bob,

   The IAB's position in the pre-NSF Internet was pretty  clear, given DARPA's
   and DCA's position on  policy matters,  and the  fact that  they funded the
   whole kit and caboodle.  With the advent of  the NSFNet  Backbone, and soon
   the Federal Research  Internet, things  seem a  little cloudy.   From where
   does the IAB draw its authority in this modern world?  Is it still formally
   authorized by the funing agencies,  or has  it evolved  into an independent
   group of network gurus, leading rather than commanding?

   In short, is there anything special about the IAB, or could  someone form a
   competeing group and offer their own view of the world now?

Ross Patterson
Rutgers University
P.S. No, I haven't got any plans. Just curious, thanks. RAP

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Jul 89 08:33:34 -0400
From:      Andy Malis <malis@BBN.COM>
To:        John Gilmore <pacbell!hoptoad!gnu@ames.arc.nasa.gov>
Cc:        tcp-ip@sri-nic.arpa, malis@BBN.COM
Subject:   Re: Prosecution in the Internet Worm case
> I don't think Mr. Morris should be left hanging like this.

Yesterday, Mr. Morris received a federal indictment.  He faces up
to 5 years in jail and/or a $250,000 fine.

Andy
-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 01:54:21 GMT
From:      seth@ctr.columbia.edu (Seth Robertson)
To:        comp.protocols.tcp-ip
Subject:   Re: New and cleaned version of etherprint available

In article <1989Jul26.190343.13181@ctr.columbia.edu> seth@ctr.columbia.edu (Seth Robertson) writes:
>In article <1052@tukki.jyu.fi> eloranta@tukki.jyu.fi (Jussi Eloranta) writes:
 
>>New (and cleaned) version of etherprint (epr) is available from 
>>tukki.jyu.fi (128.214.7.5).
 
>There is a version available for anonymous ftp in the United States.
>sol.ctr.columbia.edu [128.59.64.40] in the directory /pub


For those of you who tried getting it and failed, please try again.

I mistakenly chmoded /bin to 444, which, as one might expect, did not
help matters...


					 Sorry for the inconvenience,
-- 
					-Seth Robertson
					 seth@ctr.columbia.edu

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Jul 89 09:49:08 -0400
From:      jam@LONEX.RADC.AF.MIL (Joel A. Mussman)
To:        tcp-ip@sri-nic.arpa
>Date: 26 Jul 89 19:54:58 GMT
>From: pacbell!hoptoad!gnu@ames.arc.nasa.gov  (John Gilmore)
>Organization: Grasshopper Group in San Francisco

>I think that *responsibility* for security should still rest on the
>individual hosts and networks.  However, there should be public *testing*
>of security by any interested parties, in the spirit of fire drills.
>
>Responsibility for security should remain decentralized because one
>model is not appropriate for all sites.  A central bureacracy will not
>have experts in each type of machine on the Internet.  And central rules
>will necessarily be compromises -- too loose for some sites, too strict
>for others.

	I basically agree, but not for the same reasons.  I believe
	that with the scale of the network, it would be virtually
	impossible for any specific organization to be responsible for
	security at every attached site.  How would they guarantee
	that all the users who had access to the net were trustworthy?
	How would they guarantee that no one from some other place
	would make an attempt against you?  About all they could do
	would be to lay out rules, and provide means of prosecution
	if someone was caught.  Security people are really starting
	to believe that there is NO absolute security, the potential
	for a Mr. Morris will always exist even with all innovations
	that may take place.  The best security is close monitoring
	of individual systems by qualified administrators, which is
	what nailed him anyways.  A centralized authority cannot
	provide this. I suspect that the sites that were hit the
	hardest were the ones left unattended.

>The key to making decentral security work is public testing.  On the
>third Tuesday of each month, say, it's open season on breaking into
>other peoples' machines over the Internet -- IF you provide a
>transcript of your actions afterward.  Organizations with particular
>security concerns can fund people to test their own security, or can
>swap with another organization and test each others' security.  DARPA
>and NSF can fund a few people to do more widespread "scattergun"
>testing.  And there will always be plenty of volunteers because people
>like to solve puzzles.
>
>The key is to make this a regularly scheduled, publicly sanctioned
>event.  You could even award prizes, as in the computer Go tournaments
>or the Obfuscated C contest -- highest volume of systems cracked, most
>obscure hole found, hardest to fix problem, least visible intrusion,
>etc.  These could even carry cash prizes -- if you break into a NASA
>computer during such a fire drill, and document your breakin, we'll pay
>you $1000.  This would fund the best crackers so they could afford to
>continue providing high quality testing.  Entire classes of
>undergraduates and grad students could do security testing projects,
>using the Internet as their testbed.  This would educate lots of folks
>about how to provide good security, and make the Internet the most
>secure network, by constantly testing and fixing its security.
>
>Of course, people who didn't *want* to fix their security could just
>drop off the net one Tuesday a month.  But public disclosure of the holes
>found in other systems would make their systems more vulnerable the
>rest of the time, and they would have strong incentive to either clean
>up their security, or drop off the Internet.  In either case the Internet
>is left more secure.

	Somehow this sounds a bit...  well I would probably offend the
	author.  I strongly disagree.  It is implied that your childish
	if you don't agree to testing... As if you KNOW that your system
	can't stand up to a check.  Bad attitude.  I would have to drop
	my system off the net, 'cause while I have no classified material
	on-line, there is stuff of very confidential nature (as many
	systems have). While I have to take the risk of an occasional
	breach attempt by someone working outside the boundaries of the
	law, I cannot risk a concerted effort by *legitimate* people.

	If security is in question for various operating systems, then
	my suggestion is to set up specific centers of operations with
	such systems.  Then anybody who wishes may make attempts against
	these computers.  Obviously not everyone out there has the funds
	to set up computers just for testing, but perhaps the network
	as a whole can find the means to cooperate.

>There seems to be a meme loose today that wants to criminalize all sorts
>of activities -- that views making something illegal a "fix" for the problems
>it presents.  But the problems persist regardless of what the laws say.
>I think something closer to a "fix" would be to bring the activity out
>of the underground and diffuse it through society, in a cooperative rather
>than combative situation.

	Just the effect of a society where many people believe that making
	a law against a problem makes it go away.  Sort of like taking
	a drug which masks the symptoms... because they are gone the disease
	must be cured, right?

Joel Mussman
-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 03:18:47 GMT
From:      ittai@SHEMESH.GBA.NYU.EDU (Ittai Hershman)
To:        comp.protocols.tcp-ip
Subject:   libc_resolv.so for Sun-386i

As many of you know, Sun has been very cooperative in releasing
versions of libc which call bind/named directly, as opposed to via the
yellow pages host lookup mechanism.  Unfortunately, this software is
not currently available for the 386i architecture.

With the cooperation of some helpful tech support engineers, a Request
For Enhancement (RFE# 1024808) has been filed, to have a 386i version
compiled and placed on uunet.

Sun is obviously doing a lot of work these days, and your help is
needed to let Sun know how important this is to its customers.  If you
have a 386i, and require direct bind/named support, please log a
service call with Sun refering to RFE# 1024808.  Also, please drop me
a note (to: ittai@nyu.edu) so that I can track the demand myself...

>From previous dicussions on both TCP-IP and SUN-SPOTS, I know this is
important to others; please speak up (and no flaming please!).

-Ittai

-------

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Jul 89 07:58:42 EDT
From:      snorthc@relay.nswc.navy.mil
To:        pacbell!hoptoad!gnu@ames.arc.nasa.gov, tcp-ip@sri-nic.arpa
Cc:        rlearn
Subject:   Re:  Prosecution in the Internet Worm case

<GAO/IMTEC-89-57 report:
<>                                                        As of
<> March 23, 1989, there have been no indictments in the Internet
<> virus case.  Because it is an open matter, Justice officials
<> would not provide any specific information about the case.

< Do they plan to leave it "open" until the statute of limitations runs out?

< I don't think Mr. Morris should be left hanging like this.  They have all
< the evidence they are likely to get.  If there is a case, fine, indict the
< guy.  If not, drop it.  The current situation bears no resemblance to
< "Justice".
< -- 
< John Gilmore      {sun,pacbell,uunet,pyramid}!hoptoad!gnu      gnu@toad.com

Washington Post A20 Computer 'Virus' Creator Indicted

A federal grand jury indicted Robert Tappan Morris, 24, of Arnold, Md.,
on a "felony charge for creating a rogue computer 'virus' that paralysed
as many as 6,000 computers last November."

"	Morris is the first person charged under the computer-crime
provision of the Computer Fraud and Abuse Acr of 1986, according
to the Justice Department.  If convicted, he could face a five-year
sentence and a $250,000 fine."

	respectfully, stephen northcutt

"As you wish, so be it" The Traveler In Black

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 06:46:16 GMT
From:      tli@sargas.usc.edu (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Worm report fails to address the problem

In article <8136@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
    ...
    and CERT seems to be following the NSA model (all information flows
    inward).
    
I think that this is most unfair, especially in light of the message
which was sent to the sun-managers list today.

Tony Li - USC University Computing Services
Internet: tli@usc.edu	Uucp: usc!tli	Bitnet: tli@gamera, tli@ramoth
This is a test.  This is a only a test.  In the event of a real life
you would have been given instructions.

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 09:25:14 GMT
From:      ulfis@nada.kth.se (Anders Ulfheden)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip.ibmpc
Subject:   Advice needed about net programs and configuration


Hi net!

We have a PC network (thin ethernet) containing two 3Com AT-servers equipped
with 3+Share (version 1.3.1) and workstations with Etherlink Plus (a few
with Etherlink II) cards.

We have bought a VAXStation 3100 with DeskTopVMS. We now want to:

	1) Transfer files between the VAXStation, PC workstations and
	   3Com fileservers.

	2) Use the VAXstation as a fileserver.

	3) From the VAXstation use resources (printer, disk and tape-backup)
	   at the 3Com servers.

	4) Connect the PC workstations to the VAXstation as a terminal via
	   Ethernet (not via serial port).

We already know that TCP/IP is the right protocol to use, but among all
the possible programs to use, you easily get confused.

 +-------------------------------------------------------------------+
 |  What programs are needed on the PC-side and on the VAXstation??  |
 +-------------------------------------------------------------------+

Any advice is appreciated!

Please use mail and I'll summarize to the net.

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 09:27:19 GMT
From:      ulfis@nada.kth.se (Anders Ulfheden)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Advice needed about net programs and configuration

In article <1345@draken.nada.kth.se> ulfis@nada.kth.se (Anders Ulfheden) write:
>
>Hi net!
>
>We have a PC network (thin ethernet) containing two 3Com AT-servers equipped
>
>Please use mail and I'll summarize to the net.

Sorry, I forgot my .signature...
+------------------------------------------------------------------------------
|  Anders Ulfheden
|  USENET:  ulfis@nada.kth.se
|  Royal Institute of Technology
|  Stockholm, Sweden

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 10:42:25 GMT
From:      jos@idca.tds.PHILIPS.nl (Jos Vos)
To:        comp.protocols.tcp-ip
Subject:   Re: class b IP addresses

In article <1081@vax1.tcd.ie> doherty@vax1.tcd.ie writes:

>I wish to apply for a class B IP address for the
>University of Dublin, Ireland.
 
>Can anyone tell me how I go about this please.
>I have been given a number of e-mail addresses
>by local sources but they have not been correct.

This one is correct (proof: I used it less than a month ago):

	hostmaster@sri-nic.arpa

Hope this succeeds.

-- 
-- ######   Jos Vos   ######   Internet   jos@idca.tds.philips.nl   ######
-- ######             ######   UUCP         ...!mcvax!philapd!jos   ######

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 11:58:42 GMT
From:      snorthc@RELAY.NSWC.NAVY.MIL
To:        comp.protocols.tcp-ip
Subject:   Re:  Prosecution in the Internet Worm case


<GAO/IMTEC-89-57 report:
<>                                                        As of
<> March 23, 1989, there have been no indictments in the Internet
<> virus case.  Because it is an open matter, Justice officials
<> would not provide any specific information about the case.

< Do they plan to leave it "open" until the statute of limitations runs out?

< I don't think Mr. Morris should be left hanging like this.  They have all
< the evidence they are likely to get.  If there is a case, fine, indict the
< guy.  If not, drop it.  The current situation bears no resemblance to
< "Justice".
< -- 
< John Gilmore      {sun,pacbell,uunet,pyramid}!hoptoad!gnu      gnu@toad.com

Washington Post A20 Computer 'Virus' Creator Indicted

A federal grand jury indicted Robert Tappan Morris, 24, of Arnold, Md.,
on a "felony charge for creating a rogue computer 'virus' that paralysed
as many as 6,000 computers last November."

"	Morris is the first person charged under the computer-crime
provision of the Computer Fraud and Abuse Acr of 1986, according
to the Justice Department.  If convicted, he could face a five-year
sentence and a $250,000 fine."

	respectfully, stephen northcutt

"As you wish, so be it" The Traveler In Black

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 12:21:28 GMT
From:      scs@itivax.iti.org (Steve C. Simmons)
To:        comp.protocols.tcp-ip
Subject:   Re: Worm report fails to address the problem

gnu@hoptoad.uucp (John Gilmore) writes:

>I think that *responsibility* for security should still rest on the
>individual hosts and networks.  However, there should be public *testing*
>of security by any interested parties, in the spirit of fire drills.
 
>The key to making decentral security work is public testing.  On the
>third Tuesday of each month, say, it's open season on breaking into
>other peoples' machines over the Internet -- IF you provide a
>transcript of your actions afterward. . . .

While I agree with John that testing is key, this is the wrong way to
go about it.  Several times I've made deals with other sysadms to crack
each others systems, but this is a far cry from 'open season'.  Testing
should be private and controlled.  What should be open in the immediate
dissemination of how to close any holes opened.

Many shops (not naming any names here) have implicitly or explicitly
decided not to beef up security -- they may feel it isn't worth the effort
or have decided to trust the Internet community.  Whether you agree or
disagree with this is irrelevant.  Declaring 'open season' on them will
likely cause them to get angry and perhaps stimulate the same repressive
legislation and central beaurocracy you oppose.
season' will cause these shops a great deal of distree
-- 
Steve Simmons		          scs@vax3.iti.org
Industrial Technology Institute     Ann Arbor, MI.
"Velveeta -- the Spam of Cheeses!" -- Uncle Bonsai

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 12:33:34 GMT
From:      malis@BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: Prosecution in the Internet Worm case

> I don't think Mr. Morris should be left hanging like this.

Yesterday, Mr. Morris received a federal indictment.  He faces up
to 5 years in jail and/or a $250,000 fine.

Andy

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 12:38:32 GMT
From:      set@calvin
To:        comp.protocols.tcp-ip
Subject:   BOOTP through gateways


I have a question regarding using the BOOTP protocol through gateways.  I'm
working on a "factory-floor" device which uses BOOTP and TFTP to load itself
much like a diskless workstation.  Currently I use 255.255.255.255 as the
IP destination address for the BOOTP request, as required by the spec.
255.255.255.255 will not be passed-through by any gateways, so booting from
a server not on the local wire requires cooperation by a BOOTP-knowledgeable
gateway.  So here's my questions:

1. Is booting through a gateway a typical or useful capability?  I have little
   (ok, zero) network management experience, but if the feature isn't that
   useful, then I'm done now!

2. How common is it for a gateway to provide BOOTP support?  If typical gateways
   do not support BOOTP, I guess I'll need to implement a "proxy".  Are there
   any public domain "proxy" programs?  (I hate to reinvent)

3. Instead of gateway support or a "proxy", would it be desireable for the
   device to perform an expanding search?  For instance, uses 255.255.255.255
   to search the local wire.  If no response, use ICMP to get the subnet mask
   and broadcast to the local subnet.  If still no response, broadcast to the
   entire local net.  (too much broadcast traffic?)

I'd appreciate any comments you might have.

-----------------------------------------------------------------------------
Scott Townsend			   ...!{cwjcc,decvax,pyramid,uunet}!abvax!set
Polymath Corporation, currently working for (but not representing)
Allen-Bradley Company 747 Alpha Dr. Highland Hts. OH 44143 USA (216) 646-5233

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 14:12:40 GMT
From:      sharon@asylum.SF.CA.US (Sharon Fisher)
To:        comp.protocols.tcp-ip,misc.legal
Subject:   Re: Prosecution in the Internet Worm case

In article <8137@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>GAO/IMTEC-89-57 report:
>>                                                        As of
>> March 23, 1989, there have been no indictments in the Internet
>> virus case.  Because it is an open matter, Justice officials
>> would not provide any specific information about the case.
>
>Do they plan to leave it "open" until the statute of limitations runs out?
>
>I don't think Mr. Morris should be left hanging like this.  They have all
>the evidence they are likely to get.  If there is a case, fine, indict the
>guy.  If not, drop it.  The current situation bears no resemblance to
>"Justice".



It's moot -- they indicted him yesterday on two counts.



-- 
"Inanna spoke:
	My vulva, the horn, the Boat of Heaven, is full of eagerness like 
the young moon. My untilled land lies fallow.  As for me, Inanna, who will 
plow my vulva? Who will plow my high field? Who will plow my wet ground?"
					Inanna: Queen of Heaven and Earth
					Her Stories and Hymns from Sumer

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 14:55:51 GMT
From:      rcl@cunixc.cc.columbia.edu (Robert C Lehman)
To:        comp.protocols.tcp-ip,misc.legal
Subject:   Re: Prosecution in the Internet Worm case

An item in the newspaper today says that Robert T. Morris has been
indicted by a federal grand jury and is being charged under the
"computer crime provision of the Computer Fraud and Abuse Act of
1986."  The story goes on to say that the maximum penalties are five
years in jail and a $250,000 fine. (Source: New York Newsday,
7/27/89).

-Rob

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 15:09:33 GMT
From:      waugh@dg-rtp.dg.com (Matthew Waugh)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet 'null transceiver'?

>rdn@chinet.chi.il.us (Richard Nichols) writes:
>>We have a need to connect two machines together that have thick-wire
>>ETHERNET connections.  Since there are only two machines in this 'network' I
>>was wondering if there is such a thing as a 'null transceiver'?  In other
>>
>>Rick Nichols
>>rdn@chinet.chi.il.us

Allied Telesis makes a two port Transceiver named the CentreCOM 250. Two
terminators and a couple of drop cables should see you in business. Off
hand I don't have a price, but if anyone is interested drop me mail
and I can find out from our last set of purchases. We have used them, and
they do work (although we haven't used them as "null transceivers".

Mat

------------------------------------------------------------------------
Matthew Waugh			waugh@rtp.dg.com
RTP Network Services 		{world}!mcnc!rti!dg-rtp!waugh
Data General Corp.		
RTP, NC. (919)-248-6034

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 15:31:05 GMT
From:      hes@ncsuvx.ncsu.edu (Henry E. Schaffer)
To:        comp.protocols.tcp-ip,misc.legal
Subject:   Re: Prosecution in the Internet Worm case

In article <8137@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
  ... [re: Internet worm case]
>Do they plan to leave it "open" until the statute of limitations runs out?

  I heard on NPR last night that the grand jury (in Syracuse, NY?) had
just concluded after some months of hearings and recommended (is that what
they do) that a crime had been committed and that the prosecution is
going to ask the court for an indictment.  So it does sound as if 
something was going on.

  The announcer started out by discussing the effects of the "virus" and
then later said it was a "worm".

>John Gilmore      {sun,pacbell,uunet,pyramid}!hoptoad!gnu      gnu@toad.com

--henry schaffer

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 15:42:44 GMT
From:      karl@cheops.cis.ohio-state.edu (Karl Kleinpaste)
To:        comp.protocols.tcp-ip
Subject:   Re: Worm report fails to address the problem

I would like to make a small echo of the sentiment to avoid making the
entire Internet into an open hunting ground for any form of attack.
My most visible systems are also the ones which work the hardest, and
they can't _all_ afford a day off each month.

On the other hand, I would be extremely interested if I could offer,
for example, one of my systems (or perhaps one of each type) once a
month as an open-season victim testbed.  If a list of such
available-for-abuse systems could be compiled, we could accomplish the
goals both of having a large pool of available victims and keeping the
bulk of the Internet still operating sanely even during such abusive
testing.

Would anyone care to register ABUSE.NET, containing nothing but CNAMEs
for available systems?  Anyone wanting to test could set their system
up as a secondary server, thus giving them a dump of the available
masochists.

Just a thought,
--Karl

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 16:26:54 GMT
From:      jbw@eyebeam.UUCP (Jeremy B. Wohlblatt)
To:        comp.protocols.tcp-ip,misc.legal
Subject:   Re: Prosecution in the Internet Worm case

gnu@hoptoad.uucp (John Gilmore) writes:
>GAO/IMTEC-89-57 report:
>>                                                        As of
>> March 23, 1989, there have been no indictments in the Internet
>> virus case.  Because it is an open matter, Justice officials
>> would not provide any specific information about the case.
 
>Do they plan to leave it "open" until the statute of limitations runs out?
>I don't think Mr. Morris should be left hanging like this.  They have all
>the evidence they are likely to get.  If there is a case, fine, indict the
>guy.  If not, drop it.  The current situation bears no resemblance to
>"Justice".

preparing an indictment takes time, particularly in a case like this one.
but relax, i heard on n.p.r. that they indicted morris earlier this week for
gaining unauthorized access to certain computer facilities and preventing the
authorized use of those facilities.

					-- jeremy
these opinions might not be those of my employer.  they might not even be mine.
jeremy b. wohlblatt: samsung software america, inc.
	uucp: {decvax!{gsg,cg-atla},uunet,ulowell}!ginosko!jbw
	internet:	jbw@ginosko.samsung.com

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 16:34:06 GMT
From:      gors@well.UUCP (Gordon Stewart)
To:        comp.protocols.tcp-ip,misc.legal
Subject:   Re: Prosecution in the Internet Worm case


[excerpted from NY TIMES NATIONAL Edition - July 27, 1989]

STUDENT, AFTER DELAY, IS CHARGED IN CRIPPLING OF COMPUTER NETWORK

After more than eight months... the Justice Dept. said that a Federal
Grand Jury in Syracuse had indicted the 24-Year old Cornell U. graduate
student ... Robert Tappan Morris ... 

[He] was charged with a single felony count under a 1986 computer crimes
law, the Computer Fraud and Abuse Act.  This law makes it illegal to gain
unauthorized access to Federal computers. ... Under the law, authorities
must show that Morris intended to cripple the computer network.

...

The incident has ... bitterly divided computer scientists and computer
security experts around the country.  Some have said that they believe
"an example" should be made of Mr. Morris to discourage future tampering.
Others, however, have argued that Mr. Morris performed a valuable service
by alerting the nation to the laxity of computer security controls.

[By John Markoff -- Special to the NY Times]


_________________________________________________________________________

I wish Mr. Morris well -- I subscribe to the notion that a breach of
etiquette was committed, not a breach of security.  Lock your car,
take your keys...  I suppose he's had a major lesson in the possible
far-reaching consequences from such a prank -- although the lesson
isn't over, the burden of proving that he INTENDED to cause harm is
probably too great for the Justice Dept. to carry off.

-- 
				{apple, pacbell, hplabs, ucbvax}!well!gors
							gors@well.sf.ca.us
(Doolan) | (Meyer) | (Sierchio) | (Stewart)

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 19:26:23 GMT
From:      DSTEVENS@DSRM12.STEVENS-TECH.EDU (David L. Stevens)
To:        comp.protocols.tcp-ip
Subject:   RE: RE: Worm report fails to address the problem


   
In Message  <8136@hoptoad.uucp> John Gilmore
<pacbell!hptoad!gnu@ames.arc.nasa.gov> writes:

> I found the OTA worm report to not be very helpful.
>      
> It recommends central control of Internet security.  Of course, this is
> what a government would tend to recommend -- centralization of authority.

    However, without some form of central authority you end up with anarchy,
    and you need someone with sufficient clout to punish people who violate
    security.

    [intervening text omited]

> I think that *responsibility* for security should still rest on the
> individual hosts and networks.  However, there should be public *testing*
> of security by any interested parties, in the spirit of fire drills.
>      
> Responsibility for security should remain decentralized because one
> model is not appropriate for all sites.  A central bureacracy will not
> have experts in each type of machine on the Internet.  And central rules
> will necessarily be compromises -- too loose for some sites, too strict
> for others.
>      
> The key to making decentral security work is public testing.  On the
> third Tuesday of each month, say, it's open season on breaking into
> other peoples' machines over the Internet -- IF you provide a
> transcript of your actions afterward.  Organizations with particular

    Thats a mighty big IF.  Declaring a day as open season to break into
    any system on the network is like declaring a day as open season to
    break into any bank in the country.  So what if you leave a transcript
    saying that you got in by breaking the window,  whos going to pay for the
    window afterwards???????

> security concerns can fund people to test their own security, or can
> swap with another organization and test each others' security.  DARPA
> and NSF can fund a few people to do more widespread "scattergun"
> testing.  And there will always be plenty of volunteers because people
> like to solve puzzles.

    If you make arangements with someone to specifically attempt to break
    into your system, thats fine, at least you'll know whos doing what.  But
    to allow any random Schmoe on the network to try and break in leaves no
    accountability.  How would you be able to tell a "helpful" cracker, if
    there is such a beast, from a "harmful" cracker????????

> The key is to make this a regularly scheduled, publicly sanctioned
> event.  You could even award prizes, as in the computer Go tournaments
> or the Obfuscated C contest -- highest volume of systems cracked, most
> obscure hole found, hardest to fix problem, least visible intrusion,
> etc.  These could even carry cash prizes -- if you break into a NASA
> computer during such a fire drill, and document your breakin, we'll pay
> you $1000.  This would fund the best crackers so they could afford to
> continue providing high quality testing.  Entire classes of
> undergraduates and grad students could do security testing projects,
> using the Internet as their testbed.  This would educate lots of folks
> about how to provide good security, and make the Internet the most
> secure network, by constantly testing and fixing its security.

    Undergraduates, and Graduates already try to break into systems either
    on their campus or off on networks, the last thing College Comp Center
    staffs need to deal with is encouragement, especially monetary, for them
    to continue!!!!!!!!!!!!!!

> Of course, people who didn't *want* to fix their security could just
> drop off the net one Tuesday a month.  But public disclosure of the holes
> found in other systems would make their systems more vulnerable the
> rest of the time, and they would have strong incentive to either clean
> up their security, or drop off the Internet.  In either case the Internet
> is left more secure.

    What about those of us who just don't like the idea of people trying to
    break into our systems???  You're taking away an important research
    resourse so that people can burn bandwidth trying to break into places
    where they don't belong.

> The only way I can see to keep the Internet secure is "eternal vigilance".

    Eternal vigilance is whats needed in order to keep systems secure.  But
    we need laws so that we can punish people who violate our security, and
    break into, or contaminate our systems.

> A central security bureau will not be eternally vigilant -- it will become
> bureaucratic and lazy.  And it will have no incentive to reveal what it
> has learned about security, except to small numbers of people (e.g. the

    [ rest of text omitted ]

> --
> John Gilmore      {sun,pacbell,uunet,pyramid}!hoptoad!gnu      gnu@toad.com
>       "And if there's danger don't you try to overlook it,
>        Because you knew the job was dangerous when you took it"
> ------------
> 


===============================================================================
|                                  |                                          |
| David L. Stevens                 | CCnet:    SITVXC::DSTEVENS               |
| Senior Systems Programmer        | BITnet:   DSTEVENS@STEVENS               |
| Stevens Institute of Technology  | INTERnet: DSTEVENS@VAXC.STEVENS-TECH.EDU |
|                                  |                                          |
===============================================================================
[ ...self realization, I was thinking of those immortal words of Socrates     ]
[    when he said: 'I drank what ?'     -   Val Kilmer  -  Real Genius        ]
------------

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 19:49:28 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP performance


Since there has been substantial traffic to the ttcp.c I offered for
anonymous ftp, here is a script for running ttcp.  I'm told that one does
something like "script 1" on the receiver and "script 1 rcvr" on the
sender.  One should first turn off all deamons, including YP, routed,
gated, etc. and shut off the window system--provided that you want to
measure pure, maximum TCP or UDP.  The effect of these other things on the
numbers is very interesting, but not obviously relevant in this forum.


 ----------------
#!/bin/csh -f

set udp=""
#set udp="-u"

set lengths=(0005 0128 0256 0512 1024 1536 2048 3072 3584 4096 5120 5400 6144 7168 8192)

set numBufs=25000
if ("$2" == "") then
    set op=r
#    if (-e Count) then
#	@ run=`cat Count`
#	@ run++
#	echo $run >! Count
#    else
#	echo 1 > Count
#	@ run = 1
#    endif
else
    set op=t
#    @ run = `cat Count`
endif
set run = $1
@ port = 4000 + $run * 100
echo "Starting $udp run $run"
set output=$op$run
cp /dev/null $output
foreach buflen ($lengths)
    echo "$buflen, port = $port"
    if ($op == t) then
	echo "" >> $output
	./ttcp -t $udp -p$port -n$numBufs -l$buflen $2 >> $output
	sleep 2
    else
	echo "" >> $output
	./ttcp -r $udp -p$port -n$numBufs -l8192 >> $output
	sleep 1
    endif
    @ port++
end


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

Someone ambitious should enhance ttcp to take a list of buffer sizes and
numbers of passes for each size, and compute means.  It would also be
better if it took a buffer size & a total transmission size, and divided
to compute the number of buffers to write.

It would be nice to find a public domain package to generate a postscript
plot of the results.  The hills and valleys give insites into buffering
problems and successes.  If the numbers are good, it also makes good sales
fodder.  We use something internally, but it turns out to be private
property.


Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 20:17:38 GMT
From:      greg@bilbo (Greg Wageman)
To:        comp.protocols.tcp-ip,misc.legal
Subject:   Re: Prosecution in the Internet Worm case

In article <8137@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>GAO/IMTEC-89-57 report:
>>                                                        As of
>> March 23, 1989, there have been no indictments in the Internet
>> virus case.  Because it is an open matter, Justice officials
>> would not provide any specific information about the case.
>
>Do they plan to leave it "open" until the statute of limitations runs out?

I hear on NPR yesterday that he has been indicted.  Should be an
interesting case.



Longish .signature follows.  Skip now.
 
Greg Wageman			DOMAIN: greg@sj.ate.slb.com
Schlumberger Technologies	UUCP:   ...!uunet!sjsca4!greg
1601 Technology Drive		BIX:    gwage
San Jose, CA 95110-1397		CIS:    74016,352
(408) 437-5198			GEnie:  G.WAGEMAN
------------------
"Live Free; Die Anyway."
------------------
Opinions expressed herein are solely the responsibility of the author.

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 21:33:55 GMT
From:      brent@capmkt.COM (Brent Chapman)
To:        comp.protocols.tcp-ip
Subject:   Re: Worm report fails to address the problem

tli@sargas.usc.edu (Tony Li) writes:

>In article <8136@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>    ...
>    and CERT seems to be following the NSA model (all information flows
>    inward).
>    
>I think that this is most unfair, especially in light of the message
>which was sent to the sun-managers list today.

Yes, they finally sent it out.  I was informed of it (through other
channels) and fixed it on my systems over a month ago.  I'm not particularly
well-connected in the security community; CERT must surely have learned of
the problem before I did.  Why did they take so long to get the word out?
Does CERT have a formal policy of sitting on a security problem for some
period of time before releasing it to the "general public"?  What _is_
CERT's charter and policy?

Before anyone starts flaming here, note that I'm not criticizing CERT (yet);
I don't know enough about them.  I'm asking for information about them,
so that I can form an informed opinion about them.


-Brent
--
Brent Chapman					Capital Market Technology, Inc.
Computer Operations Manager			1995 University Ave., Suite 390
brent@capmkt.com				Berkeley, CA  94704
{apple,lll-tis,uunet}!capmkt!brent		Phone:  415/540-6400

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 89 22:37:45 GMT
From:      hkhenson@cup.portal.com (H Keith Henson)
To:        comp.protocols.tcp-ip,misc.legal
Subject:   Re: Prosecution in the Internet Worm case

John Gilmore (in ref to the internet worm case) wrote:

>Do they plan to leave it "open" until the statute of limitations runs out?

Guess not, I heard this AM that Mr. Morris was indicted.  His
response was that he would fight the charges.  Keith Henson

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      THURSDAY, JULY 27, 1989      23:18  CET
From:      236%DB0TUZ01.BITNET@CUNYVM.CUNY.EDU
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Western Digital 8003 family

Hi,

     I have some minor questions according to the Western Digital
8003 family.

WD8003E - XT-Bus-Ethernet-Adaptor:
This member of the family we use under MS-DOS with NCSA-Telnet,
PC/IP (FTP) and PC-NFS (Sun) and under 386/ix with Interactive's
TCP/IP, NFS and X-windows. This works fine.

WD8003S -XT-Bus-Starlan-Adaptor:

The same PC/IP version works, but NCSA-Telnet 2.2D does not. The
386/ix-stuff does not work, too. PC-NFS we did not try until now.

WD8003E -microchannnel-Ethernet-Adaptor: ( /2 -> 2nd class ?)

Our first experiment was to test NCSA-Telnet 2.2D. It failed. WD's
diagnostics say that the adaptor work fine. Somewhat disappointed
we did not try the other packages because they did not explicitly
mention the microchannel version of the adaptor.

Some time ago I've heard WD's 8003-family would be register-compatible
on every board. But with the above told experience my thoughts went to
George Orwell: All registers are equal. But some are more equal.

So, what did I wrong? Are there any known bugs in the software or in
the boards? How can I solve my problems?

Any answers, comments and solutions are greatly appreciated.

Wolfgang Ksoll
Techn. Univ. Berlin (West), Germany
Computer Center
     BITNET:    236@db0tuz01
From Internet:  236@db0tuz01.bitnet
From uucp:      {...}!unido!db0tuz01.bitnet!236

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 89 00:24:06 GMT
From:      wclx@vax5.CIT.CORNELL.EDU
To:        comp.protocols.tcp-ip,misc.legal
Subject:   Re: Prosecution in the Internet Worm case

In article <8137@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>GAO/IMTEC-89-57 report:
>> As of
>> March 23, 1989, there have been no indictments in the Internet
>> virus case.  Because it is an open matter, Justice officials
>> would not provide any specific information about the case.
>
>Do they plan to leave it "open" until the statute of limitations runs out?
>
>I don't think Mr. Morris should be left hanging like this.  They have all
>the evidence they are likely to get.  If there is a case, fine, indict the
>guy.

It looks like you just got your wish!


From the ITHACA JOURNAL (Ithaca, NY), Thursday, July 27, 1989, page 1:


CU student indicted in 'worm' case
By John Yaukey, Journal Staff

     Cornell University graduate student Robert Morris Jr. faces a
felony charge for allegedly creating a renegade computer program
that brought down thousands of computers nationwide last November.

     Morris was indicted on a charge of "gaining unauthorized access
to computers around the country, preventing authorized access to
these computers and causing losses in excess of $1,000," according
to a statement from the U.S. attorney for the Northern District of
New York.

     The indictment, handed up by a federal grand jury in Syracuse,
was announced Wednesday.

     If convicted, the 24-year-old graduate student could be
imprisoned for five years and fined $250,000, according to a
statement from the U.S. attorney's office.

     "Mr. Morris will enter a plea of not guilty," his Washington-
based attorney, Thomas Guidoboni, said in a telephone interview
Wednesday.  "He looks forward to eventual vindication and his
return to a normal life."

     Morris is expected to be arraigned in Syracuse sometime next
week, Guidoboni said.

     The federal attornet's office in Syracuse would not say when
he would be arraigned.

     The indictment against Morris comes about eight months after
the destructive program called a "worm" was released.

     U.S. Attorney Andrew Baxter said the grand jury was waiting
on a decision by the U.S. Justice Department before a ruling
could be made.  Baxter never elaborated on what the justice
department was weighing during those eight months.

     Cornell officials have refused to comment on the charge in
any way.

     In early April, the university issued a report that said
Morris created a computer "worm" and that he apparently acted
alone in doing it.

     The report also noted that disciplinary measures "should
allow for redemption" and should not be so harsh as to be
permanently damaging.  It also said that nobody of authority at
Cornell was involved in creating or releasing the worm.

     In early November, Morris is alleged to have created and
released a "worm," a program that electronically mailed itself from
computer to computer.

     As the worm, first called a virus, infiltrated the machines,
it filled them with bogus files, bled them of power and brought
them down.

     The worm reportedly made its way through some 6,000 defense,
industry and academic computers, but did not destroy any information.

     Some of the computers that the worm made its way to include
those at the University of California at Berkeley, the National
Aeronautics and Space Administration at Moffett Field, Calif., Purdue
University in West Lafayette, Ind. and the Cornell National
Supercomputing Facility.

     Estimates of the damage caused by the worm vary.

     Damage and cleanup costs were reported as high as $96 million,
but members of the Cornell team assembled to investigate the worm
said that was "grossly exaggerated."

     Morris was reported to be living in the Washington, D.C., area,
though his attorney said he no longer is there.  Guidoboni would not
reveal where Morris had moved.

     When asked about Morris' status at Cornell, officials there
acknowledge only that he requested and received a leave of absence
effective Dec. 1, 1988.

     Morris' attorney has said he has been suspended from Cornell

----------------(End of article)---------------------------

Lawrence Kestenbaum, wclx@vax5.cit.cornell.edu
506 S. Albany St., Ithaca NY 14850
"In the long run, the preservationists are always right." -J. K. Galbraith

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 89 00:28:23 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Prosecution in the Internet Worm case

The NY Times reported that one factor that delayed the indictment was
that the statute requires demonstration of intent.  Reportedly, the
grand jury and the local D.A. weren't certain they could prove intent,
and hence wanted to offer Morris a plea bargain to a misdemeanor.
The Justice Department wanted none of that, ostensibly to demonstrate
that they're serious about hacking.

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 89 02:21:12 GMT
From:      sra@lcs.mit.edu (Rob Austein)
To:        comp.protocols.tcp-ip,misc.legal
Subject:   Re: Prosecution in the Internet Worm case

In article <19157@vax5.CIT.CORNELL.EDU> wclx@vax5.CIT.CORNELL.EDU writes:

   From the ITHACA JOURNAL (Ithaca, NY), Thursday, July 27, 1989, page 1:

   ... As the worm, first called a virus, infiltrated the machines,
   it filled them with bogus files, bled them of power and brought
   them down.

Moral: Don't let your computer finger its power supply.

--Rob

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 89 09:11:36 GMT
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   the worm and internet security

I agree and I disagree. Mostly agree, and wish to agree more.

Yeah, there're a lot of problems left and the government agencies are
*not* being useful. I think that centralized administration of the
Internet is absolutely the wrong thing, and that government
administration would be a disaster.

On the other hand, I'm scared of throwing open the whole Internet for
security testing. The Internet Engineering Task Force met this week at
Stanford. According to the NIC, an automated survey of the domain
system returned more than 118,000 host names, and several major sites,
such as Stanford and CMU, didn't return any data. Probably a better
estimate of the number of hosts on the Internet is 150,000 [my
opinion]. Right now I just don't think the system is good enough to
be able to coordinate that many systems. I mean, we can't even get a
lot of system maintainers to install the latest version of sendmail.
I'm afraid that declaring next Tuesday open season on the Internet
would cause utter chaos. 

I don't think this is a *good* state to be in, mind you. Just that
this is where we are now, and I can't change the state of the world
overnight. Maybe periodically declaring open season for a day would
help the world grow up faster, but I afraid it might only hinder the
growth and get the government involved more, and that, I really don't
want.

Some people are recognizing the need for testing. The IAB is pushing
to get funding for the "Internet testbed" where they can have an
Internet in miniature and do this kind of testing. Some statements
from them today made that concern pretty clear. God, this paragraph
sounds like politicalese. Anyway, I don't know if they'll really do
it. I don't know if it'll really be effective. But they do seem to be
pushing for it, and I'd feel a lot more comfortable about doing the
testing in a smaller, more controlled environment.

There's some senator who's trying to introduce legislation that would
make it illegal to write a worm or virus. I think worms could actually
be very interesting for doing certain kinds of distributed computation
or network management.

I also think more vendor responsibility would go a long way. Some of
the problems that the worm took advantage of were well known. Sun and
DEC shouldn't have released sendmail with debug mode left in. An awful
lot of vendors pick up 4.x TCP, get it running on their system, and
never really understand what's in it. I do not blame Berkeley for
this.

And I don't know how much security is enough. I don't tend to like
much at all, myself. At some point to gain the security, you'll have
to start making some really big changes. If you want real security,
you'll end up not sending passwords and userid's in plain text over
telnet and rlogin. You'll probably end up with link encryption, and
even stronger authentication than what MIT is doing with Kerberos. And
those are pretty big changes to the way things are done now. It's
going to take a while, and still won't cope with the kind of hardcore
password cracking you can attempt when you've got a 1Mbit/s channel
into my computer instead of a 1200 baud dialin, and can finger @asylum
to find out user names...it's not the network that's insecure there,
it's just that the existence of the connection makes it easier to
exploit (what didn't used to be) "weaknesses" in the existing
operating system.

These issues give me headaches. Yes, I wish we could do open testing
all over the Internet. We could test security; we could also take pot
shots with finger of death packets to find old releases of software
that are running on systems and encourage their administrators to run
up to date stuff. And more. I don't think it's practical in the
current environment, but I do think it is important, regardless.
				- john

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 89 12:49:34 GMT
From:      gregb@dowjone.UUCP (Gregory S. Baber)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.questions
Subject:   help with WANs

I am posting this for a friend. Please direct all mailed responses to:
	uunet!dowjone!georgeh

Thanks,  gregb

  We are looking to implement a WAN over satellite to seven remote sites.
  Each site would have primarily Dec and Sun computers on a single ethernet
  running Decnet and TCP/IP. We have decided that multi-protocol routers in
  a modified star might be the best way to go. Presently we are
  investigating Cisco, Proteon, and Wellfleet routers as a possible
  solution. Our primary requirements are that the routers support at least
  decnet and TCP/IP, handle up to T1 speeds in the future, and handle
  satellite delays and bandwidth efficiently. We presently have decnet 
  routers at several sites so we are also investigating TCP/IP to decnet 
  gateways as an alternative, though with little success.  
 
  Any suggestions for the above scheme, first hand experience, pros and
  cons of specific hardware or alternate solutions would be greatly
  appreciated.  Vendor literature also welcome.

  Thanks, George

-- 
Reply to: Gregory S. Baber		Voice:	(609) 520-5077
   Dow Jones & Co., Inc.		UUCP:	..princeton!dowjone!gregb
   Box 300				or	..uunet!dowjone!gregb
   Princeton, N.J. 08543-0300		"So long, and thanks for all the fish"

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 89 17:37:22 GMT
From:      morrison@accuvax.nwu.edu (Vance Morrison )
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP through gateways


Hello

Doing Bootp through a gateway is a useful thing to have.   We use it here
at NU already and expect to use it more as more diskless devices (terminal
servers, gateways) come on line.  

It sounded like you are dealing with the client code.  If you implement
the client code correctly, IT SHOULD NOT NEED TO BE CHANGED for a boot
though a gateway.  The extra code you need is not client code, it is code
for the proxy (which usually resides in a gateway BUT NEED NOT).  All
major gateway manufactures support this proxy code, or a local host can
run CMU's bootpd to act as a proxy (in which case the gateway is not the
proxy).

I stress that the client code need not be changed because at least one
major manufacture (CICSO) screwed up their BOOTP boot sequence so it will
not work unless you have a CISCO acting as a proxy.  The correct sequence
of events for a proxy is 

	1) Client broadcasts (255.255.255.255) the Bootp request
	2) The proxy picks this up and forwards it (Thus it is assumed
		that the proxy has been configured to forward bootp
		requests to the right place).  The proxy sets
		the gateway field in the BOOTP packet to show that
		this BOOTP request is from a proxy.
	3) The BOOTP packet makes its way though an arbitrary number of
		gateways to get to the BOOTP server.
	4) The server looks up the request and prepares the reply.  Since
		the gateway field is non-zero, the server sends the reply
		back to the proxy (instead of broadcasting on the local net).
	5) The proxy recieves the BOOTP reply, and broadcasts it on the
		correct local net.
	6) The Client recieves the BOOTP info.  It sets its IP address
		AND SUBNET MASK and local gateway from the BOOTP packet
	7) The Client uses TFTP to download the proper file from the server
		SPECIFIED IN THE BOOTP packet.  (It the client could not
		set his subnet mask from the bootp packet, he should send
		this packet to the gateway for forwarding).

    CISCO's make it though step 5 and part of step 6, but instead of using
the information in the BOOTP packet to find the server to TFTP to, it blindly
TFTP's to the broadcast address 255.255.255.255.  Of couse this only works
(and works badly) if the server is on the local net.  


Vance Morrison
Network Adminstrator
Northwestern University

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 89 17:54:43 GMT
From:      curt@dtix.ARPA (Curt Welch)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   "dead ports" on a Bridge LS/1 terminal server

For several months, we have been using a Bridge LS/1 (CS/1) 64 port
TCP/IP terminal server to connect a bank of 48 Bell 212 modems to our
local ethernet.  We have been seeing a recurring problem with "dead"
ports and I would like to know if anybody else has seen this problem,
or if they have tried to use a Bridge LS/1 with dial-in modems.

What we have found, is that every few weeks, a bank of consecutive
ports on the LS/1 will stop working for no apparent reason.  When we
reboot the LS/1, the problem goes away, but nothing else we have tried
seems to clear the condition.

Typically, when a port goes "dead", the terminal server holds DTR high,
so the modem will answer the phone, but the terminal server never
responds with its welcome message and does not echo characters.

I've never seen more than 8 (or less than 4) ports go bad at once, and
the last bad port in the group has always ended on a multiple of 8.  For
example, twice now, we have seen ports 2 through 7 (the first port on
the server is 0) go bad.

Thanks for any help you can give us.

Curt Welch
curt@dtix.arpa
David Taylor Research Center, Bethesda, MD
(202) 227-1428

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 89 18:27:04 GMT
From:      generous@dgis.daitc.mil (Curtis Generous)
To:        comp.protocols.tcp-ip
Subject:   Re: class b IP addresses

jos@idca.tds.PHILIPS.nl (Jos Vos) writes:
>	hostmaster@sri-nic.arpa

After August 6, better to use:

	hostmaster@nic.ddn.mil

SRI-NIC is finally changing to a FQDN (sri-nic.arpa will still work for a while)

--curtis
-- 
Curtis C. Generous
DTIC Special Projects Office (DTIC-SPO)
ARPA: generous@daitc.mil
UUCP: {uunet,vrdxhq,lll-tis}!daitc!generous

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 89 20:55:18 GMT
From:      ml@gandalf.UUCP (Marcus Leech)
To:        comp.protocols.tcp-ip
Subject:   SLIP under CTIX6.1


We're having a problem with TCP/IP under CTIX6.1.  Here's our configuration:


      Machine B <---SLIP----> Machine A
       |                       |  |
       |                       |  |
   [ETHERNET]		[ETHERNET][ETHERNET]

Both machines run ROUTED.  The two ends of the SLIP link have addresses
   134.22.128.1 and 134.22.128.3.  The ETHERNET interfaces on Machine A
   have addresses of 134.22.80.9 and 134.22.32.6. Machine B's ETHERNET
   interface has an address of 134.22.48.1.  All the ETHERNET interfaces
   run with a netmasks of 255.255.240.0 (yielding 16 possible subnets).
   The SLIP links have netmasks of 255.255.0.0. Both systems add routes
   statically at system boot time, so that hosts on any of the ethernets
   can see each other.  This all works swimmingly well for the first
   hour or so after Machine A gets booted.  After about an hour of
   operation, the SLIP link seems to die.  Neither Machine B, nor Machine A
   can see any packets, nor even any packet-errors.  Rebooting machine A
   clears things up--it is never necessary to reboot machine B.  I
   thought of hardware, so I switched SLIP ports (to a different controller)
   and the same thing happens.  The routing information seems to still be
   valid, because when machine A pings machine B, the Opkt count on the
   SLIP interface goes up by an appropriate number.  I'm kinda stumped.
   Anybody got any brilliant ideas?
-Marcus Leech
Gandalf Data Ltd
-- 
"If at first you dont succeed, STOP!"    PaperMail: 130 Colonnade Rd, Nepean,ON
Marcus Leech                             E-mail:     ml@gandalf.UUCP
Gandalf Data Ltd                         PacketRadio: VE3MDL@VE3JF
"The opinions expressed herein are solely my own" So there

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 89 00:34:41 GMT
From:      dan@s3dawn.ARPA (Dan Peterka)
To:        comp.protocols.tcp-ip
Subject:   terminal servers for modems?

Does anyone have a good recommendation for an 8 line or so terminal server
which supports full modem control? We have an Annex II and can't get it to
do hardware flow control to work with a modem. Has anyone else been able to
get UUCP to negotiate an Annex II? 

_______________________________________________________________________________
Dan Peterka                     S-Cubed                      PO Box 1620
dan@scubed.com                  (619) 587-8338               La Jolla, CA 92038
^^^^^^^^^^^^^^ This is the correct net address - ignore the header info.
_______________________________________________________________________________

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 89 01:14:55 GMT
From:      mark@alias.UUCP (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Source for ethernet drivers

I recently picked up Steve Deering's multicast code via a friend with
accesss to the internet. The code included patches for a few ethernet
drivers (if_qe.c, if_ie.c, etc). Are there any public domain versions
of these drivers (and if so, where?). Please respond to myself, as news
tends to propagate very rapidly.

					Thanks,

						Mark

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

	Mark Andrews
	Systems Programmer,
	Alias Research,
	Toronto, Canada
Phone:	(416)-362-9181
UUCP:	mark%alias@csri.utoronto.ca

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 1989 05:18-EDT
From:      CERF@A.ISI.EDU
To:        elbereth.rutgers.edu!hardees.rutgers.edu!patterso@RUTGERS.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Announcing a little board-room shakeup
Ross,

Bob may already have responded (I persist in going through my mail
sequentially), but here is my two cents. The IAB works very closely
with the FRICC which is the government group which sponsors most of
the Internet backbone and deals with international connections to
the Internet. The government supports the IAB and its subsidiary groups,
IETF and IESG, and many of the members of these groups continue to be
supported individually by government research grants and cooperative
agreements. Things haven't really changed all that much from the days
with DARPA sponsored the whole thing - except that in place of DARPA,
the FRICC acts to set government policy and to fund the R&D and
infrastructure work necessary to keep the Internet healthy and
relevant.

Vint Cerf
-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 89 09:18:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Announcing a little board-room shakeup

Ross,

Bob may already have responded (I persist in going through my mail
sequentially), but here is my two cents. The IAB works very closely
with the FRICC which is the government group which sponsors most of
the Internet backbone and deals with international connections to
the Internet. The government supports the IAB and its subsidiary groups,
IETF and IESG, and many of the members of these groups continue to be
supported individually by government research grants and cooperative
agreements. Things haven't really changed all that much from the days
with DARPA sponsored the whole thing - except that in place of DARPA,
the FRICC acts to set government policy and to fund the R&D and
infrastructure work necessary to keep the Internet healthy and
relevant.

Vint Cerf

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 89 17:44:08 GMT
From:      jacob@gore.com (Jacob Gore)
To:        comp.protocols.tcp-ip
Subject:   Re: terminal servers for modems?

/ comp.protocols.tcp-ip / dan@s3dawn.ARPA (Dan Peterka) / Jul 28, 1989 /
We have an Annex II and can't get it to
do hardware flow control to work with a modem. Has anyone else been able to
get UUCP to negotiate an Annex II? 
----------

True, the Annex II allows you to have modem control or flow control, but
not both.  But that's OK for UUCP, since UUCP uses packet protocols that
handle their own flow control.  Just set it up as a "modem" connection, and
set input_flow and output_flow to "none".

--
Jacob Gore	Jacob@Gore.Com		{nucsrl,boulder}!gore!jacob

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 89 18:00:41 EDT
From:      <KTORIDIS%GRPATVX1.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   How 3270 terminal emulations can be established;
Hi there

 I would like to have informations about how we can establish 3270
 terminal emulations (vm/sp) through ethernet from the following
 opearating systems:
                      - finder/multifinder
                      - ms-dos
                      - vax/vms
                      - unix

I would appriciate it very much if i could hear anyone's experience
about the subject (if you happen to work with something similar)
or if you know if there are any products (like tn3270 for the pc's)
that could help.

PLease send your responses to : "ktoridis@grpatvx1"


                                thanking you in advanse
                                  panos ktoridis
                                C.T.I Patra Greese



-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 89 22:00:41 GMT
From:      KTORIDIS@GRPATVX1.BITNET
To:        comp.protocols.tcp-ip
Subject:   How 3270 terminal emulations can be established;

Hi there

 I would like to have informations about how we can establish 3270
 terminal emulations (vm/sp) through ethernet from the following
 opearating systems:
                      - finder/multifinder
                      - ms-dos
                      - vax/vms
                      - unix

I would appriciate it very much if i could hear anyone's experience
about the subject (if you happen to work with something similar)
or if you know if there are any products (like tn3270 for the pc's)
that could help.

PLease send your responses to : "ktoridis@grpatvx1"


                                thanking you in advanse
                                  panos ktoridis
                                C.T.I Patra Greese

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 89 22:19:16 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Multiple copies!

Hey,  Somthing is causing multiple copies of most of the mail to
this list lately.  I get the second (usually) copy about 3-4 days
later after it has wandered through Sweden.  Can someone figure out
what is broken and stop it?
Thanks,
Dan
-------

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 89 01:04:05 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   Re:  Multiple copies!

Dan, I've sent mail to the NIC and asked them to filter out anything
from sunic.sunet.se.  I've got a mail message waiting in the queue for
the postmaster at sunic, but it seems stuck (time-outs).  *sigh*  

Mike

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 89 01:54:47 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Multiple copies!

Dan:

You noticed it too?  A number of the duplicates that I have seen have a sender
field of ucbarpa.berkeley.edu--or was that ucbarpa.bezerkely.edu?  I'll give
them the benefit of the doubt.

Merton

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 Jul 89 10:45:42 EDT
From:      Cliff Stallings <cliff@wsu-eng.eng.wayne.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   PC NFS with a Western Digital Micro Channel Card
 
Has anyone used PC NFS with a Western Digital "EtherCard PLUS/A (WDLAN-EP/A)
It is the PS/2 MicroChannel version.  It hangs during the procedure in the
network.bat file (DOS 4.0).
 
Cliff...
 
I can be reached at:
 
   cliff@wsu-eng.eng.wayne.edu
 
-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 Jul 89 13:53:43 EDT
From:      Russ Nelson <nelson@sun.soe.clarkson.edu>
To:        pcip@udel.edu, tcp-ip@sri-nic.arpa, telnet@zaphod.ncsa.uiuc.edu, ucsd.edu@sun.soe.clarkson.edu, comp-dcom-lans@sun.soe.clarkson.edu
Subject:   Alpha 4.0 release of PC packet drivers
Release 4.x of the Clarkson packet driver collection is now available.
This should be considered an alpha release.  Do not use this software
unless you can deal with any bugs that might appear.  The READ.ME file
appears below.

Major changes (all changes are listed below):

BICC Data Networks' ISOLAN 4110 driver added.
WD8003ET/A support added to the WD8003E driver.
NI5210 initialization bug fixed.
Packet driver tracer added.

Availability

The Clarkson collection of packet drivers is available by FTP, by
archive-server, and by modem.

FTP:

sun.soe.clarkson.edu:/pub/ka9q/alpha.arc
grape.ecs.clarkson.edu:/e/tcpip/alpha.arc

Archive-server:

Send mail to archive-server@sun.soe.clarkson.edu and put the following
command as the body of your message:
	send ka9q alpha01

Repeat for alpha02, alpha03, alpha04, and alpha05.  Combine the five parts
and unarchive it.

Modem:

Call the Clarkson Heath User's Group's BBS: (315)268-6667, 8N1,
1200/2400 Baud, 24 hours.  Change to file area 24 and download alpha.arc.

Opus:

260/360 in the Nodelist.  Alpha.arc is file requestable.

Read.me:

		Release 4.0 of the Clarkson packet drivers

If you are a user, all you need do is locate the correct packet driver for your
interface, and read DRIVERS.DOC.

Versions:

If you already have an older packet driver, you may wish to upgrade.  You
should base this decision on the contents of the "Changes..." section
below.  The major version (currently 4) goes up with every release.  The
minor version (.x, different for every driver) goes up with every released
change.  If the minor version hasn't changed, then chances are very good
that no significant bugs have been introduced.  The device-dependent part
of every one of the drivers below has been changed, if only to add
do-nothing stubs for receive mode setting and multicasting.

3C501.ASM       version equ     0
3C503.ASM       version equ     2
3C523.ASM       version equ     1
GENERIC.ASM     version equ     0
ISOLAN.ASM      version equ     1
NI5010.ASM      version equ     0
NI5210.ASM      version equ     2
SLIP8250.ASM    version equ     2
WD8003E.ASM     version equ     3


Contents:

3C501.ASM     Device dependent 3COM 3C501 code.
3C501.COM     Executable for a packet driver for the 3COM 3C501.
3C503.ASM     Device dependent 3COM 3C503 code.
3C503.COM     Executable for a packet driver for the 3COM 3C503.
3C523.ASM     Device dependent 3COM 3C523 code.
3C523.COM     Executable for a packet driver for the 3COM 3C523.
CHKPKT.ASM    Source of the packet driver installation checker.
CHKPKT.COM    Executable of the packet driver installation checker.
COPYING       The Free Software Foundation's General Public License.
DEFS.ASM      Definitions and macros.
DRIVERS.DOC   User documentation.
DUMP.C        Source of the trace dumper.
DUMP.EXE      Executable of the trace dumper.
GENERIC.ASM   Device dependent generic code (a skeleton only).
HEAD.ASM      Resident device independent generic code.
ISOLAN.ASM    Device dependent BICC Isolan 41xx code.
ISOLAN.COM    Executable for a packet driver for the BICC Isolan 41xx.
MAKEFILE      Makefile.  Uses tasm and tlink, but MS may work.
NI5010.ASM    Device dependent Interlan NI5010 code.
NI5010.COM    Executable for a packet driver for the Interlan NI5010.
NI5210.ASM    Device dependent MICOM-Interlan NI5210 code.
NI5210.COM    Executable for a packet driver for the MICOM-Interlan NI5210.
PACKETQA.TXT  Questions from R. Nelson and Answers from jbvb@vax.ftp.com
PACKET_D.108  Packet driver spec version 1.08
READ.ME       This file.
README.503    Bob Clements' README file for the 3c503.
README.WD8    Jan Engvald's README file for the WD8003ET/A.
SLIP8250.ASM  Device dependent SLIP driver using IBM-PC 8250.
SLIP8250.COM  Executable for a SLIP packet driver for the IBM-PC 8250.
STAT.C        Source of the statistics printer.
STAT.EXE      Executable of the statistics printer.
SUPPORT.TXT   Who supports the packet driver spec.
TAIL.ASM      Non-resident device independent generic code.
TERMIN.ASM    Source of the packet driver terminator.
TERMIN.COM    Executable of the packet driver terminator.
TRACE.ASM     Source of the packet driver tracer.
TRACE.COM     Executable of the packet driver tracer.
WD8003E.ASM   Device dependent Western Digital WD-8003e code.
WD8003E.COM   Executable for a packet driver for the Western Digital WD-8003e.

Editor's note:

I created the infrastructure for the packet drivers.  All of the device
dependent portions were written by other people.  The best term to
describe what I do is "Editor and publisher", because I perform a function
similar to that served in the literary world.

Please direct bug reports to me.  Chances are that the bug is in my code
anyway.  If not, I'll forward the bug report on to the device driver author.
As with all free software, no guarantee of support is given.

Russell Nelson, Editor of the Clarkson packet drivers.
nelson@clutx.clarkson.edu, nelson@clutx.bitnet, 70441.205@compuserve.com

Changes from version 3.0 to 4.0 of the drivers:

Russell Nelson added code to enable interrupts in the body of the packet
	driver.
Denis DeLaRoca added hardware handshake to the SLIP8250 driver.
John Grover optimized the SLIP8250 driver to work at 38.4 Kbps.
Russell Nelson added some sanity checking to slip8250 to warn the user about
	possible incorrect parameters.
Bob Clements added a switch to select thick or thin Ethernet in the 3c503.
Russell Nelson found a minor bug in NI5210 that caused it to fail to
	initialize sometimes.  Thanks to everyone who reported it.
Dan Lanciani found a race condition in the 80586 code common to the
	NI5210 and 3c523 drivers.
Russell Nelson split out the 82586 code from the NI5210 and 3c523 drivers
	into a single file.
Russell Nelson added memory address checking to NI5210.
Glen M. Marianko devised a method for determining the memory size of the
	NI5210 automagically.
Jan Engvald enhanced the packet driver code for Western Digital Ethernet
	cards to handle the micro channel version WD8003ET/A.
Jan Engvald enhanced TAIL.ASM to return error codes to DOS.
Jan Engvald enhanced HEAD.ASM to be aware of running on a MicroChannel bus.
Rainer Toebbicke wrote the BICC Data Networks' ISOLAN 4110 ethernet driver.
Russell Nelson wrote the packet driver tracer and dumper (trace.com and
	dump.exe).
Russell Nelson added support for set_rcv_mode, get_rcv_mode,
	set_multicast_list, and get_multicast_list to the infrastructure.  It
	is up to the individuals who wrote the individual drivers to add the
	device-dependent support.


Changes from version 2.0 to 3.0 of the drivers:

GNU General Public License adopted.  The restriction on commercial usage
     prevented some companies from distributing the packet drivers.  This
     is entirely my idea, so send any comments to nelson@clutx.clarkson.edu.
3c523 driver added, thanks to Dan Lanciani (ddl@harvard.edu).
Gregg Stefanik (wstef@eng.clemson.edu) is working on a 3c505 driver.  Don't
     bug him about it unless you're willing to be a alpha tester.
User documentation added (DRIVERS.DOC).
Brad Clements (no relation to Bob Clements) fixed the NI5210 driver so that
     it will work with a MTU of 1500.
The NI5210 now checks for shorts and opens before it starts up, thanks to
     Brad.
All memory-mapped packet drivers now check the packet length in send_pkt to
     ensure that too-long packets get trapped.  All packet drivers will
     work with MTUs of 1500 (plus 14 bytes of Ethernet header).
Deborah Swanberg noticed that attach_type was returning NO_CLASS
     when it meant to return NO_TYPE.
She also noted that packet drivers weren't returning unique handles.  This
     is only a problem with Phil Karn's code, as his code directs *every*
     packet driver to the same receiver routine.  With non-unique handles,
     it was impossible to tell which packet driver was upcalling the
     receiver.  Unique handles are now generated, based on the starting
     segment of the driver.  The latest version of Karn's code uses different
     receiver routines, so the code to implement this will eventually go away.
Tail.asm now prints the Ethernet address of the interface (if it is an Ethernet
     class device)
Micom has sold Interlan, and Racal has bought it, so perhaps the NI5210 is
     now the Racal-Interlan NI5210?
If anyone is interested in using the Zenith Z-100 with a SLIP packet driver, please
     send me (Russell Nelson) mail.  I have it partially written, but will
     probably never use it myself.
WD8003E and 3c503 sped up slightly -- stole movemem from NI5210.


Changes from version 3 to 2.0 of the drivers:

Version numbering now changed.  If the skeleton changes, the major version is
     incremented and all the minor versions are reset to zero.

Support for version 1.08 of the packet driver spec included.
Bob Clements' 3c503 driver added.  See README.503.
Some comments improved.
BAD_COMMAND checking code fixed.
cld instructions added to ensure that DF=0.
NI5210 sped up slightly -- look at movemem in ni5210.asm for an especially
     fast routine to move memory around.


Changes from version 2 to 3 of the drivers:

SLIP8250 can now be one of three classes: SLIP, AX.25, and KISS.
Tail.asm now checks for a packet driver already at the given interrupt.
Tail.asm now echoes its arguments in hex and decimal.
Tail.asm will close stdout so that a file handle won't be used up in
     case the user redirects stdout to NUL.
Head.asm now supports driver termination.
Termin.com added to terminate a driver.
Head.asm now does a stack swap to avoid pushing too many things when
     interrupting MS-LOSS.


Changes from version 1 to 2 of the drivers:

!!  Arguments are now in decimal by default  !!  Use a 0x prefix for hex.

DEFS.ASM created.
The loadport macro improved.
SLIP8250 driver added, thanks for a C version from Phil Karn.
     I've tried to put some 16550 support in, but I don't have one to
     test it with.  The documentation insists the TBRE goes low when
     the transmit buffer is not empty, while it makes sense for it to stay
     high while the buffer is not full.  I suspect the documentation is
     wrong.
NI5010 driver added, thanks for a C version from Bill Doster.
WD8003 driver added, by Bob Clements.
Loadport macro added to WD8003 driver by Russell Nelson.
Numeric arguments may now be specified in octal, decimal or hex, using the
     C notation.
Numeric arguments can now use up to 32 bits.
Source files reformatted.




-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 89 13:32:00 GMT
From:      ber@SUNIC.SUNET.SE
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple copies!


I would guess it's some leftovers, delayed somewhere. Mail comming from
vd.volvo.se for a non-existent newsgroup moderator are trapped at
sunic. As the guys at volvo maintaining news are on vacation, the
news flow to volvo has even been stopped until they have fixed the
problems at their site.

--Bjorn

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 89 14:44:38 GMT
From:      erik@naggum.uu.no (Erik T Naggum)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple copies!

> Can someone figure out
> what is broken and stop it?

This has been reported fixed by Bjorn Eriksen <ber@sunic.sunet.se>
after I complained when I got the first duplicate a week or so ago.

Was some problem with volvo.se getting news and having an old active
file.  You will see "vd.volvo.se" in the first Received-line.

I still notice duplicates, however, so I don't know what happened,
maybe just delays here and there.

Cheers,
--Erik

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 89 19:02:48 GMT
From:      gary@dvnspc1.Dev.Unisys.COM (Gary Barrett)
To:        comp.protocols.tcp-ip
Subject:   Re: Evaluating Network Performance


I would  be interested in knowing if there are any "standard"
benchmarks by which to evaluate TCP/IP implementations across a
variety of different vendor products.  Any information that you can
provide would be most appreciated.


Gary Barrett
Unisys 
Devon Engineering Facility
Wayne, PA

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 89 19:39:31 GMT
From:      amanda@intercon.uu.net (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: MacII FTP speeds on Ethernet

In article <8907250124.AA23044@multimax.encore.com>, bzs@ENCORE.COM (Barry
Shein) writes:
> With the additional overhead of the
> network activity (those disks are all PIO, right?) you're probably
> doing well at those speeds.

Yup.  I *really, really* wish Apple would let us do async I/O to the file
system.  I can ask for it, but the OS ignores me.  Grumble, grumble.
Sometimes you *want* to treat the disk as a slow device...

--
Amanda Walker
InterCon Systems Corporation
--
amanda@intercon.uu.net    |    ...!uunet!intercon!amanda

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 89 20:07:58 GMT
From:      bambi@kirk.nmg.bu.oz (David J. Hughes)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Stanford Socket interface to MacTCP

I have been told by a gentleman at Apple here in Australia that Stanford
has written a Berkeley socket interface to MacTCP.  If anyone in
*** Australia *** has obtained a copy, could you let me know as we are
not in a postition to FTP from the states yet.

Any help would be greatly appreciated.

bambi
...


+---------------------------------------------------------------------------+
|  David J. Hughes   (AKA bambi)	bambi@KIRK.BU.OZ      (ACSNet)      |
|  Network   Management   Group	 	bambi@KIRK.BU.OZ.AU   (DARPA)       |
|  Bond Universy, Gold Coast                                                |
|  Queensland   Australia		+61 75 951111                       |
 +---------------------------------------------------------------------------+
|	All standard disclaimers apply    (-: and so they should :-)        |
+---------------------------------------------------------------------------+

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 89 23:44:59 GMT
From:      desnoyer@apple.com (Peter Desnoyers)
To:        comp.protocols.tcp-ip
Subject:   Re: MacII FTP speeds on Ethernet

In article <8907250124.AA23044@multimax.encore.com> bzs@ENCORE.COM (Barry 
Shein) writes:
> >Can somebody tell me what the bottleneck is on FTP transfer rates for
> >a MacII on ethernet?  I am running two MacII's on a subnet in the 
> >Atmospheric Sciences program here at Princeton, with a Sun 3/280
> >file server also on the net.  I have the Apple ethernet cards in
> >the machines, and am running NCSA Telnet 2.3 (which has server
> >FTP support).  Basically, between the mac and the server I am
> >getting no better than about 35K bytes/sec for binary transfers,
> >no matter how I tweak the protocol parameters.

The numbers I have seen for memory-to-memory MacTCP and AppleTalk 
transaction protocol performance are very close. I would suspect that
the actual hardware driver that receives the packet (and is common
to both stacks) is the bottleneck.

That bottleneck is about an order of magnitude faster than the FTP
performance I see to a Sun (about 35kbyte/s, like Barry).  

> I believe if you run benchmarks writing the disk locally you'll find
> it peaks at around 50K bytes/sec. With the additional overhead of the
> network activity (those disks are all PIO, right?) you're probably
> doing well at those speeds.

My SC80 runs considerably faster than that. (I did a quick-and-dirty
benchmark just now and got ~150kbyte/s to duplicate a file. One-way
performance should be better.) My guess is that the bottleneck is in
NCSA Telnet, or at least in its interface with MacTCP and the file system.
 

                                      Peter Desnoyers
                                      Apple ATG
                                      (408) 974-4469

Disclaimer - I make no claims about the performance or any other 
characteristics of Apple products. These figures are for comment only.
Also, I don't mean to put down the fine efforts of the people who have
produced NCSA Telnet.

END OF DOCUMENT