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 August 1989 (336 messages, 185044 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1989/08.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 89 01:11:12 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Evaluating Network Performance

In article <727@dvnspc1.Dev.Unisys.COM>, gary@dvnspc1.Dev.Unisys.COM (Gary Barrett) writes:
> 
> 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.
> 
> Gary Barrett
> Unisys 
> Devon Engineering Facility
> Wayne, PA

Sorry to mention this again, but people keep asking.  I promise to shut up
about it for at least 6 weeks.

BRL's Mike Muuss's ttcp is the only reasonable one I know of.  It was not
written at a vendor.  It is flexible about buffer sizes and so forth.  It
does both UDP and TCP.  It is more accurate than some "blast" tests which
tend to measure the remote "inetd" as much as the transport.  It does not
test file system performance, unlike the common use of ftp.  File systems'
performance varies by a factor of >100, and while that is interesting, a
file system is not usually a layer 3 or 4 service.  Ttcp is free.

Ttcp unfortunately does not average several runs.  It also uses sockets
and not TLI.  However, since most current applications use sockets, one
could say that makes ttcp more, not less fair and accurate.  It is a UNIX
creature, and so would require porting to other systems.

If there is a better benchmark by the preceding criteria, I would like
a copy of it.

You can ftp a copy of ttcp.c from sgi.sgi.com or 192.26.63.16 in sgi/src/ttcp.c


Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 89 13:35:35 GMT
From:      swb@DAINICHI.TN.CORNELL.EDU (Scott Brim)
To:        comp.protocols.tcp-ip
Subject:   (none)

Linda,  you should talk to Xylogics, the folks who took over 
the Annex terminal server from Encore.

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 89 17:15:00 GMT
From:      amanda@intercon.uu.net (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: MacII FTP speeds on Ethernet

In article <3258@internal.Apple.COM>, desnoyer@apple.com (Peter Desnoyers)
writes:
> My guess is that the bottleneck is in
> NCSA Telnet, or at least in its interface with MacTCP and the file system.

As I've already noted, I'd say it's mostly in the latter.  NCSA blocks disk
I/O in 8K blocks, which is pretty reasonable, but it still blocks.  The MacTCP
interface routines, while not the absolutely most efficient (in particular,
they use TCPRcv instead of TCPNoCopyRcv), aren not bad, and they certainly
don't account for the 80% difference in performance between your
memory-to-memory experiment and the observed FTP performance.  Using the
same MacTCP interface but not writing stuff to disk, I have no problem getting
100-150K bytes/second.

Another thing that can make for a big performance hit is running under
MultiFinder, since this reduces the percentage of time in which the FTP
server can process data and write it to the disk.

I'm glad that the file system will support asynchronous I/O in System 7.0;
that'll help this sort of thing a lot.

--
Amanda Walker
InterCon Systems Corporation
amanda@intercon.uu.net    |    ...!uunet!intercon!amanda
--
"We may have come here on different ships, but we're in the same boat now."
    --Betsy Rose

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 89 23:18:42 GMT
From:      stephen@uowcsa.cs.uow.oz (The Mighty OGBO)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: Berkeley sockets on the Mac?


At some stage or another, it was announced in comp.protocols.appletalk that
there were Berkeley sockets available for the Mac. Apparantly they were
available by ftp-ing "citi-macip" from citi.umich.edu.

Unfortunately, being in Australia, I have no tcp link with the U.S., and as
such I would be most grateful if someone could get these by ftp, and then
forward them to by email. Hacking Mac device drivers is tolerable, but
painful. Socket libraries would be a blessing.

Thanks to the person who sends them to me.

				Stephen.

 Stephen Nicholson		ACSnet:	stephen@uowcsa
 Dept. of Computing Science	UUCP:	...!munnari!uowcsa.oz!stephen
 Uni. of Wollongong		ARPA:	stephen%uowcsa.oz@uunet.UU.NET

[Oh mighty OGBO save us from sobriety and teach us a sense of the ridiculous]

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 89 02:46:47 GMT
From:      ep0y+@ANDREW.CMU.EDU ("Erik D. Perkins")
To:        comp.protocols.tcp-ip
Subject:   RFC 1063 question


I am implementing the MTU discovery IP options for our gateway software.
 My question is:  should the IP MTU Request option be copied into
fragments upon fragmentation of the original datagram?  RFC 1063 doesn't
specify.  It is "obvious" that the reply option shouldn't be copied,
because it isn't changed.  Can anyone suggest a compelling reason to
copy the request option?

The individual fragments could conceivably travel over different routes,
so MINMTU values may differ.  Would this information be useful when the
original datagram is reassembled?  The general feeling around here is
that the answer is no.

There doesn't seem to be any real benefit to justify the extra
gateway/host overhead.  Any other thoughts???

(BTW, what is IP option 10?  Strict Source Routing is option 9 and MTU
Request is option 11.  Just wondering...)


thanks in advance,

erik perkins
network development
carnegie mellon

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 89 03:16:59 GMT
From:      ww0n+@ANDREW.CMU.EDU (Walter Lloyd Wimer III)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1063 question


Upon closer examination of RFC 791 (Internet Protocol), it is clear that
the MTU discovery options should definitely not be copied on
fragmentation since an IP option-type encodes the most-significant-bit
as the "copy" bit.  As specified in RFC 1063, the MTU option numbers do
not have this bit set.

(As is often the case, this answer was discovered mere moments after the
question was posted.)



Walt Wimer
Network Development
Carnegie Mellon University

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 89 05:44:43 GMT
From:      beepy%commuter@Sun.COM (Brian Pawlowski)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Looking for NFS-related Development/Research Information


Over the past three weeks I have stumbled across two research activities
involving NFS at Cornell (Replicated NFS File Systems) and research
into different types of User Level file servers based on the NFS
protocol (University of Sydney).

I wasn't looking for them, and now I'm curious if there is other
work being done to explore distributed file systems using NFS, the
NFS protocol or derivatives of them. I'm not interested in
direct implementations of NFS (unless there's a new twist, or you
think you can surprise me in that I don't already know about you -
like the engineer did during lunch in Munich :-) The work is
though provoking and is interesting in the way people are
extending the NFS protocol to support new features.

A Tech Report describing the work would be great! A brief e-mail
would be acceptable. I'm curious about the reason you're doing the work,
not only what you're doing.

Address:

	Brian Pawlowski
	Sun Microsystems, Inc.
	2550 Garcia Ave. MS 14-40
	Mountain View, California 94043

Thanks!


			Brian Pawlowski <beepy@sun.com> <sun!beepy>
			Sun Microsystems, NFS Development

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 89 06:20:28 GMT
From:      john@smosjc.UUCP (John Conover)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC Library sources for System V

In article <8906141633.AA01919@sunned.sun.com>, warrens@SUN.COM (Warren Smith) writes:
> RPC/XDR is a necessary component of NFS, but it is not a "part" of
> NFS any more than IP is.  We demonstrated NFS over OSI connectionless
> transports more than 2 years ago, for instance.
>

Where are the sources for RPC available on magnetic media?
	Thanks,
	John
	..uunet!smosjc!john
 

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 89 16:23:00 PST
From:      art@sage.acc.com
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   SUNOS 4.x NIT interface

I'm trying to port a test program to SUNOS 4.0 on a SUN-3/60  using the
STREAMS NIT interface.  I'm also trying to bring up tcpdump and am
seeing similar problems.  I've installed the nit_if.o from LBL and
have applied the 4.0 patches for tcpdump.

I can successfully transmit raw packets out the Ethernet interface,
but when I attempt to read (I haven't tried using getmsg() yet), I
seem to get the same data over and over. If a real packet is received,
that seems to get passed up, then it reverts to repeating it's
default data.

This behavior seems to ring a bell about something I'd seen on this
list.

Please send any hints/ideas directly to me.
Thanks in advance.
+-----------------------------------------------------------------------+
|	Art Berggreen		Advanced Computer Communications	|
|	<art@sage.acc.com>	Santa Barbara Street			|
|	(805)963-9431		Santa Barbara, CA 93101			|
+-----------------------------------------------------------------------+


-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Aug 89 16:12:17 PDT
From:      Fred Ostapik <FRED@SRI-NIC.ARPA>
To:        silver!hughes@iuvax.cs.indiana.edu
Cc:        tcp-ip@SRI-NIC.ARPA, FRED@SRI-NIC.ARPA
Subject:   Re: Network Printing
IT WOULD BE MOST USEFUL TO ME IF YOU COULD JUST PUT DOWN THE STRIKING EVENTS
THAT OCCURRED AT THE CERT WORKSHOP AS FACTUAL ITEMS WITH NO PARTICULAR SLANT.
-------
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 89 14:37:34 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip,comp.unix.i386
Subject:   Oracle and TCP/IP on System V/386.

Is there any standard for the Streams TLI interfaces to socket libraries
for System V? We have a Bell Tech/Intel SV/386 with Lachman TCP using a
WD8003e Ethernet card. The Oracle docs indicate it needs SQL*Net which
requires a MICOM-Interlan NP600 Ethernet card. If the socket library
interface to the Streams TLI is compatible then we should just be able
to run Oracle with Lachman TCP. This would be particularly desirable
since we plan on getting a Bell Tech IWS card, and since it includes an
Intel PC586 controller it'd be nice not to have to duplicate it.
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
Business: peter@ficc.uu.net, +1 713 274 5180. | "The sentence I am now
Personal: peter@sugar.hackercorp.com.   `-_-' |  writing is the sentence
Quote: Have you hugged your wolf today?  'U`  |  you are now reading"

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 89 14:49:16 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  RFC 1063 question

The absense of the 'copy on fragmentation' flag indicates that there is
no need to copy on fragmentation.  See my IP option wall chart below:
(Please send flaming corrections to cpw@lanl.gov)

Two types of options fixed and variable:

TYPE	        MNE LEN  First Octet    Second Octet    Function
	
		 	 C CL   NUM     OLEN

   F		EOL   1  0 00 00000   	N/A		End of Option List.
   F		NOP   1  0 00 00001   	N/A		No OPeration 

  V/F      SECURITY  11  1 00 00010     00001011	SECURITY.
   V	       LSRR var  1 00 00011 			Loose Source and RR
   V	         TS var  0 10 00100                     Time Stamp.
   V      XSECURITY var  1 00 00101                     eXtended SECURITY.
                    xxx  x xx 00110                     not defined
   V	         RR var  0 00 00111                     Record Route.
  V/F         SATID   4  1 00 01000     00000100**      SATnet stream ID.
   V	       SSRR var  1 00 01001                     Strict Source and RR
                    xxx  x xx 01010                     not defined
  V/F	       PMTU   4	 1 00 01011   	00000100        Probe MTU
  V/F	       RMTU   4  1 00 01100     00000100        Reply MTU

TYPE	(F = Fixed), (V = Variable), (V/F = Fixed but with length octet).
MNE 	mneumonic
LEN	length of option
C   	copied flag (copy on fragmentation, if set to 1)
CL  	option class 
	0 = control
	1 = reserved for future use
	2 = debugging and measurement
	3 = reserved for future use
NUM 	option number
OLEN	value of option length field for variable length options

** RFC 791 indicates 00000010 which must be a typo.

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 89 15:09:07 GMT
From:      grr@cbmvax.UUCP (George Robbins)
To:        comp.protocols.tcp-ip
Subject:   Re: RE: Worm report fails to address the problem

In article <89627152623.c83.DSTEVENS> DSTEVENS@DSRM12.STEVENS-TECH.EDU (David L. Stevens) writes:
> 
>    
> 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.

Say what?  It is not at all obvious that anybody needs to be punished for
violation of this precious "security", in the absence of any further malign
intent or actions.  "Security" need not be need not be used as a catchall
excuse that lays all the fault on the perpetrator and excuses the victims
for their failure to understand their exposure and secure their system to
such a degree they deem appropriate.  I'd leave the "enforcement" of security
up to the organizations who have a compelling need for it and prefer not to
have government supply a new set of rules and regulations over a network of
diverse organizations and interests.  One might still be regretting such
rules long after the battle of the worm has faded into legend...

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

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 89 18:33:56 GMT
From:      msd@trwind.UUCP (Marc S. Dye )
To:        comp.protocols.tcp-ip
Subject:   Re: Revision of PC/IP scorecard


Might I add the suggestion that the data regarding performance list a
Norton number for the PC processor (host-side for 'smart' implementations).
Also, a footnote indicating the configuration of the PC/IP host used and
that of the peer it was talking to.

ASCII vs. BINARY mode FTP transfer data might also be nice.  There are
some drastic performance differences between these in many implementations.

Bi-directionality is also a possible performance issue.  If you expect
anything but the best value for either direction, that should noted.

Finally, I should like to point out that there are some implementations
around which take much license with the performance statistics their FTP
client interfaces report.  The numbers should really report the total
time it takes the data to actually sink to the destination medium (usu.
RAMdisk for these sorts of tests);  data thrown over the wall to TCP
shouldn't count.  A good way to ameliorate this effect is to require a
LARGE file transfer (> a few Megs).

++msd -- msd@TRW.Com -- Marc S. Dye (ayuda Company)
1393 Stonemeadow Ct.;  Camarillo, CA;  93010;  USA;  (805)987-0433

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 89 18:36:05 GMT
From:      VAF@SCORE.STANFORD.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   TCP socket message interface?

Has anyone built an IPC interface on top of BSD sockets to do asynchronous
message passing? Basically, what I want is a library that adds some record
structure to a TCP stream, so I don't have to deal with socket buffering and
waiting for input/output to complete. Ideally, I'm looking for something like
the TOPS-20 IPCF interface (for any of you who's memory goes back that far...)
that uses TCP sockets. I realize that this wouldn't be terribly difficult to
implement (though it might be tricky to do it "right"), but I'd rather not have
to do it myself if someone has already gone to the trouble...

	Thanks,
	Vince Fuller, Stanford Networking
-------

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 89 19:27:00 GMT
From:      hughes@silver.bacs.indiana.edu
To:        comp.protocols.tcp-ip
Subject:   Network Printing


We have a need at Indiana University to implement a TCP/IP-based
network printing system for our statewide network.  Such printing
services must be made available to a mixed and wide variety of
vendor's machines and operating systems (with the common denominator
being, again, TCP/IP).  Included in this mix are VAXes and MicroVAXes
running VMS (with Wollongong's product), ULTRIX, and Berkely 4.3; 
IBM mainframes; Sun, NeXT, and Apollo workstations; and a few others 
to boot.  (Support for PC's and Mac's would be nice too...)

We know about the LPR capabilities under most UNIX implementations
(and coming in the next release of Wollongong), and have been using
it in a few places on the net.  But does the collective family
of LPR/LPD/LPQ/LPC/LPRM provide enough functionality *and* reliability
to satisfy most users (and implementors) for such a large base?  And 
is the maintenance of dozens or hundreds of local printcap files an
administrator's nightmare?

And if this seems to be the most viable solution, is anyone
aware of enhancements to this suite, possibly developed at 
another university (or even available commercially), that we 
might be interested in?  

Any information at all would be appreciated and investigated.

Please respond via email.  I will post a summary of solutions
if so requested.  Thanks in advance.

          =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
               Larry Hughes, Senior Programmer
                University Computing Services
               Indiana University, Bloomington

          Internet: hughes@jade.bacs.indiana.edu
                    hughes@silver.bacs.indiana.edu
          Bitnet  : hughes@iubacs
          =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 89 20:22:48 GMT
From:      DKRUGER@UALTAVM.BITNET (Dwight Kruger)
To:        comp.protocols.tcp-ip
Subject:   Horsepower of IBM 8232 TCP/IP interface

Has anyone measured the horsepower in packets/second of an IBM 8232 LAN
Channel Station on ethernet?  I would be interest in the host and
work-station types, ethernet load, IBM operating system on the host, etc.
 
Dwight Kruger
Network Software Development
University of Alberta

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 89 20:48:50 GMT
From:      jml@tw-rnd.SanDiego.NCR.COM (Michael Lodman)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Wollongong TCP/IP and Printer Sharing

I have ordered TCP/IP software for DOS from Wollongong. One
of the things I would like to do is have the PCs share a
printer tied to a Unix host. 

To do this, I think I need to capture output from
the devices lptx: and re-route it into an rsh <sysname> lp
type command. I've seen programs that captured lptx: output
and put it into a file, so I assume this may be possible.

Does someone know how to accomplish this? Is there software,
commercial or otherwise to do this? Thanks!

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

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 89 21:02:00 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Printing

In article <44500002@silver> hughes@silver.bacs.indiana.edu writes:

   ... But does the collective family
   of LPR/LPD/LPQ/LPC/LPRM provide enough functionality *and* reliability
   to satisfy most users (and implementors) for such a large base?

*and* security?  The problem we have here is charging users for the printing
that they do.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])|(70441.205@compuserve.com)|
       (Russell.Nelson@f360.n260.z1.fidonet.org)|(BH01@GEnie.com :-)

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Aug 89 06:24:38 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        sun-barr!texsun!texbell!uhnix1!sugar!ficc!peter@apple.com, tcp-ip@sri-nic.arpa
Subject:   Re:  Oracle and TCP/IP on System V/386.
There is no standard for mapping TLI calls into TCP operations.  Each
supplier of SVR3(Streams) TCP is likely to have somewhat different
interface functionality or calling sequences.

Dave
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Aug 89 08:30:59 -0500
From:      larry hughes <hughes@silver.bacs.indiana.edu>
To:        iuvax!SRI-NIC.ARPA!FRED
Cc:        FRED@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Network Printing
I think you replied to the wrong person; I wrote about Network Printing,
not a "Cert workshop".
-Larry Hughes
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 89 00:23:00 GMT
From:      art@SAGE.ACC.COM
To:        comp.protocols.tcp-ip
Subject:   SUNOS 4.x NIT interface


I'm trying to port a test program to SUNOS 4.0 on a SUN-3/60  using the
STREAMS NIT interface.  I'm also trying to bring up tcpdump and am
seeing similar problems.  I've installed the nit_if.o from LBL and
have applied the 4.0 patches for tcpdump.

I can successfully transmit raw packets out the Ethernet interface,
but when I attempt to read (I haven't tried using getmsg() yet), I
seem to get the same data over and over. If a real packet is received,
that seems to get passed up, then it reverts to repeating it's
default data.

This behavior seems to ring a bell about something I'd seen on this
list.

Please send any hints/ideas directly to me.
Thanks in advance.
+-----------------------------------------------------------------------+
|	Art Berggreen		Advanced Computer Communications	|
|	<art@sage.acc.com>	Santa Barbara Street			|
|	(805)963-9431		Santa Barbara, CA 93101			|
 +-----------------------------------------------------------------------+

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 89 03:23:36 GMT
From:      236@DB0TUZ01.BITNET
To:        comp.protocols.tcp-ip
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

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Thu, 03 Aug 89 13:16:37 CDT
From:      "Linda Winkler,   312-972-7236" <B32357@ANLVM.CTD.ANL.GOV>
To:        <TCP-IP@SRI-NIC.ARPA>
We have been attempting to run Van Jacobson's traceroute on a Sun.
We don't see any routes appearing, only the timeout indicators * * *.
I've checked the kernel hack and monitored the input and output
packets with a Lanalyzer.  Everything appears ok but, the returned
packets never seem to reach the traceroute program.  Can anyone
help?                  Linda
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 89 13:24:38 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  Oracle and TCP/IP on System V/386.

There is no standard for mapping TLI calls into TCP operations.  Each
supplier of SVR3(Streams) TCP is likely to have somewhat different
interface functionality or calling sequences.

Dave

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 89 16:11:29 GMT
From:      verber@pacific.mps.ohio-state.edu (Mark A. Verber)
To:        comp.protocols.tcp-ip
Subject:   Help with SLIP under SunOS 4.0

I picked up a copy of the stream based slip for SunOS 4.x recently
from neat.ai.toronto.edu.  I know I must have done something stupid
but I can't figure out want it was (and since the machine I am running
as my slip server is also servicing 14 diskless clients I can't afford
to do alot of testing.).  I was hoping someone might be able to
recognize my problem and save me alot of problem.

The primary symptom is that as soon as sliplogin is run, slip_open
seems to be repeatedly called.  For example, the following messages
were generated in a period less than a minute from a *single* sliplogin:

	slip0: coming up
	slip1: coming up
	slip2: coming up
	slip3: coming up
	slip4: coming up
	slip: cannot allocate interface (NSLIP is 5)
	slip: cannot allocate interface (NSLIP is 5)
	slip: cannot allocate interface (NSLIP is 5)
	slip: cannot allocate interface (NSLIP is 5)
	slip: cannot allocate interface (NSLIP is 5)
	slip: cannot allocate interface (NSLIP is 5)

My configuration is a Sun 4/280 running SunOS 4.0 w/ the yapt 5.5c
patches installed.  I am using ttyb which has flags set to 3.  I was
using a IBM-AT running ka9q as a slip client.  One oddity was that
while I got these messages I was having no problem using slip to get
to/from the PC running ka9q.  The initual slip connection seemed to be
working fine.

Another symptom is when a HUP was sent to sliplogin my machine crashed
with the following output:

	slip4: going down
	BAD TRAP
	syslogd: Data fault
	kernel read fault at addr=0xc, pme=0x0
	Bus Error Reg 80<INVALID>
	pid=303, pc=0xf80b72b0, sp=0xf80d0b40, psr=0x400cc6, context=8
	g1-g7: c00, 400ce0, 0, 0, 0, f80e9000, f80e9000

Any ideas what I did wrong?  I have check twice make sure my copy of
sliplogin and tty_slip were the same as the one on neat.  Seems to be
fine.  I believe I followed all the instructions in the README.

--- Mark Verber
    verber@mps.ohio-state.edu
    1-614-292-8002

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 89 17:59:44 GMT
From:      pete@sunseeker.UUCP (Peter R. Carpenter)
To:        comp.protocols.tcp-ip
Subject:   Question about echo-udp

I've got this little program to implement echo using tcp/udp-ip.  I call 
gethostbyname(), and getservbyname("echo","udp") and get back reasonable 
hostent and servent structures, except that the h_addr in hostent for 
various machines is always a single character 'H'.

If I call getservbyname() with echo/tcp or other "well known" services it fails.
Its a Sun/NFS system, and there is a note in /etc/services which says the file
is ignored when yellow pages are operating. I'm not concerned with yp's or
sun-ism's at this point in time.

Call socket() with DGRAMs, and connect(), return OK. Am I really connected?

I get a string from stdin, and write it to the socket, sleep for a few to 
let things percolate. Write length is correct, but the read off the socket 
returns -1, Nobody home? A second read returns 0.

Any ideas? 

---
Pete Carpenter, Cirrus Logic Inc, 1463 Centre Pointe Dr, Milpitas, CA 95035
{amdahl,ames,apple,bunker,pyramid}!oliveb!tymix!cirrusl!pete   408-945-8300
---------------------------------------------------------------------------

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 89 18:16:37 GMT
From:      B32357@ANLVM.CTD.ANL.GOV ("Linda Winkler,   312-972-7236")
To:        comp.protocols.tcp-ip
Subject:   (none)

We have been attempting to run Van Jacobson's traceroute on a Sun.
We don't see any routes appearing, only the timeout indicators * * *.
I've checked the kernel hack and monitored the input and output
packets with a Lanalyzer.  Everything appears ok but, the returned
packets never seem to reach the traceroute program.  Can anyone
help?                  Linda

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 89 19:57:14 GMT
From:      ceide@bbn.com (Chantal Eide)
To:        comp.protocols.tcp-ip
Subject:   tcp-ip on AT&T3B2


We have a AT&T3B2 522 running Wollongong version 3.0.1 TCP/IP
software.  We are experiencing the following problem: we have an
application which looks like the Programming Example 8 given in
Appendix A of the Enhanced TCP/IP WIN/3B Reference Manual:

    register int file;
    struct sockaddr_in sin;

    vinit((PTR) &sin, sizeof(sin), 0);
    if ((file = socket(AF_INET, SOCK_DGRAM, 0)) < 0)
        {}
    sin.sin_family = AF_INET;
    sin.sin_port = htons(port); /* port is 0 or 2180 I think */
    sin.sin_addr.s_addr = host; /* host is 0 I think */
    if (bind(file, (struct sockaddr *) &sin, sizeof(sin)) < 0)


Our application returns an error on the bind: can't assign requested
address.  Does anyone have a workaround or solution?

Please email responses as I don't read this group.

Thank you,


Chantal Eide
ceide@bbn.com

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 89 20:42:40 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Western Digital 8003 family

The WD8003/A Microchannel card is very close, but not quite identical
to the PC/AT bus card.  In particular, the MCA card has more memory and
a different on-board bus width.  Our driver works on all the WD8003 family,
which requires a little special code to deal with the MCA card's bus and
some chip glitches (see the Nat. Semi errata sheets for the 8390) on 1Mb
networks.  The latest release of the Clarkson packet drivers has source
for a driver which can handle at least the MCA and PC/AT cards.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Fri, 04 Aug 89 09:44:31 PDT
From:      Greg Satz <satz@cisco.com>
To:        mailrus!accuvax.nwu.edu!morrison@tut.cis.ohio-state.edu  (Vance Morrison)
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: BOOTP through gateways
Vance,

You must be working with old information about our products. While we do
not implement BOOTP exactly as you would have liked, we do provide some
extra features which you do not describe and apparently are not aware.

As you have clearly pointed out, BOOTP clients can utilize the information
in the server field of the returned BOOTP REPLY. The implicit assumption in
your description is that the BOOTP client can only TFTP from the server
that answered the BOOTP. Both Croft's original version (which is three
years old now) and CMU's, which is a derivation, return the BOOTP server's
address in the server address field.  While this does work it isn't the
only option left to a client.


We consciously chose to decouple our TFTP process from the BOOTP process.
This gave us the ability to obtain TFTP information from other then the
supplier of BOOTP information. You reported that we can only TFTP from a
server on the directly connected network unless there is a cisco router
also on the connected network. This is true if you do not have non-volatile
memory.  If you do have non-volatile memory you have more flexibility and
control.  We have a boot system command which permits you to load
information via TFTP and specify the filename and host address. You can
form a list of boot system commands in case the first host (or directed
broadcast) fails. We have been successfully performing network boots using
this scheme for over three years.

Your complaint isn't with our implementation of BOOTP but rather our use of
the returned information. We do implement BOOTP proxy forwarding correctly
as you point out later in your message.

You are correct that adding an option to our TFTP configuration code to
permit the usage of the BOOTP server would be a useful feature. Thanks for
pointing that out.

Greg Satz
cisco

PS. Comments, questions and complaints about cisco products can be sent to
customer-service@cisco.com and are very welcome.
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 89 10:53:03 GMT
From:      jim@syteke.UUCP (Jim Sanchez)
To:        comp.protocols.tcp-ip
Subject:   Re: Evaluating Network Performance

I am interested in getting the program but only have uucp.  How about a posting if enough people are interested.
-- 
Jim Sanchez  {sun,hplabs}!sun!sytek!syteke!jim OR
Hughes LAN Systems, Brussels  mcvax!prlb2!sunbim!syteke!jim

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 89 11:14:07 GMT
From:      ROBERT@VM1.MCGILL.CA (Robert Craig)
To:        comp.protocols.tcp-ip
Subject:   traceroute and nit

Would some kind soul tell me where I can pick up a copy
of the source for traceroute, and where I can find the
fixes to the NIT interface for SunOS 3.5 (for use with
nnstat).

Thanks,
Robert Craig                          domain: robert@vm1.mcgill.ca
Network Analyst                       bitnet: robert@mcgill1
McGill University Computing Centre    FAX: (514) 398-6876
805 Sherbrooke St. W.
Montreal, Quebec H3A 2K6
(514) 398-3710

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 89 12:42:09 GMT
From:      kre@cs.mu.oz.au (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Re: trace route to OZ

In article <8907282200.AA06660@ucbvax.Berkeley.EDU>,
J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes:
> (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?)

Sure ...

traceroute to sics.se (192.16.123.90), 30 hops max, 40 byte packets
 1  HW.GW.AU (128.250.1.1)  10 ms  10 ms  10 ms
 2  132.160.253.1 (132.160.253.1)  560 ms *  560 ms
 3  132.160.1.1 (132.160.1.1)  570 ms  560 ms  560 ms 
 4  132.160.249.2 (132.160.249.2)  620 ms  610 ms  610 ms 
 5  ARC1.BARRNET.NET (192.52.195.7)  620 ms  620 ms  620 ms 
 6  ARC.SU.BARRNET.NET (131.119.3.6)  620 ms  620 ms  630 ms 
 7  Salt_Lake_City.UT.NSS.NSF.NET (129.140.79.13)  690 ms  690 ms  690 ms 
 8  Ann_Arbor.MI.NSS.NSF.NET (129.140.81.15)  750 ms  740 ms  750 ms 
 9  Princeton.NJ.NSS.NSF.NET (129.140.72.17)  790 ms *  790 ms 
10  * * * 
11  slartibartfast-gateway.jvnc.net (128.121.54.76)  800 ms  800 ms  800 ms 
12  * kth-ptp-gw.nordunet.se (192.36.148.66)  1750 ms  1720 ms 
13  se-gw.nordunet.se (192.36.148.21)  1670 ms  1650 ms  1650 ms 
14  * ipsthlm-gw.sunet.se (192.36.125.10)  1660 ms  1670 ms 
15  130.237.210.1 (130.237.210.1)  1660 ms  1920 ms  1720 ms 
16  ipkista-gw.kth.se (130.237.72.204)  1740 ms  1870 ms  1670 ms 
17  * * * 
18  * * *

I assume that sics.se has the IP TTL bug still in it, and if I had let
it run out to 34 hops (or so) eventually the packet from the destination
would have made it back.  (I did let it run beyond 18, but the rest
wasn't interesting).

kre

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 89 14:25:34 GMT
From:      ceide@bbn.com (Chantal Eide)
To:        comp.sys.att,comp.protocols.tcp-ip
Subject:   tcp-ip problems on the AT&T 6386

We have an ATT 6386 using Interlan's TCP/IP implementation (version?).
We are having some difficulties:
 
1. getsockname() makes a socket unusable if called after listen()
 
        /* works */                             /* does not work */
        s = socket(...)                         s = socket(...)
        bind(s, ...)                            bind(s, ...)
        getsockname(s, ...)                     listen(s, ...)
        listen(s, ...)                          getsockname(s, ...)
                                                /* s is now unusable */
   Any insights anyone?

2. Closing a tcp connection immediately flushes data still in the "pipe".
   Our application sends a bunch of data, then calls close.  The
   documentation states that by default sockets are set to "linger" for 45
   seconds.  We even tried explicitely setting linger on [with
   setsockopt(s, ... SO_LINGER) (or whatever)], to no avail.  Has anyone
   dealt with this before?

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 89 16:18:59 GMT
From:      german@UXH.CSO.UIUC.EDU (Gregory German)
To:        comp.protocols.tcp-ip
Subject:   RE: PC NFS with a Western Digital Micro Channel Card


What version of PC NFS are you using?  Versions earlier than 3.0.1 do not
work with DOS 4.0.  There is a good chance that is your problem and not the
card.

         Greg German (german@sonne.CSO.UIUC.EDU) (217-333-8293)
US Mail: Univ of Illinois, CSO, 1304 W Springfield Ave, Urbana, IL  61801
Office:  129 Digital Computer Lab., Network Design Office

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 89 16:22:52 GMT
From:      german@UXH.CSO.UIUC.EDU (Gregory German)
To:        comp.protocols.tcp-ip
Subject:   Packet Driver for NE1000, NE2000?


I have not noticed any packet drivers for the NE1000 or NE2000 cards
available from Novell.  There is also a clone I have heard about of the
NE1000 that is supposed to be very low priced.  Does anyone know of a
driver that will work with these?  I had heard that the NE1000 was very
much like the 3Com 3c501, but I could not get that driver to work.  The
PD looked like it loaded, but I could not get either NCSA Telnet or the
Netware shell to actually put anything out on the wire.  Thanks for any
help/information you can give me.
         Greg German (german@sonne.CSO.UIUC.EDU) (217-333-8293)
US Mail: Univ of Illinois, CSO, 1304 W Springfield Ave, Urbana, IL  61801
Office:  129 Digital Computer Lab., Network Design Office

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 89 16:44:31 GMT
From:      satz@CISCO.COM (Greg Satz)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP through gateways

Vance,

You must be working with old information about our products. While we do
not implement BOOTP exactly as you would have liked, we do provide some
extra features which you do not describe and apparently are not aware.

As you have clearly pointed out, BOOTP clients can utilize the information
in the server field of the returned BOOTP REPLY. The implicit assumption in
your description is that the BOOTP client can only TFTP from the server
that answered the BOOTP. Both Croft's original version (which is three
years old now) and CMU's, which is a derivation, return the BOOTP server's
address in the server address field.  While this does work it isn't the
only option left to a client.


We consciously chose to decouple our TFTP process from the BOOTP process.
This gave us the ability to obtain TFTP information from other then the
supplier of BOOTP information. You reported that we can only TFTP from a
server on the directly connected network unless there is a cisco router
also on the connected network. This is true if you do not have non-volatile
memory.  If you do have non-volatile memory you have more flexibility and
control.  We have a boot system command which permits you to load
information via TFTP and specify the filename and host address. You can
form a list of boot system commands in case the first host (or directed
broadcast) fails. We have been successfully performing network boots using
this scheme for over three years.

Your complaint isn't with our implementation of BOOTP but rather our use of
the returned information. We do implement BOOTP proxy forwarding correctly
as you point out later in your message.

You are correct that adding an option to our TFTP configuration code to
permit the usage of the BOOTP server would be a useful feature. Thanks for
pointing that out.

Greg Satz
cisco

PS. Comments, questions and complaints about cisco products can be sent to
customer-service@cisco.com and are very welcome.

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 89 17:30:07 GMT
From:      jjr@nandi.ESD.3Com.COM (Janardan Ramesh)
To:        comp.protocols.tcp-ip
Subject:   tnlib: New telnet utility library(?)


I understand that this library was done by Van Jacobson recently. Is it
available for annonymous FTP anywhere? I would appreciate any help in this
regards.

J. Ramesh

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 89 18:47:35 GMT
From:      pquiring@ncrorl.Orlando.NCR.COM (Powell Quiring)
To:        comp.protocols.misc,comp.org.decus,comp.sys.dec,comp.protocols.tcp-ip
Subject:   DECNET anyone?


Does anyone know how to where to get a DECNET port/source?
An AT&T Streams implementation would be preferable.

Powell Quiring
quiring@Orlando.NCR.COM	..!uunet!ncrlnk!ncrorl!pquiring

Workstations, NCR E&M Orlando
3200 Lake Emma Rd.
Lake Mary, FL 32746

VOICE: (407) 333-9250,     VOICEplus: 656-1219,      FAX: (407) 333-0050

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 89 18:50:00 GMT
From:      melanie@uxe.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Network Printing



the university of illinois has a distributed printing system. a central
server resides on a vax 3500 and talks to satellite servers and/or clients
on suns, vaxes, convexes (convi?) and an ibm 3081. this is all tcp-based.
however, since the 3500 runs ultrix and decnet-ultrix, a decnet interface
could be written in a straightforward fashion. 

accounting cards (well, theyre virtual...) are cut to the ibm-based
accounting system by the central server (co). chargeback is quite accurate.

i didnt write it, i just use it...

contact

charley kline
sr research programmer and resident network guru
kline@tuna.cso.uiuc.edu

or 

sue greenberg 
charley's boss
sue@uxh.cso.uiuc.edu

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 89 20:56:31 GMT
From:      kwang@infmx.UUCP (Kwang Sung)
To:        comp.protocols.tcp-ip
Subject:   Data Base Engine running on ISODE env. with STREAMS TLI on IBM 386.

Does anyone know a Data Base Engine Product running on ISODE environment
interfacing with STREAMS TLI on IBM 80386 machine ???

Let me know.

Kwang Sung
415-926-6758
UUCP: ...!pyramid\!infmx\!kwang
.

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 89 21:12:12 GMT
From:      mikeh@dell.dell.com (Mike Hammel)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Wollongong TCP/IP and Printer Sharing

In article <464@tw-rnd.SanDiego.NCR.COM> jml@tw-rnd.SanDiego.NCR.COM (Michael Lodman) writes:
>of the things I would like to do is have the PCs share a
>printer tied to a Unix host. 
:
>Does someone know how to accomplish this? Is there software,
>commercial or otherwise to do this? Thanks!

ISC(actually Locus) has a package known as PC-Interface.  It has a command,  
PRINTER, that allows you to redirect output from DOS or applications
to UNIX printers.

Michael J. Hammel   | UUCP(preferred): ...!cs.utexas.edu!dell!Kepler!mjhammel
Dell Computer Corp. | Also: ...!dell!dell!mikeh  or 73377.3467@compuserve.com
Austin, TX	    | Phone: 512-338-4400 ext 7169  
	    	    | "I know engineers, they looooove to change things"
Disclaimer:	    |:
	These are my views, not necessarily those of the nice folks I work for.

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 89 00:05:48 GMT
From:      danzig@ucbarpa.Berkeley.EDU (Peter Danzig)
To:        comp.protocols.tcp-ip
Subject:   Microsecond Resolution Clock for Sun Workstations


 We have produced a microsecond resolution timer board for Sun workstations 
and are distributing them through a company in Berkeley.  We have distributed 
over sixteen boards now.  The board works with Sun 3/50, 3/60, 3/75, 3/160, 
3/260, and 4/280 workstations.  You must leave the VME card adjacent 
to the processor vacant in the VME based workstations (We may be able to
cook up a tiny one for you if it's really important).  If your machine is not 
listed, ask us about it.  

 The board usurps the DES socket.  Just plug it in as if it were a chip.   
On 3/75, 3/160, 3/260, 4/280 systems you must also plug in a few PAL and buffer
chips that we provide.  Sun chose not to support the DES socket in these
workstations.  Tell us what machines your want to use it with.

 On a 3/50 with the screen blanked you can generate a 32 bit timestamp inside 
the kernel in about 20 microseconds and about 11 microseconds from user 
space (the difference is because you can't call splimp() and splx()
from user space).  For 64 bit timestamps, expect 30 microseconds and 23 
microseconds.  On a 3/60, 64 bit timestamps take 29 and 20 
microseconds.  You can set the time between clock ticks with the timer 
library call tmrPrescaleBy(x) to be as high as four ticks per microsecond.  
The can timer initialize itself to 32 or 64 bit mode.  A call to tmrTimeval() 
will set the time to the UNIX gettimeofday value.  To open and initialize the 
timer, call tmrOpen().  To map the timer into user space, call tmrMap().  To 
read a 32 bit timestamp call getTS().  To read a UNIX timeval structure, call 
getTV().  Here is a summary of the timer library:
 
	int fd = tmrOpen ()   
	void tmrMap ()
	void tmrPrescaleBy (int x)
	void tmrTimeval ()
	getTS (long *x)   
	getTV (struct timeval *tv)  

 The board doesn't generate an interrupt.  

  We can distribute the device driver on an IBM PC diskette or email it
to you.  The device driver works under SunOS 3.5 and SunOS 4.0.  It 
has been ported to other operating systems: Dash, Sprite, and the V-system.

  The board costs $125.  For 3/75, 3/160, 3/260, 4/280 systems
add $25 for the PALs and buffers chips.  If you want one, contact us 
by phone or electronic mail.  Shipping in the US through FED Express
is $9.50 for standard air delivery of any number of boards and through
US mail is $2.00.  Shipping outside the US is by US Postal Service 
airmail for $15.

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 89 09:12:18 GMT
From:      sl@van-bc.UUCP (Stuart Lynne)
To:        comp.protocols.tcp-ip,comp.unix.xenix
Subject:   Xenix TCP/IP/SLIP Named setup

I'm setting up a SLIP link into another larger TCP/IP network from this
system. 

We're running TCP/IP from Lachman/SCO on SCO 2.3.2 / 386.

I do have things working - sort of. But not too well. 

I'm trying to use a remote namesever (at the other end of the SLIP link),
but it doesn't work too well. For example ping uunet.uu.net doesn't work the
first time, but does after that (we postulate that gethostbyname() is timing
out before named can get the information from the nameserver, but by the
second time we try it has received a reply and cached it).

Anyway, if anyone has any suggestions on how to setup TCP/IP, named, 
etc to run efficently at the far end of a SLIP link I'd be appreciative.

One thing is certain, a permanent SLIP connection does seem to be better
than an intermittent uucp connection.

-- 
Stuart.Lynne@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 89 13:18:06 GMT
From:      tkevans@fallst.UUCP (Tim Evans)
To:        comp.protocols.tcp-ip
Subject:   PC/IP Scorecard--Novice Question

I've been following with interest the PC/IP scorecard postings, but have
a really basic question.  Although it's not clear, it appears that the
scorecard relates to TCP/IP products for DOS PC's.  Is this correct?  If
so, is there similar information for '286 and '386 PC's running UNIX/Xenix?
Or does the scorecard data reflect *NIX products, too?

Thanks.  
-- 
UUCP:  ...!{rutgers|ames|uunet}!mimsy!aplcen!wb3ffv!fallst!tkevans
INTERNET:  tkevans%fallst@wb3ffv.ampr.org
OTHER: ...!attmail!fallst!tkevans
Tim Evans  2201 Brookhaven Court, Fallston, MD  21047   (301) 965-3286

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 89 19:45:18 GMT
From:      randall@uvaarpa.virginia.edu (Randall Atkinson)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re:  TCP/IP on System V/386 & STREAMS

In article <8908051908.AA12163@ucbvax.Berkeley.EDU>,
	 dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) writes:
>There is no standard for mapping TLI calls into TCP operations.  Each
>supplier of SVR3(Streams) TCP is likely to have somewhat different
>interface functionality or calling sequences.

I understand that AT&T UNIX System V Release 4 will provide
tcp/ip support.  I have heard that a Berkeley-style sockets
interface implemented via STREAMS will be provided and I'm
sure that a TLI/STREAMS interface will also be provided.

I think that the System V.4 mapping of TLI calls to
TCP will become a "de facto" standard.  Certainly, I
hope so (in large part because I believe that sockets
'know too much' and want to see the cleaner TLI/STREAMS
approach be more widely used).

What I've heard about V.4 is from what I consider reliable sources, 
but if I'm wrong, I'm sure someone will correct me.

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 89 20:31:47 GMT
From:      leichter@CS.YALE.EDU (Jerry Leichter)
To:        comp.protocols.misc,comp.org.decus,comp.sys.dec,comp.protocols.tcp-ip
Subject:   Re: DECNET anyone?

In article <560@ncrorl.Orlando.NCR.COM>, pquiring@ncrorl.Orlando.NCR.COM (Powell Quiring) writes...
> 
>Does anyone know how to where to get a DECNET port/source?
>An AT&T Streams implementation would be preferable.
> 
>Powell Quiring
>quiring@Orlando.NCR.COM	..!uunet!ncrlnk!ncrorl!pquiring
> 
>Workstations, NCR E&M Orlando
>3200 Lake Emma Rd.
>Lake Mary, FL 32746
> 
>VOICE: (407) 333-9250,     VOICEplus: 656-1219,      FAX: (407) 333-0050

There are several vendors of DECnet implementations for non-DEC machines.
One that comes to mind is Ki Research, or something like that.

Check out any recent issue of the standard DEC-market publications (e.g.,
Digital Review or Digital News); these companies advertise, and vendors that
use their products also advertise.
							-- Jerry

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 89 21:09:23 GMT
From:      timk@NCSA.UIUC.EDU (Tim Krauskopf)
To:        comp.protocols.tcp-ip
Subject:   Re: Mac FTP transfer speeds

Previous discussions of Mac FTP transfer speeds have let the Ethernet
boards off the hook, but ask the question:

why does copying a file time at approx. 150KB/sec and NCSA Telnet time at
50KB/sec with MacTCP, 30KB/sec without MacTCP?

I admit to some software overhead in NCSA Telnet, but have you ever done
the following experiment?  Try disk read sizes of 100B,1K,8K,32K,64K,1024K
and see what the data rates are.  Finder copy uses very large buffers now,
usually as much system memory as it can get its hands on.  The larger the
block, the faster it goes.

Track sizes are getting to be 32-64K range -- remember the Mac II uses
one-to-one interleave, and seek times are still significant overhead.
NCSA Telnet blocks the network 4K (TCP window) at a time, but it does 
8K at a time to disk to save memory.  Try recompiling it with 64K blocking
to disk and let me know how much it improved.

For some reason the system disk cache has enough overhead so that it is
not a cure-all for this problem.


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

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

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 89 21:23:43 GMT
From:      jacob@gore.com (Jacob Gore)
To:        comp.protocols.tcp-ip
Subject:   Re: Western Digital 8003 family


Hello,

I have had some dealings with the WD8003 line and their interoperability.
The theory is that they are identical as far as the software is concerned,
and thus you should be able to for example plug a WD8003S (starlan card)
in and use software designed for the WD8003E (ethernet card).  

Well that is the theory, here is the practice.  I tried the exact experiment
above and it did not work.  I happen to be in a better position than most
to debug what exactly went wrong, so I did.  It turns out that the WD8003
card queues up network packets in a circular queue, Each queue entry has

	1 byte status code
	1 byte pointer to next packet
	2 byte length
	n byte data packet.

It turns out that the WD8003S (starlan card) was at random times returning
a corrupted length field.  It was interesting that the length would only
be corrupted in a certain way.  What the card would do would be to duplicate
the low byte of the length in the high order byte of the length.  For example,
the length 0x50 (80 bytes) would be returned as 0x5050 (20560 bytes).  

What typically happens is that the software would blindly do a copy of 
the packet into some memory buffer.  Of course what happens is that the
copy overflows the buffer and starts writting trash into whatever happens
to follow the software packet buffer.  At this point, a system crash or
hang is almost assured.

I called Western Digital to tell them about my discovery (if they did not
already know), and to see what if anything could be done about it.  After
some digging, I found out that Western Digital did indeed know about this 
bug, but since it could be corrected easily in software, it was not likely
to be fixed anytime soon.

This was all very disappointing, because it would have been very nice to
be able to use the different cards with the same software, and this bug
seemed to rule this out.

But there is hope.  First of all, it is an easy bug to fix.  All that is
ABSOLUTELY necessary is that the software perform a sanity check on the
length the card returns.  Better yet, the software can look for this 
particular kind of corruption and correct it on the fly.

In fact I worked a bit with NCSA Telnet and Stanford's PC/IP and have
versions of both that work.   I gave NCSA a fix and their version 2.3
should work.

An even better solution is now available.  This solution is FTP software's
packet driver.  This is simply an interface spec that allows networking
software for PC's be card independant.  There are versions of NCSA Telnet,
PC/IP available that use the packet driver.  In addition there is even
code that allow SUN's PC-NFS, and novell to use the packet driver.  (most 
is available from omnigate.clarkson.edu in the ka9q directlory)

The nice thing about this is that the Packet driver is a SEPERATE piece
of code from the rest of the application.  Also it is this piece of code
that needs to be modified to perform the software fix.  I believe there
is even a packet driver for the WD8003A (microchannel) and I don't know
how it differs from the WD8003E card, but with the packet driver I really
don't care.

I have a version of the packet driver that will work with the WD8003E 
and WD8003S card.  I will soon tell the people at Clarkson about the
change and hopefully they will incorperate it into the 'official' release.

Anyone wanting more info on the above can contact me at

morrison@accuvax.nwu.edu	(not the account I am posting this from!!)

Vance Morrison
Northwestern Univeristy









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

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 89 02:39:16 GMT
From:      slevy@poincare.geom.umn.edu ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   endless *'s from traceroute

Our SunOS 3.3 system needed another kernel mod for traceroute to work.
In netinet/ip_icmp.c, icmp_input() only hands a few types of incoming
ICMP's to listening sockets -- redirects and echo replies, but *not* the
time-to-live expired or port unreachable errors that traceroute requires.
The effect is just what you found, endless *'s.

If you don't have source, you might try building a kernel with the
ip_icmp.o in uc.msc.umn.edu:~ftp/pub/traceroute.tar.Z... note this is
only for Sun-3's running 3.x (3<=x<=5).

	Stuart Levy, slevy@geom.umn.edu

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 89 04:35:36 GMT
From:      jkp@cs.HUT.FI (Jyrki Kuoppala)
To:        comp.protocols.tcp-ip
Subject:   Re: the worm and internet security

In article <8907280211.AA09340@asylum.sf.ca.us>, romkey@asylum (John Romkey) writes:
>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. 

It's been proposed that security problems like those what the worm
used, whenever found, should first be published on a restricted-access
mailing list as soon as possible.  This mailing list should have all
major Un*x vendors on it, so that they can rush bug-fixes to their
clients as soon as possible.  Then, with for example a three-month or
so delay, this mailing list would be relayed to a Usenet newsgroup.

I think this approach would work quite well.  The knowledge that the
bug will be public knowledge in some months should make the vendors'
support much better.  Perhaps then we wouldn't be seeing all these
various sendmail, ftpd, rcp, rdist, rwall/wall, fingerd, nfs, rexd,
lpr, ptrace, uucp, yp and who knows what else (they're too numerous to
remember already!) security bugs months or even years they've come at
least partly public knowledge.

The Berkeley ucb-fixes list already does a very good job at this -
but apparently it isn't enough, as many vendors seem to neglect the
security fixes which Berkeley puts out.  For example, how many have
fixed the one with rshd and rlogind accepting connections from ports
under 512 ?  It seems that someone has to make public the information
how to use the bug before the vendors believe it.

Also, some way should be found to make vendors to make the
out-of-the-box system even somewhat acceptable.  Especially Sun loses
badly on this.  I think they still have + in their /etc/hosts.equiv.
They have extremely bad manners in other things, too, like that
/etc/utmp is world-writable.  And even after the rwalld / wall bug was
published, apparently they STILL don't plan to change that.  They're
practically asking for trouble.

Perhaps there should be some kind of `security rating' given to an
operating system.  I dont mean ratings like C2 or things like that;
just an estimate on how many known security bugs a system has and if
it is suitable for use in the internet off-the-box or if it needs a
few weeks of debugging with a tight comb to prevent J. Random User on
the internet from getting root access on it in five minutes by reading
the tips from `The History of BSD Unix'.

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

Sounds good.

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

That kind of legislation sounds extremely silly and dangerous to me.
Computers are nothing but a tool.  Why should they be treated any
differently from any other tools in legislation ?  If a person deliberately
causes harm to others - like destroys all data from a police computer
- certainly there already are laws which can be used against this
person.  Of course, some laws about official documents may need to be
changed to cover documents stored on computer systems, but the need
for a separate `computer fraud law' is not clear to me.

Actually, I find the idea of a `computer fraud law' quite disturbing.
If it is made criminal to for example feed wrong information to a
computer, it leads to great reduction of the individual's basic
rights.  As an example, I'm appending the State of Wisconsin Computer
Fraud Law to the end of this message (as a part of a law is hardly any
use).  As I have little experience reading legalese, perhaps I have
misunderstood the law, but to me it seems that there's no mention
about to which purpose the computer system in question is used.  Also,
the headings like `(3) OFFENSES AGAINST COMPUTERS, COMPUTER EQUIPMENT
OR SUPPLIES.' seem quite strange to me - I thought the laws were there
to protect people, not machines (the heading sounds like those you see
in scifi-novels describing societies ruled by computers ;-).

Of course, I can't be sure if the document is real as I've gotten it
via the computer networks, so please tell me if it isn't.

>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

Perhaps there should even be `an internet requirement' of suffucient
security; that is, if a site runs software with all the five-year-old
network bugs unfixed, they're not allowed to be an the internet.  That
way, good will in the net is maintained as random pranksters don't get
access to machines they don't have official accounts to nearly as
easily.  Please note that this shouldn't be extended to administrative
policies, just the security bugs (much like the RFC requirements).  Ah
well, just an idea.

//Jyrki

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

         -- Computer Law - State of Wisconsin Statute --

                    Chapter 293, Laws of 1981

                     943.70 Computer crimes.

(1) DEFINITIONS. In this section:

   (a) "Computer" means an electronic device that performs
       logical, arithmetic and memory functions by manipulating
       electronic or magnetic impulses, and includes all input,
       output, processing, storage, computer software and
       communication facilities that are connected or related to
       a computer in a computer system or computer network.

   (b) "Computer network" means the interconnection of
       communication lines with a computer through remote
       terminals or a complex consisting of 2 or more
       interconnected computers.

   (c) "Computer program" means an ordered set of instructions or
       statements that, when executed by a computer, causes the
       computer to process data.

   (d) "Computer software" means a set of computer programs,
       procedures or associated documentation used in the
       operation of a computer system.

   (dm) "Computer supplies" means punchcards, paper tape,
       magnetic tape, disk packs, diskettes and computer output,
       including paper and microform.

   (e) "Computer system" means a set of related computer
       equipment, hardware or software.

   (f) "Data" means a representation of information, knowledge,
       facts, concepts or instructions that has been prepared or
       is being prepared in a formalized manner and has been
       processed, is being processed or is intended to be
       processed in a computer system or computer network. Data
       may be in any form including computer printouts, magnetic
       storage media, punched cards and as stored in the memory
       of the computer. Data are property.

   (g) "Financial instrument" includes any check, draft, warrant,
       money order, note, certificate of deposit, letter of
       credit, bill of exchange, credit or credit card,
       transaction authorization mechanism, marketable security
       and any computer representation of them.

   (h) "Property" means anything of value, including but not
       limited to financial instruments, information,
       electronically produced data, computer software and
       computer programs.

   (i) "Supporting documentation" means all documentation used in
       the computer system in the construction, clarification,
       implementation, use or modification of  the software or
       data.

(2) OFFENSES AGAINST COMPUTER DATA AND PROGRAMS.

   (a) Whoever willfully, knowingly and without authorization
       does any of the following may be penalized as provided in
       par. (b):

   1.  Modifies data, computer programs or supporting
       documentation.

   2.  Destroys data, computer programs or supporting
       documentation.

   3.  Accesses data, computer programs or supporting
       documentation.

   4.  Takes possession of data, computer programs or supporting
       documentation.

   5.  Copies data, computer programs or supporting
       documentation.

   6.  Discloses restricted access codes or other restricted
       access information to unauthorized person.

   (b) Whoever violates this subsection is guilty of:

   1.  A Class A misdemeanor unless subd. 2, 3 or 4 applies.

   2.  A Class E felony if the offense is committed to defraud or
       to obtain property.

   3.  A Class D felony if the damage is greater than $2,500 or
       if it causes an interruption or impairment of governmental
       operations or public communication, of transportation or
       of a supply of water, gas or other public service.

   4.  A Class C felony if the offense creates a situation of
       unreasonable risk and high probability of death or great
       bodily harm to another.


(3) OFFENSES AGAINST COMPUTERS, COMPUTER EQUIPMENT OR SUPPLIES.

   (a) Whoever willingly, knowingly and without authorization
       does any of the following may be penalized as provided in
       par. (b):

   1.  Modifies computer equipment or supplies that are used or
       intended to be used in a computer, computer system or
       computer network.

   2.  Destroys, uses, takes or damages a computer, computer
       system, computer, network or equipment or supplies used or
       intended to be used in a computer, computer system, or
       computer network.

   (b) Whoever violates this subsection is guilty of:

   1.  A Class A misdemeanor unless sub. 2,3 or 4 applies.

   2. A Class E felony if the offense is committed to defraud or
       obtain property.

   3.  A Class D felony if the damage to the computer, computer
       system, computer network, equipment or supplies is greater
       than $2,500.

   4.  A Class C felony if the offense creates a situation of
       unreasonable risk and high probability of death or great
       bodily harm to another.

                 -- Penalties for Infractions --

939.50(3) Penalties for felonies are as follows:

   (a) For a Class A felony, life imprisonment.

   (b) For a Class B felony, imprisonment not to exceed 20 years.

   (c) For a Class C felony, a fine not to exceed $10,000 or
       imprisonment not to exceed 10 year, or both.

   (d) For a Class D felony, a fine not to exceed $10,000 or
       imprisonment not to exceed 5 year, or both.

   (e) For a Class E felony, a fine not to exceed $10,000 or
       imprisonment not to exceed 2 year, or both.

939.51(3) Penalties for misdemeanors are as follows:

   (a) For a Class A misdemeanor, a fine not to exceed $10,000 or
       imprisonment not to exceed 9 months, or both.

   (b) For a Class B misdemeanor, a fine not to exceed $1,000 or
       imprisonment not to exceed 90 days, or both.

   (c) For a Class C misdemeanor, a fine not to exceed $500 or
       imprisonment not to exceed 30 days, or both.
-- 
Jyrki Kuoppala    Helsinki University of Technology, Finland.
Internet :        jkp@cs.hut.fi           [128.214.3.119]
BITNET :          jkp@fingate.bitnet      Gravity is a myth, the Earth sucks!

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 89 13:41:31 GMT
From:      jeff@ndcheg.cheg.nd.edu (Jeffrey C. Kantor)
To:        comp.protocols.tcp-ip,comp.protocols.appletalk
Subject:   TN3270 using MacTCP?

Having installed MacTCP and the version of NCSA_Telnet that uses the MacTCP
drivers, I'm now wondering if there is a version of tn3270 that uses the
MacTCP drivers.  Does such an animal exist?  Can it be ftp'd from somewhere?

Thanks,

-- 
Jeff Kantor
                                       US Mail:  Dept. of Chemical Engineering
internet: jeff@ndcheg.cheg.nd.edu                University of Notre Dame
    uucp: iuvax!ndmath!ndcheg!jeff               Notre Dame, IN   46556  USA

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 89 16:31:25 GMT
From:      gors@well.UUCP (Gordon Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP socket message interface?


Do you want a message-passing mechanism a la Sys V IPC messages?
(datagram-oriented sockets, but with guaranteed delivery, and correctly
sequenced)?

I have a small library of routines that use datagram (UDP) sockets
and perform the necessary verification, etc. to do THAT. Is that what
you want??

-- 
				{apple, pacbell, hplabs, ucbvax}!well!gors
							gors@well.sf.ca.us
(Doolan) | (Meyer) | (Sierchio) | (Stewart)

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 89 17:52:32 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Re: packet driver for ne1000, ne2000?



the NE1000 card from novell is (was? are they still making/selling them?)
a NAt Semi evaluation card. nat semi made the cards to show off their 
DP8390 chip. they then decided to give the designs to anyone who wanted to
make the cards (and sell the chips). seems like a good idea. several other
comapnies have done basically the same thing: DLink DE-001, Tiara "8-bit"
(i dont know their part name/number). there is a company in Isreal that
built one into the motherboard of a workstation they built. there are more
people jumping on this bandwagon every day.

it has nothing to do with the 3c501 from 3com. 3com uses the same chip in
the 3c503, but it is in no way compatible with the NS eval board.

stev knowles
stev@ftp.com
ftp software
617-246-0900

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 89 19:03:26 GMT
From:      verber@pacific.mps.ohio-state.edu (Mark A. Verber)
To:        comp.protocols.tcp-ip
Subject:   Re: Help with SLIP under SunOS 4.0

Thanks to everyone who responded to my query.  In the end I figured things
out myself (just after posting of course).  The problem with slip_open
being called multiple times was that my shell hadn't let go of the tty
and was still trying to write... sigh.

---mark verber

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 89 19:09:45 GMT
From:      darcy@tci.UUCP (Jeff d'Arcy)
To:        comp.protocols.misc,comp.org.decus,comp.sys.dec,comp.protocols.tcp-ip
Subject:   Re^2: DECNET anyone?

leichter@CS.YALE.EDU (Jerry Leichter):
>There are several vendors of DECnet implementations for non-DEC machines.
>One that comes to mind is Ki Research, or something like that.

Since someone mentioned Ki, I think it's only fair to mention that my
current company (which I'm leaving in a week so don't bother flaming)
also makes a DECnet product for UNIX, with the advantages of a larger
-- 
Jeff d'Arcy		...!uunet!tci!darcy		(508) 443-7311 x283
	TCI is not responsible for my opinions, nor I for theirs

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 89 22:10:53 GMT
From:      bzs@ENCORE.COM (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   the worm and internet security


To some extent I think what the public has just discovered about
networks is:

	"Oh my, someone could just come along with a rock and throw it through
	this glass-stuff?! Someone ought to do something about that, people
	could be hurt!"

	-Barry Shein

Software Tool & Die, Purveyors to the Trade
1330 Beacon Street, Brookline, MA 02146, (617) 739-0202

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Mon, 07 Aug 89 10:54:12 CST
From:      Cheng-ping Chang <IIIG010%TWNMOE10.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   help
Please send me any documents on BSMTP(Batch Simple Mail Transfer Protocol).
Thank you.
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 89 12:03:00 PDT
From:      "MIKE ANELLO" <manello@bi1.simpact.com>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Token Ring on PCs
I'm looking for information on TCP/IP for PCs running MS/DOS that support
IBM compatible Token Ring interfaces. I have Ftp Software's version but
also looking for others. Please send all responses to:

	manello@simpact.com

I will put together a scorecard if anyone is interested.

Mike Anello
Simpact Associates
manello@simpact.com


-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 89 12:56:27 GMT
From:      kwe@bu-cs.bu.edu  (kwe@bu-it.bu.edu (Kent W. England))
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: the worm and internet security
>
>To some extent I think what the public has just discovered about
>networks is:
>
>	"Oh my, someone could just come along with a rock and throw it through
>	this glass-stuff?! Someone ought to do something about that, people
>	could be hurt!"
>
>	-Barry Shein
>

But the glass had been painted to look like brick.
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 89 14:57:41 GMT
From:      amanda@intercon.uu.net (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: Mac FTP transfer speeds

In article <8908052109.AA12473@zaphod.ncsa.uiuc.edu>, timk@NCSA.UIUC.EDU (Tim
Krauskopf) writes:
> NCSA Telnet blocks the network 4K (TCP window) at a time, but it does 
> 8K at a time to disk to save memory.  Try recompiling it with 64K blocking
> to disk and let me know how much it improved.

Actually, it occured to me this weekend that the problem may be a little
more subtle.  Telnet writes out files by using FSWrite--I remember a
discussion a while back about FSWrite, where someone claimed that FSWrite
just calls PBWrite 512 bytes at a time.  I haven't gotten around to
changing the code to just call PBWrite directly, but this might make the
file system a lot happier...

--
Amanda Walker
InterCon Systems Corporation
--
amanda@intercon.uu.net    |    ...!uunet!intercon!amanda

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 89 15:01:20 GMT
From:      chris@SALT.ACC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   LU6.2 over SOCKETS

Morning all,
		I was wondering if anyone has seen/heard of/ knows of a
way to allow LU6.2 communication between two IP hosts using SOCKETS as the
transport mechanism? It certainly doesn't seem like something I'd care to
try but I've had more than a few inquiries about it so there must be interest
somewhere for it. I assume this means two programs that only talk LU6.2
needing to communicate via a TCP socket.
			Thanks in advance,
					Chris VandenBerg
					ACC
					chris@salt.acc.com
					805-963-9431

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 89 15:42:44 GMT
From:      gary@dvnspc1.Dev.Unisys.COM (Gary Barrett)
To:        comp.protocols.tcp-ip
Subject:   Re: Evaluating Network Performance



Right now, I have no way to access ttcp.c source.  Is it possible for
someone to post the source on the net?   

Thanks a lot if you can.


Gary Barrett
Unisys
Devon Engineering Facility
Wayne, Pa.

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 89 15:48:54 GMT
From:      kozel@MILANO.CISCO.COM (Edward R. Kozel)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP socket message interface?


>Has anyone built an IPC interface on top of BSD sockets to do asynchronous
>message passing? Basically, what I want is a library that adds some record
>structure to a TCP stream, so I don't have to deal with socket buffering and
>waiting for input/output to complete. Ideally, I'm looking for something like
>the TOPS-20 IPCF interface (for any of you who's memory goes back that far...)
>that uses TCP sockets. I realize that this wouldn't be terribly difficult to
>implement (though it might be tricky to do it "right"), but I'd rather not have
>to do it myself if someone has already gone to the trouble...Vince,

Vince,
	Check with Len Schlegel at SRI (schlegel@spam.istc.sri.com) for
information on a procedural, non-blocking IPC extension package he's
designed there.

Ed Kozel
cisco Systems

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 89 16:15:33 GMT
From:      cliff@WSU-ENG.ENG.WAYNE.EDU (Cliff Stallings)
To:        comp.protocols.tcp-ip
Subject:   Driver for PC NFS and the Western Digital Microchannel Card

has anyone written (or know of) a driver for PC NFS and Western Digital's 
Microchannel card (WDLAN-EP/A)?
 
  Thanks (in advance) for any replys
 
  Cliff...     cliff@wsu-eng.eng.wayne.edu

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 89 16:54:12 GMT
From:      IIIG010@TWNMOE10.BITNET (Cheng-ping Chang)
To:        comp.protocols.tcp-ip
Subject:   help

Please send me any documents on BSMTP(Batch Simple Mail Transfer Protocol).
Thank you.

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 89 17:15:22 GMT
From:      hwajin@wrs.wrs.com (Hwajin Bae)
To:        comp.sys.att,comp.protocols.tcp-ip
Subject:   Re: tcp-ip problems on the AT&T 6386

In article <1921@currant.bbn.com> ceide@bbn.com (Chantal Eide) writes:
>1. getsockname() makes a socket unusable if called after listen()
> 
>        /* works */                             /* does not work */
>        s = socket(...)                         s = socket(...)
>        bind(s, ...)                            bind(s, ...)
>        getsockname(s, ...)                     listen(s, ...)
>        listen(s, ...)                          getsockname(s, ...)
>                                                /* s is now unusable */
>   Any insights anyone?

The socket implementations for most system V.3 OS's are emulations of
sockets over either TLI (Transport Library Interface) or TPI (Transport 
Provider Interface -- AT&T's specification for STREAMS multiplexing
module in the kernel to service TLI calls, etc.).  TPI state machine
does not allow certain things to happen -- for example,
T_OPTMGMT is not allowed after a connection has been established.
If the 'getsockname' is implemented on top of TLI and use TLI functions
in the order that doesn't conform to the TPI state machine, you will
get an error message.  What kind of error message do you get?
BTW, using internal socket data structure one can retrieve the socket
address immediately if socket calls all implementation directly on top
of TPI module as stream-head interfaces -- it doesn't even have to
go through TPI at all.  So it's my guess that your socket library may
be implemented on top of TLI in some incorrect way in terms of state
transition.

>2. Closing a tcp connection immediately flushes data still in the "pipe".
>   Our application sends a bunch of data, then calls close.  The
>   documentation states that by default sockets are set to "linger" for 45
>   seconds.  We even tried explicitely setting linger on [with
>   setsockopt(s, ... SO_LINGER) (or whatever)], to no avail.  Has anyone
>   dealt with this before?

SO_LINGER option get be set with linger time of zero (l_linger) to effective
tell TCP not to linger -- like 4.2 BSD SO_DONTLINGER option.

-- 
Hwajin Bae
hwajin@wrs.com
...!{uunet, rtech, sun}!wrs!hwajin
Wind River Systems, 1350 Ocean Ave, Emeryville, CA 94608

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 89 17:27:36 GMT
From:      randall@uvaarpa.virginia.edu (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: the worm and internet security

The GAO report was frankly disappointing.  I hope that
the powers that be at DARPA, NSF, et. al. understand 
what happened and why more clearly than the GAO seems
to have.  Moreover, I hope that they apply their own 
knowledge and experience to the problems in network
security rather than just adding "yet another" 
coordinating committee or group or agency as the GAO
seems to suggest.

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 89 19:03:00 GMT
From:      manello@BI1.SIMPACT.COM ("MIKE ANELLO")
To:        comp.protocols.tcp-ip
Subject:   Token Ring on PCs

I'm looking for information on TCP/IP for PCs running MS/DOS that support
IBM compatible Token Ring interfaces. I have Ftp Software's version but
also looking for others. Please send all responses to:

	manello@simpact.com

I will put together a scorecard if anyone is interested.

Mike Anello
Simpact Associates
manello@simpact.com

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 89 19:48:47 GMT
From:      jdp@polstra.UUCP (John D. Polstra)
To:        comp.protocols.tcp-ip
Subject:   Re: the worm and internet security

One of the problems that surfaces over and over in this forum is the
fact that the major vendors don't bother to fix the known security
problems in their products.  The reason they don't fix these problems
is that they don't have much motivation to do so.  I would like to
suggest a way to provide the missing motivation.

Somebody (the DoD, a major university, or an interested member of the
press) ought to organize an annual competition, in which each of the
vendors would try to crack its competitors' systems.  A mini-network
would be set up, and each vendor's tiger team would try to crack as
many other systems in as many ways as possible during some fixed time
interval.  The results would be published openly so that potential
customers could take security issues into account when choosing
vendors.

The vendors would be doubly motivated to keep abreast of all known
security weaknesses.  First, they would be looking for ways to
embarrass the competition.  Second, they would be trying to minimize
their own vulnerability as much as possible.

The press would love it, because security issues sell newspapers these
days.  Also, members of the press IMHO get a charge out of embarrassing
people and (especially) corporations.

There would be no need to openly publish the methods used for breaking
into systems, so the rest of the Internet would not need to worry about
zillions of evil computer hackers suddenly finding out how to mess with
their systems.  On the other hand, the rules could require that vendors
share their successful methods with the manufacturers of the systems
that were defeated by them.  (This could be part of the process of
validating a break-in.)

If the competition were held periodically, say once or twice a year,
then one could also keep track of weaknesses which had been previously
exposed and remained uncorrected.

Comments, anyone?

-- John Polstra               jdp@polstra.UUCP
   Polstra & Co., Inc.        ...{uunet,sun}!practic!polstra!jdp
   Seattle, WA                (206) 932-6482
-- 

-- John Polstra               jdp@polstra.UUCP
   Polstra & Co., Inc.        ...{uunet,sun}!practic!polstra!jdp
   Seattle, WA                (206) 932-6482

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 89 21:56:20 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: the worm and internet security

Slightly less prejudicially (or perhaps reverse-biased):
    "You mean some kid playing ball could could break this glass-stuff?!
Someone ought to ...."

    cheers, map
-------

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Tue 8 Aug 89 13:22:02-PST
From:      KASHTAN@TGV.COM (David L. Kashtan)
To:        tcp-ip@sri-nic.arpa, info-vax@crvax.sri.com, info-gcc@prep.ai.mit.edu
Subject:   A cloud of uncertainty is removed
First, let me apologize for using this mailing list to thank all those
who gave us support and encouragement over the past year.  One year
ago The Wollongong Group filed a Multi-Million dollar lawsuit against
myself, Ken Adelman and TGV Inc.  Although we were very confident in
our position that we had done nothing wrong, just the existance of the
lawsuit and the effort required to fight the lawsuit combined with our
startup of TGV Inc, made for a very stressful year.

Yesterday a judge in Santa Clara County, California, announced his dismissal
of all claims against Ken Adelman and TGV, Inc.  He also dismissed all but
one claim against me.  This morning, in court, The Wollongong Group
voluntarily dismissed that last claim.  As you might expect -- Myself, Ken and
TGV are very pleased at this (expected -- but long overdue) total vindication.

Now that the emotional (and time) demands of this lawsuit are behind us,
it will be a pleasure for all of us at TGV to get back to doing what we
do best -- putting out the best TCP products and services we can possibly
deliver!

David Kashtan
    for Ken Adelman, Stuart Vance and TGV Inc.
-------
-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 89 08:27:07 GMT
From:      HANK@BARILVM.BITNET (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Pc/Ip scorecard

The response has been underwhelming to say the least.  I am going on
vacation of 3 weeks and when I come back I will post a revision 8 if I
receive further updates.

Have a nice summer,
Hank

                         The Pc/Ip Scorecard
                        revision 7: 08/07/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 4.5           | Yes| No |V102| Yes| Yes|100k| 195@cpu | No   |
Clarkson NCSA 2.2TN | No | No |V102| Yes| Yes|150K|   0@    | Yes  |
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.03           | Yes| Yes|V220| Yes| Yes|179k| 400@cpu | Yes  |
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 3.0.1    | No |Xtra| Yes| No | Yes|167k| 395@cpu | Yes  |
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. V220, V240,
          V330, 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  Inter.
            3C501 EXOS205  NI5010 2273A 8003  3C523  PS/2   3C503 NI5210
-----------+-----+--------+------+-----+-----+-----+------+------+------+
Beame      | Yes |  No    |  No  | No  | Yes | No  | No   | Yes  | No
Clarkson   | Yes |  No    |  No  | Yes | Yes | Yes | No   | No   | Yes
Clarkson PD| Yes |  No    |  Yes | No  | Yes | Yes | No   | Yes  | Yes
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

Notes: Clarkson PD refers to the Clarkson Packet Drivers, which are
       different from its Pc/Ip package.

TABLE #2B:

Vendor      3com     WD     Tiara  IBM  D-
            3C505 8003ET/A LANcard TR    Link
-----------+-----+--------+-------+----+-----+
Beame      | No  |  Yes   |  No   | No | No  |
Clarkson   | No  |  No    |  No   | No | No  |
Clarkson PD| No  |  Yes   |  No   | No | No  |
Cornell    |     |        |       |    |     |
CMU        |     |        |       |    |     |
Excelan    |     |        |       |    |     |
FTP        | Yes |  Yes   | Yes   | Yes| Yes |
FUSION     |     |        |       |    |     |
IBM        |     |        |       |    |     |
KA9Q       |     |        |       |    |     |
MIT        |     |        |       |    |     |
NCSA       |     |        |       |    |     |
Stanford   |     |        |       |    |     |
Sun        | Yes |  Yes   |   No  | No | No  |
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| Yes|Xtra| No | No | No | No | No | No |4105|
Clarkson   | Yes| No | No | No |No  | No | Yes| No | No | Yes| No |4010|
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    | Yes| No | No | No | No | No | No | Yes| No | No | No |    |
FTP        | Yes| Yes| Yes| Yes| No | No |Xtra|Xtra| Yes| Yes| No |    |
FTP        | Yes| Yes| Yes| Yes|Xtra| No |Xtra|Xtra| Yes| Yes| No |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 |4014|
Stanford   | No | Yes| Yes| Yes| No | No | No |    | Yes| No | Yes|    |
Sun        | Yes| No | No | No | Yes| No |Xtra| No | Yes| Yes|Xtra| No |
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      |Xtra|Xtra| 25K|
Clarkson   | No |Yes |200K|
Clarkson   |    |    |    |
Cornell    |    |    |    |
CMU        |    |    |    |
Excelan    |    |    | 15K|
FTP        |Xtra|No  | 85K|
FUSION     |    |    |    |
IBM        |    |    |    |
KA9Q       |    |    |    |
MIT        |    |    |    |
NCSA       |    |Yes |    |
Stanford   |    |    |    |
Sun        | No | No | 95K|
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      | Beame@McMaster.CA
Clarkson   | bkc@omnigate.clarkson.edu
Cornell    |
CMU        |
Excelan    |
FTP        | info@ftp.com
FUSION     |
IBM        |
KA9Q       |
MIT        |
NCSA       |
Stanford   |
Sun        | garnold@East.Sun.COM
UB         |
Wollongong |


------------------------------------------------------------------------
Final Notes:

1) FTP Software is OEMed to BICC Data Networks, Fibronics, Proteon,
   cisco, Spider Systems, MICOM-Interlan, Scope, Univation, Western
   Digital, AT&T, Acer, D-Link, IMC Networks, Gateway and HP.
2) Clarkson software is an offshoot of the NCSA product.
3) Sun's PC-NFS is OEMed to Accurate Information Systems, ASCII
   Corporation (KANJI version), BICC Data Networks, Bridge
   Communications, CMC, Eastman Kodak, Honeywell Bull, Intergraph,
   Interleaf, Lachman Associates, Logic Tree, NOCOM AB, Olivetti USA,
   Word Systems Inc.

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 89 09:06:03 GMT
From:      thomas@uplog.se (Thomas Hameenaho)
To:        comp.protocols.tcp-ip
Subject:   IP on X.25


I'm in need of better connections over the Atlantic. We need to be able
to talk to a lot of IP sites in the US.
I've been thinking of using IP on top of X.25, probably running on a Sun.

I need to know if it works and if there is someone in the US that can act
as a gateway between X.25 and the Internet or if there is a better solution.

Znks, 

Thomas.

--
Real life:	Thomas Hameenaho		Email:	thomas@uplog.se
Snail mail:	TeleLOGIC Uppsala AB		Phone:	+46 18 189406
		Box 1218			Fax:	+46 18 132039
		S - 751 42 Uppsala, Sweden

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Tue, 08 Aug 89 11:27:07 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
The response has been underwhelming to say the least.  I am going on
vacation of 3 weeks and when I come back I will post a revision 8 if I
receive further updates.

Have a nice summer,
Hank

                         The Pc/Ip Scorecard
                        revision 7: 08/07/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 4.5           | Yes| No |V102| Yes| Yes|100k| 195@cpu | No   |
Clarkson NCSA 2.2TN | No | No |V102| Yes| Yes|150K|   0@    | Yes  |
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.03           | Yes| Yes|V220| Yes| Yes|179k| 400@cpu | Yes  |
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 3.0.1    | No |Xtra| Yes| No | Yes|167k| 395@cpu | Yes  |
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. V220, V240,
          V330, 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  Inter.
            3C501 EXOS205  NI5010 2273A 8003  3C523  PS/2   3C503 NI5210
-----------+-----+--------+------+-----+-----+-----+------+------+------+
Beame      | Yes |  No    |  No  | No  | Yes | No  | No   | Yes  | No
Clarkson   | Yes |  No    |  No  | Yes | Yes | Yes | No   | No   | Yes
Clarkson PD| Yes |  No    |  Yes | No  | Yes | Yes | No   | Yes  | Yes
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

Notes: Clarkson PD refers to the Clarkson Packet Drivers, which are
       different from its Pc/Ip package.

TABLE #2B:

Vendor      3com     WD     Tiara  IBM  D-
            3C505 8003ET/A LANcard TR    Link
-----------+-----+--------+-------+----+-----+
Beame      | No  |  Yes   |  No   | No | No  |
Clarkson   | No  |  No    |  No   | No | No  |
Clarkson PD| No  |  Yes   |  No   | No | No  |
Cornell    |     |        |       |    |     |
CMU        |     |        |       |    |     |
Excelan    |     |        |       |    |     |
FTP        | Yes |  Yes   | Yes   | Yes| Yes |
FUSION     |     |        |       |    |     |
IBM        |     |        |       |    |     |
KA9Q       |     |        |       |    |     |
MIT        |     |        |       |    |     |
NCSA       |     |        |       |    |     |
Stanford   |     |        |       |    |     |
Sun        | Yes |  Yes   |   No  | No | No  |
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| Yes|Xtra| No | No | No | No | No | No |4105|
Clarkson   | Yes| No | No | No |No  | No | Yes| No | No | Yes| No |4010|
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    | Yes| No | No | No | No | No | No | Yes| No | No | No |    |
FTP        | Yes| Yes| Yes| Yes| No | No |Xtra|Xtra| Yes| Yes| No |    |
FTP        | Yes| Yes| Yes| Yes|Xtra| No |Xtra|Xtra| Yes| Yes| No |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 |4014|
Stanford   | No | Yes| Yes| Yes| No | No | No |    | Yes| No | Yes|    |
Sun        | Yes| No | No | No | Yes| No |Xtra| No | Yes| Yes|Xtra| No |
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      |Xtra|Xtra| 25K|
Clarkson   | No |Yes |200K|
Clarkson   |    |    |    |
Cornell    |    |    |    |
CMU        |    |    |    |
Excelan    |    |    | 15K|
FTP        |Xtra|No  | 85K|
FUSION     |    |    |    |
IBM        |    |    |    |
KA9Q       |    |    |    |
MIT        |    |    |    |
NCSA       |    |Yes |    |
Stanford   |    |    |    |
Sun        | No | No | 95K|
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      | Beame@McMaster.CA
Clarkson   | bkc@omnigate.clarkson.edu
Cornell    |
CMU        |
Excelan    |
FTP        | info@ftp.com
FUSION     |
IBM        |
KA9Q       |
MIT        |
NCSA       |
Stanford   |
Sun        | garnold@East.Sun.COM
UB         |
Wollongong |


------------------------------------------------------------------------
Final Notes:

1) FTP Software is OEMed to BICC Data Networks, Fibronics, Proteon,
   cisco, Spider Systems, MICOM-Interlan, Scope, Univation, Western
   Digital, AT&T, Acer, D-Link, IMC Networks, Gateway and HP.
2) Clarkson software is an offshoot of the NCSA product.
3) Sun's PC-NFS is OEMed to Accurate Information Systems, ASCII
   Corporation (KANJI version), BICC Data Networks, Bridge
   Communications, CMC, Eastman Kodak, Honeywell Bull, Intergraph,
   Interleaf, Lachman Associates, Logic Tree, NOCOM AB, Olivetti USA,
   Word Systems Inc.
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 89 16:10:34 GMT
From:      nobody@mimsy.UUCP (Nobody)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Wollongong TCP/IP and Printer Sharing

I'd like to try and play so TCP-IP software on ibmpc. I have an ibmpc-xt
is there any hardward requirement? Where can I get a demo-copy ?
From: chenn@tame.cs.umd.edu (Jenn-San Peter Chenn)
Path: tame.cs.umd.edu!chenn

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 89 17:10:48 GMT
From:      morrison@accuvax.nwu.edu (Vance Morrison )
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   PCroute 2.0 ($800 IP router) now available

Hello,

Well, at long last, PCroute2.0 is available for anonymous FTP
from accuvax.nwu.edu (129.105.49.1).  Both the executable and
the source can be found in the directory ~ftp/pub/pcroute.

I am planning on talking to uunet to see if I can put the code
there so that people without internet access can get at the code.
So if you can't FTP, please be patient.

Version 2.0 is a big step forward for PCroute.  In particular
SLIP support has now been added.  For those unfamiliar with PCroute
here is a short description.

Vance

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


            PCROUTE - an IP routing program from the IBM PC
                             Vance Morrison
                        morrison@accuvax.nwu.edu

    Traditionally IP routers have been fairly high performance,
expensive machines.  Typically they run about $5000-$10,000 a unit.
Until now a IP router for under $5000 was just about impossible
to get.  Recent developments in PC hardware, however, has made
it possible to convert a PC to an IP router for a TOTAL of $800
a unit.  This price is less that the cost of many ethernet boards
and thus it now makes sense to always use dedicated router to
perform IP gatewaying functions.  

---------------------------------------------------------------------
What is PCroute?

    PCroute is software written for an PC/XT (or AT) or clone that will 
allow it to act as a IP router.   At present the following interfaces
are supported.

        Ethernet - (WD8003E card) (recommeded no more than 4 interfaces)
        Starlan  - (WD8003S card) (up to 6 interfaces)
        Localtalk - (Apple localtalk card for the PC) (1 interface max)
        SLIP      - (COM1..COM4)  (2 interfaces max)

   One of the most common configuration for the router is as an
ethernet-ethernet router, but this is not the only configuration possible.
The software supports up to 6 interfaces of varying types, so many
many configurations are possible.  Exact details on what is possible
is explained in the installation/compilation manual

   In addition to the XT, the only other hardware needed are the
networking cards, which at present run about $225 a piece (for ethernet).  
Since you can buy an XT (10Mhz, without an monitor) for $350, the total
cost for the hardware is $800

---------------------------------------------------------------------
What do I need to install PCroute?

        1) An XT computer (does not need monitor) with a floppy
        2) The proper interface cards
                Ethernet : WD8003E              Ethercard Plus
                Starlan  : WD8003S,WD8003SH     Starcard,Starlink Plus
                Localtalk: Apple localtalk PC card
                SLIP     : COM[1-4] ports

---------------------------------------------------------------------
How Fast is PC route?

    Some may argue that a PC simply is not fast enough to be a
good IP router.  For slow networks (Localtalk SLIP) this is not really
an issue.  For Ethernet it is a real concern.  Luckily, in the case
of Ethernet (and starlan), the Western Digital cards do a lot of the work.  
All the input packet queuing is done by the card, freeing the PC to do the
routing task.   By programming in assembler and optimizing for peak 
efficiency (the main loop has NO procedure calls), the PC is up to the task.  

    Actual tests indicate that that following formula is a worst case 
estimate of the throughput of PCroute on a 4.77Mhz XT (based on actual 
measurments).

        packet_delay = .51 + .00406 * len      msec

   Where 'len' is the length of the packet in bytes.  Thus PCroute has a 
fixed per packet overhead of .51 msec and takes .00406 msec/byte to transfer 
the packet from one network to the other.  
 




    Thus for the largest packet size (1514) we get throughput of 

        packet_delay = .51 + .00406 * 1514 = 6.65 ms
        throughput = len*8/packet_delay = 1.8 Mbit/sec

    For the smallest packet size (64) we get a throughput of

        packet_delay = .51 + .00406 * 64 = .77 ms
        throughput = len*8/packet_delay = .66 Mbit/sec

   If you are going to by the XT needed, please buy a clone (without
a monitor) with a 10Mhz CPU speed (cost < $350).  This will almost
double the throughput measured above.  If you need more speed you can
go with an AT clone and a even faster CPU speed.  Here are some 
actual measurements of packet speeds for some common machines.

                 per packet       per byte     Packet rate    Throughput
                   delay           delay        (64bytes)     (1500 bytes)
-----------------------------------------------------------------------------
4.77 Mhz XT    | .51 msec       .00406 msec     1300 /sec    1.8 Mbits/sec
10 Mhz XT      | .237 msec      .00254 msec     2500 /sec    3.0 Mbits/sec
6 Mhz AT       | .169 msec      .00228 msec     3200 /sec    3.3 Mbits/sec
12 Mhz AT (est)| .100 msec      .00220 msec     4150 /sec    3.5 Mbits/sec
16 Mhz AT      | .050 msec      .00190 msec     5800 /sec    4.1 Mbits/sec

   As you can see, at the high end, the PCrouter can sustain a thoughput
of close to half the BANDWIDTH of a ethernet (remember 5Mbits of sustained 
load is a HEAVY load for an ethernet).  Also remember that this is packets
routed THOUGH the router.  Thus even if 4/10 of the ethernet bandwidth is
being used (that is your ethernet is HEAVILY loaded) and ALL that traffic
is going though the router, PCroute can still keep up.
   
   Note also that the throughput measurements are based on packet delay.
This tends to underestimate the thoughput of the router since it ignores
the fact that there are in fact three processes in the router that are
doing work concerently.  Thus the router can actually handle slightly more
traffic than what the above figure would indicate.

   In addition the Ethernet boards have an on-board 6.5K packet input buffer.
Thus packets that come at the PCrouter too fast for it to process will be 
queued.  This queueing happens on board and can keep up with the maximum
10Mbit/sec bit rate.  Thus the router will start dropping packets only 
after this 6.5K buffer is exhausted.

   Note that since SUN NFS likes to send 8K blocks in fast spurts
this will sometimes cause the router to drop packets (since this is
larger than the input queue buffer size).  If you are running NFS through
the router, I suggest that you set the NFS block size down to 4K for
file systems that are mounted though the router (look for 'rsize' and 
'wsize' in man fstab).  We use NFS quite heavily here at NU and as 
long as rwize and wsize are set to 4K we have no problem. 

---------------------------------------------------------------------
What about SLIP speeds?

    PCroute also supports up to 2 serial lines in addition to the other
interfaces.  These lines can operate at all the common baud rates 
up to 19.2K.  In PCroute with a faster processor (10Mhz XT or an AT clone)
can handle 38.4K or even 57.6K.   All of this using the standard 8250
serial ports.

    Note because PC serial ports interupt the processor on EVERY character
SLIP consumes a fair amount of the CPU.  On a 4.77MHZ XT the interupts 
for two SLIP ports running at 19.2K Baud consume about 1/2 the available 
CPU time.  (actually measurements show that two slip lines running full 
tilt at 19.2K consume slightly less than 1/2 the CPU).  Thus packet delays
will double.  Obviously the situation gets better as CPU speed increases.
On a 12Mhz AT interupts consume less than 1/10 of the CPU.

---------------------------------------------------------------------
What PC route supports?

   PCroute was designed to be a fully functional IP router.  In 
particular it supports

        1) IP routing with Subsets (however the subnet mask
           must begin with 255.255)
        2) Static routing with up to 250 routes.
        3) responds to ICMP echo (ping) 
        4) Sends ICMP TTL, Redirect, Unreachable when appropriate
        5) Fragmentation where necessary
        6) RIP dynamic routing protocol
        7) Up to 6 interfaces of varying types
        8) Error logging using BSD syslog
        9) Optional proxy ARP
        10) Bootp forwarding

Note that although the software supports up to 6 interfaces, the 
total throughput of the router is fixed by the speed of the processor.
For fast boards (ethernet) this gets excessive after 4 interfaces 
are installed.  

---------------------------------------------------------------------
What PC route DOESN'T support?

        1) Ethernet cards besides WD8003E.  It is possible to write
           the driver code for other cards, but I personally have no
           desire to do so.

---------------------------------------------------------------------
Wish List

These are things that I would like to add to PCroute, but it looks like
I will not have the time.

        1) SNMP support.  Everybody wants SNMP support.  Well there is
           nothing that says PCroute can't have it.  I have written the
           code with this support in mind.  In addition, some people at CMU
           have already written the hard part of SNMP and all that would
           be necessary is to graft that code onto the various databases
           inside PCroute.   I think this would take about 1-2 months of
           half time progamming effort.

        2) Any other interface that someone might what (T1 or X.25 for
           example).   PCroute has been designed to make this addition
           relatively simple.

---------------------------------------------------------------------
Hints

        1) We found that the 10Mhz XT clones that Jamco and others sell
           work very well.  One nice feature about these units is their
           BIOS.  By setting the dip switches in the PC, you can tell it
           that there is no Monitor.  This also tells the BIOS not to
           check for a keyboard either.  Thus you don't need to buy either
           the keyboard or the monitor.  Other XT BIOS ALWAYS check for
           the keyboard, and thus you have to plug it in even though you
           never use it.

---------------------------------------------------------------------
Reliability

        The reliability of PCroute has been EXCELLENT.  We have been
        using these routers for months now in ten places with absolutely 
        no failures.   If you wish to PING one for yourself here are some 
        PC routers on our campus

                129.105.49.13
                129.105.1.1
                129.105.7.1

---------------------------------------------------------------------
Comments and Bug reports

        I am interested in finding out what you think of PCroute and
        how well it performs for you.  I am also interested in hearing
        about any problems you have or bugs in the documentation.
        You should send your comments to 
                
                Vance Morrison <morrison@accuvax.nwu.edu>

        Note that since I am not paid to support this software, I can
        not guarantee that I can respond to your problem, but I will
        try.


                                                Vance Morrison
                                                Northwestern University

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 89 17:11:17 GMT
From:      chris@salt.acc.com (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   (none)

All,

In an effort to organize the SNMP demonstration at Interop we
need to know who is planning on having working SNMP-products 
(either full agents or proxies) and
are interested in participating in a demonstration.

We are interested in collecting the names and addresses of all
impelmentations so that they may be summarized in a list available
at the show.  

For technical information/coordination contact:

Karl Auerbach (karl@asylum.sf.ca.us)
Epilogue Technology

and for all the marketing stuff contact:

Gary Krall (gary@salt.acc.com)
Advanced Computer Communications

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 89 21:51:17 GMT
From:      geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   How to get an urgent message to an arbitrary system

One of the questions I am often asked about PC-NFS is "how come
there's no way for me to find out when a particular file server
is going down? Unix users get notified." I point out that (at least
on SunOS) the mechanism used is "rwall", which is an RPC service, and that
for size reasons we can't afford to embed a version of rpc.rwalld in 
PC-NFS. This explanation is reasonable, but unsatisfactory. 

My reaction was to say "let's ask the NIC for a UDP port so that
we can use it to send unsolicited messages to PCs running PC-NFS."
That would certainly do the trick. However, a moment's thought
reveals that the problem is bigger than just PC-NFS. Surprisingly,
there is at present no simple ubiquitous message protocol to fulfil this
function. rwall is fine for SunOS and other ONC licensees, but
what about other systems? Do I have to rely upon SMTP? That's
incompatible with the idea of broadcasting a simple message
such as "The backbone will be down for five minutes at 12:00
to replace a bridge." 

This could be trivially simple or slightly more involved
(but still simple). The trivial approach is to dedicate
a UDP port for unsolicited system messages. Anyone could send one,
in a single datagram, and the listener process would be responsible
for delivering it as seemed appropriate for the system (dialog
box, console message, etc.) A more complete approach would be to
define a formal protocol so that it would be possible to convey
information about the coding of the message, message length (so that
TCP could be used instead) and so forth. [If the spec exceeds
one page, it's too complicated.]

Comments?

Geoff

Geoff Arnold,                              Internet: geoff@East.Sun.COM
PCDS Group, Sun Microsystems Inc.
---------------------------------------------------------------------------
Just think: If Unix had been developed in England, we'd all be using BCPL...

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Wed, 09 Aug 89 08:47:37 CST
From:      IIIG007%TWNMOE10.BITNET@CUNYVM.CUNY.EDU
To:        TCP-IP@NIC.DDN.MIL
Subject:   Looking for SMTP documents
Hello,

Please send me any documents on SMTP(Simple Mail Transfer Protocol).
Thank you very much for your assistance.
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 89 04:03:02 GMT
From:      schwartz@shire.cs.psu.edu (Scott Schwartz)
To:        comp.protocols.tcp-ip
Subject:   Re: How to get an urgent message to an arbitrary system


In article <681@east.East.Sun.COM> Geoff Arnold writes:
| However, a moment's thought
| reveals that the problem is bigger than just PC-NFS. Surprisingly,
| there is at present no simple ubiquitous message protocol to fulfil this
| function. 
 
| Comments?

Zephyr, free from MIT, solves this one.

--
Scott Schwartz		<schwartz@shire.cs.psu.edu>

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Wed, 09 Aug 89 13:13:05 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        geoff@east.sun.com
Cc:        tcp-ip@NIC.DDN.MIL, pgross@nri.reston.va.us
Subject:   Re: How to get an urgent message to an arbitrary system

Geoff:

> Anyway, is anyone working to
> get an RFC out and push for "recommended" or "required" status
> for the protocol?

I'm not aware of any efforts.  If you are seriously interested in seeing
this done, I suggest you contact Phill Gross (pgross@nri.reston.va.us).
As head of the Internet Engineering Task Force, this sort of activity is
his responsibility.  Note that the IETF recently has been restructured to
make it easier to get such RFCs written, issued and blessed -- for something
like this, it could be only a few months.  The next IETF meeting is in
Hawaii (in part to see what Torben Nielsen's been doing in promoting
IP in the Pacific Rim) at the end of October.

Craig
-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Wed, 09 Aug 89 17:27:20 PDT
From:      cire|eric <cire@cisco.com>
To:        tcp-ip@NIC.DDN.MIL
Subject:   DecNet on TR


I know this is perhaps blasphemous so I'll put on my asbestos suit.

As far as I know the only media that DecNet currently runs over is
serial lines and ethernet.  Are there other media that DecNet is being
implemented on?  In particular are there other implementations of
DecNet on Token Ring?  I know that Sun has a Token Ring interface and
Apple is working on one.  Both of these folks have some form of 
potential relationship with DecNet.  So there is some likelihood that
it is being worked on.

Cisco has a DecNet on Token Ring implementation and we would certainly 
like to have it play with the other kids on the block.  I've run into
a number of interesting little details that would need to be agreed on
to accomplish this.

1) Ethernet DecNet interfaces set their hardware address to
   AA00.0400.xxxx (where xxxx is determined by area.node).  This can
   not be used by Token Ring interfaces because it is a Token Ring
   non-specific address.  One possibility is to bit swap all the bytes
   of the address.  This is the recommended practice given by IEEE.
   So the address becomes 5500.2000.yyyy.  Note that AA on ether and
   55 on Token Ring are both Locally Administered addresses.  This is
   important.

   The choice isn't particularly important as long as it is agreed on.
   One other significant detail on this choice is whether we want this
   stuff to operate reasonably over transparent Token Ring-Ethernet
   bridges.  If so then the bit swap is probably the way to go.  I say
   probably because there are significant technical details that would
   need to be solved for such an thing to exist.  Primarily because of
   the bit ordering problems.  These are significant.  I'd recommend that
   we don't worry about Ether to Token Ring transparent bridging.

2) DecNet on Ethernet also uses two multicast address for talking to
   all Nodes and all Routers on this cable.  All Token Ring hardware
   I've seen and all hardware based either on the IBM chipset or TI
   chipset only support a single multicast address (called the Group
   address, not to be confused with the Group bit).  Common practice
   I've seen on Token Ring so far is to use what is called a Functional
   address.  A Functional address is a bit significant address.  Two
   bits would have to be chosen that don't conflict with other uses
   of the Functional addresses.  Currently the following are the ones
   that seem to have gained some solidity:

   NOVELL		C000.0080.0000
   CLNS ESIS all IS	C000.0010.0000
   CLNS ESIS all ES	C000.0008.0000
   all Bridges		C000.0000.0100  **
   NETBIOS		C000.0000.0080
   Config Rpt. Server	C000.0000.0010	* a.k.a. Lan Manager
   Ring Error Monitor	C000.0000.0008	*
   Ring Parameter Srv	C000.0000.0002	*
   Active Monitor	C000.0000.0001	*

	*  = from standard IEEE 802.5
	** = from draft standard IEEE 802.5D (for review only)


   Note that there isn't as far as I know any central authority that
   has responsibility for these bits other than some of the lower ones.
   Those have been set by IEEE and earlier IBM.  The other bits appear
   to be up for grabs.  Like the address in point 1 above, which two bits
   chosen need to be agreed on for interoperability.


Comments?  Also if there is a better place to post this kind of message
please feel free to inform me.  I would say this list has the largest
readership of folks interested in interoperability issues that I know
of.

thanks for you time,

-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
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 89 13:47:39 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   re: the worm and internet security


*Somebody (the DoD, a major university, or an interested member of the
*press) ought to organize an annual competition, in which each of the
*vendors would try to crack its competitors' systems.  A mini-network
*would be set up, and each vendor's tiger team would try to crack as
*many other systems in as many ways as possible during some fixed time
*interval.  The results would be published openly so that potential
*customers could take security issues into account when choosing
*vendors.

*Comments, anyone?


i doubt any of the major vendors would show up, unless they were forced to
somehow, like the goverment requiring all equipment in bids show up at
these "meetings". even then, i am not sure anything would get fixed. i
think instead alot of things would become "non-standard". things like
finger and rcp and rlogin and such would be moved to the "unsupported
networking tape". you probably cant force the big guys to play ball if
they dont want to, and you probably cant organize enough of the customer
base to make them want to.

sorry if i seem pessimistic, but i have been around for this before, and
only seen it work once. (you need to get *only* the engineers together. if
*anyone* else shows up, you should forget it.)

stev knowles
stev@ftp.com
617-246-0900
ftp software

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 89 14:47:37 GMT
From:      IIIG007@TWNMOE10.BITNET
To:        comp.protocols.tcp-ip
Subject:   Looking for SMTP documents

Hello,

Please send me any documents on SMTP(Simple Mail Transfer Protocol).
Thank you very much for your assistance.

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 89 15:18:56 GMT
From:      gary@dvnspc1.Dev.Unisys.COM (Gary Barrett)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Performance,  ttcp.c


I want to thank all of you who were so helpful in giving me hints on
how to get a ttcp.c source file.  I especially want to thank the
gentleman who mailed me the file over UNIX mail.

I am posting this thankyou over Usenet because I've had a devil of a
time trying to get email replies to all who responded to my query.  If
you haven't heard from me, it's not for my lack of trying.

So thanks again!


Gary Barrett 
Unisys
Devon Engineering Facility
Wayne, PA

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 89 15:34:39 GMT
From:      larry@focsys.UUCP (Larry Williamson)
To:        comp.protocols.tcp-ip
Subject:   Should "ping" be restricted to root??


On our System V/386 Unix, ping works only if the effective
user id of ping is root. Is this really necessary?

As a temporary measure, I've chmod'd ping to run as root.

Is this a bad idea?

If it matters, the system is Interactive 386/ix 1.0.6 and
their host based tcp/ip package v1.0.3.

-larry

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 89 15:55:53 GMT
From:      little@SAIC.COM (Mike Little)
To:        comp.protocols.tcp-ip
Subject:   Re: the worm and internet security

John Polstra wrote and suggested an annual security rodeo for major vendors
with visitors and press to record the results.  Winners likely get to bake
the losers through marketing ads.  I'd like to point out a problem with
this scheme:  the systems brought to the competition are not necessarily
those I buy.  One would need to employ a stock car racing analogy, where
some modifications are allowed - change default passwords, locate machine
as "standard" (and what would THAT mean?) host on a network, etc.  At 
some point what becomes allowed is beyond what you or I would do as an
administrator;  at which point the purpose is forgotten in favor of the
competition and the trophies.  However, I agree the approach is time tested.
Competition is an age old method of determination;  perhaps the challenge
here is to determine the appropriate contest(s).

					-Mike

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 89 15:57:35 GMT
From:      louis@aerospace.aero.org (Louis M. McDonald)
To:        comp.protocols.tcp-ip
Subject:   Sockets book(s)

I would like to get into "better" communications programming
using sockets. Does anyone know of some good books on programming
with sockets? The BSD stuff in the manuals is okay to start, but
I would like a more detailed introducton....

Louis McDonald
The Aerospace Corporation

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 89 16:10:04 GMT
From:      gaurang@WSU-ENG.ENG.WAYNE.EDU (Gaurang K. Shah)
To:        comp.protocols.tcp-ip
Subject:   (none)

Sub: remove from relay group
Please remove my name from tcp-ip-relay group.

gaurang@wsu-eng.eng.wayne.edu

thanks...

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 89 16:43:20 GMT
From:      geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
To:        comp.protocols.tcp-ip
Subject:   Re: How to get an urgent message to an arbitrary system

In article <SCHWARTZ.89Aug9000335@shire.cs.psu.edu> schwartz@shire.cs.psu.edu (Scott Schwartz) writes:
>
>In article <681@east.East.Sun.COM> Geoff Arnold writes:
>| However, a moment's thought
>| reveals that the problem is bigger than just PC-NFS. Surprisingly,
>| there is at present no simple ubiquitous message protocol to fulfil this
>| function. 
 
>| Comments?
>
>Zephyr, free from MIT, solves this one.
>Scott Schwartz		<schwartz@shire.cs.psu.edu>

I'll go back and check this out - my memory is that it was still
a bit more complex that I'd like to see. Anyway, is anyone working to
get an RFC out and push for "recommended" or "required" status
for the protocol?

Geoff Arnold,                              Internet: geoff@East.Sun.COM
PCDS Group, Sun Microsystems Inc.
---------------------------------------------------------------------------
Just think: If Unix had been developed in England, we'd all be using BCPL...

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 89 17:13:05 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Re: How to get an urgent message to an arbitrary system


Geoff:

> Anyway, is anyone working to
> get an RFC out and push for "recommended" or "required" status
> for the protocol?

I'm not aware of any efforts.  If you are seriously interested in seeing
this done, I suggest you contact Phill Gross (pgross@nri.reston.va.us).
As head of the Internet Engineering Task Force, this sort of activity is
his responsibility.  Note that the IETF recently has been restructured to
make it easier to get such RFCs written, issued and blessed -- for something
like this, it could be only a few months.  The next IETF meeting is in
Hawaii (in part to see what Torben Nielsen's been doing in promoting
IP in the Pacific Rim) at the end of October.

Craig

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 89 17:19:27 GMT
From:      henry.jpl.nasa.gov!elroy.jpl.nasa.gov!forsight!jato!mars.jpl.nasa.gov!leer@ames.arc.nasa.gov
To:        tcp-ip@NIC.DDN.MIL
Subject:   Multiple Internet Addresses for Single Interface
Is it possible that machine with single interface
can have multiple internet addresses.
I understand that each machine can have multiple addresses 
if it has multiple interfaces.  But when machine have
only one interface, can it have multiple addresses?
Can a network have multiple network numbers?
It seems to be legal according to the IP specification.  
Is this really true? Is there any implementation supporting 
this?

Thanks for any infomation.
-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 89 20:01:37 GMT
From:      matthews@cbnewsm.ATT.COM (john.matthews)
To:        comp.protocols.tcp-ip
Subject:   Where are SNMP tools?

Someone mentioned to me that there some SNMP tools written at CMU or
MIT, but he didn't remember what machines I could get them from.
Can anyone tell me where they are and maybe how useful they are?
Are any of them graphics oriented?
				Thanks in advance,
					John Matthews
					matthews@research.att.com

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 89 20:09:49 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Should "ping" be restricted to root??

In article <525@focsys.UUCP> larry@focsys.UUCP (Larry Williamson) writes:
>On our System V/386 Unix, ping works only if the effective
>user id of ping is root. Is this really necessary?
>As a temporary measure, I've chmod'd ping to run as root.
>Is this a bad idea?

From the source code (which is public domain):

 *	This program has to run SUID to ROOT to access the ICMP socket.

ICMP is connectionless, and reading the ICMP socket gives the caller a
copy of *all* ICMP packets received by the system.  Since it permits
access to packets not necessarily intended for that particular
process, it may only be accessed by root.

It's safe to setuid ping.  It filters out the packets not associated
with the ping, so there is no security problem there.  The only reason
not to would be if you are worried about users wasting net bandwidth
by running lots of pings.  Since there are plenty of other ways to
waste net bandwidth, I wouldn't worry.


Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 89 00:27:20 GMT
From:      cire@CISCO.COM (cire|eric)
To:        comp.protocols.tcp-ip
Subject:   DecNet on TR



I know this is perhaps blasphemous so I'll put on my asbestos suit.

As far as I know the only media that DecNet currently runs over is
serial lines and ethernet.  Are there other media that DecNet is being
implemented on?  In particular are there other implementations of
DecNet on Token Ring?  I know that Sun has a Token Ring interface and
Apple is working on one.  Both of these folks have some form of 
potential relationship with DecNet.  So there is some likelihood that
it is being worked on.

Cisco has a DecNet on Token Ring implementation and we would certainly 
like to have it play with the other kids on the block.  I've run into
a number of interesting little details that would need to be agreed on
to accomplish this.

1) Ethernet DecNet interfaces set their hardware address to
   AA00.0400.xxxx (where xxxx is determined by area.node).  This can
   not be used by Token Ring interfaces because it is a Token Ring
   non-specific address.  One possibility is to bit swap all the bytes
   of the address.  This is the recommended practice given by IEEE.
   So the address becomes 5500.2000.yyyy.  Note that AA on ether and
   55 on Token Ring are both Locally Administered addresses.  This is
   important.

   The choice isn't particularly important as long as it is agreed on.
   One other significant detail on this choice is whether we want this
   stuff to operate reasonably over transparent Token Ring-Ethernet
   bridges.  If so then the bit swap is probably the way to go.  I say
   probably because there are significant technical details that would
   need to be solved for such an thing to exist.  Primarily because of
   the bit ordering problems.  These are significant.  I'd recommend that
   we don't worry about Ether to Token Ring transparent bridging.

2) DecNet on Ethernet also uses two multicast address for talking to
   all Nodes and all Routers on this cable.  All Token Ring hardware
   I've seen and all hardware based either on the IBM chipset or TI
   chipset only support a single multicast address (called the Group
   address, not to be confused with the Group bit).  Common practice
   I've seen on Token Ring so far is to use what is called a Functional
   address.  A Functional address is a bit significant address.  Two
   bits would have to be chosen that don't conflict with other uses
   of the Functional addresses.  Currently the following are the ones
   that seem to have gained some solidity:

   NOVELL		C000.0080.0000
   CLNS ESIS all IS	C000.0010.0000
   CLNS ESIS all ES	C000.0008.0000
   all Bridges		C000.0000.0100  **
   NETBIOS		C000.0000.0080
   Config Rpt. Server	C000.0000.0010	* a.k.a. Lan Manager
   Ring Error Monitor	C000.0000.0008	*
   Ring Parameter Srv	C000.0000.0002	*
   Active Monitor	C000.0000.0001	*

	*  = from standard IEEE 802.5
	** = from draft standard IEEE 802.5D (for review only)


   Note that there isn't as far as I know any central authority that
   has responsibility for these bits other than some of the lower ones.
   Those have been set by IEEE and earlier IBM.  The other bits appear
   to be up for grabs.  Like the address in point 1 above, which two bits
   chosen need to be agreed on for interoperability.


Comments?  Also if there is a better place to post this kind of message
please feel free to inform me.  I would say this list has the largest
readership of folks interested in interoperability issues that I know
of.

thanks for you time,

-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

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 89 01:39:20 GMT
From:      awalker@polyslo.CalPoly.EDU (Alan K Walker)
To:        comp.protocols.tcp-ip
Subject:   Need pointer to Internet ethics



Hi. I need some kind soul to point me to where I might be able
to find some documentation on what you shouldn't allow on
systems connected to the Internet.

Specifically, I am an Admin. of two 386i workstations, currently
on Internet. For obvious reasons I disabled the default capability
of allowing users (anyone) to create their own account. Because
of department politics, I find myself in the position of having
to defend this action with something more than my own word, that
this is a major security breach and should not be allowed on the
network.

Are there any references, papers, archived do's and dont's, or
anything else I could use out there? Thanks muchly for any help!
Please reply by email.
Thanks

Al.

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 89 02:21:50 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   kernel telnet?


	A few years back, sombody (Rick Ace?) was working on implementing
telnet in the kernel.  As I remember, all you had to do was put in some
fairly trivial code to patch a couple of sockets together and check for
IAC's, deferring to the user-level telnet server to deal with these.  It
was supposed to be a major efficiency win, even if it was a layering
violation.  Anybody know whats up with that work lately?
-- 
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"

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 89 02:25:14 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Should "ping" be restricted to root??

In article <26366@news.Think.COM>, barmar@think.COM (Barry Margolin) writes:
> 
> It's safe to setuid ping. ... I wouldn't worry.
> 
> Barry Margolin
> Thinking Machines Corp.
> barmar@think.com
> {uunet,harvard}!think!barmar


While on balance ping seems too useful to restrict, it is only fair to
mention that `ping -f <broadcast>` is a handy way to melt the wire.  If a
bad guy does not have a ping with -f, then
`repeat 100 eval "ping <broadcast> > /dev/null &"` is as good.

Unless you've changed things to not respond to ICMP echo requests to
broadcast addresses.


Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Aug 89 10:19 MST
From:      Terry Wimmer <WIMMER@rvax.ccit.arizona.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   RE: Token Ring on PCs
Mike Anello  Manello@Simpact.com

Yes!  I'm interested in the final scorecard.  Please post to this list or
send to:
	Wimmer@arizrvax   or
	Wimmer@rvax.arizona.edu

Thanks

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 89 14:27:00 EST
From:      "RXZ" <rxz@stc10.ctd.ornl.gov>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   TCP-IP E-mail list
Please add rutledge@msr.epm.ornl.gov to the TCP-IP e-mail list.

Thank You,
Ron Rutledge, M/S 7038
Martin Marietta Energy Systems
P.O. Box 2003
Oak Ridge, TN 37831-7038

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 89 09:44:34 GMT
From:      hollandm@prlhp1.prl.philips.co.uk (Martin Holland)
To:        comp.protocols.tcp-ip,comp.sys.ibm.pc
Subject:   Micom NTS100 Terminal server remote admin


I have just upgraded some Micom NTS100 terminal servers with V3.0 of
NTS/TCP.  I am now having trouble with remote administration from a PC
running PC/TCP.  I  administer all the terminal servers over the
ethernet, from a PC and it always worked in the past. I keep a database
of all the terminal server parameters on a PC.
I have connected a loopback connector to one of the NTS100 ports and
connected to that port over ethernet from the PC.  I have monitored the
ethernet with an HP analyser.  With this setup I would expect everything
I type on the PC to be packetised and sent to the terminal server. It
would then be looped-back and packetised and returned to the PC. 
Looking at the packets sent to the NTS100 I can see the correct data
edmbeded in them, however, the returned packet contains nothing
recognisable as the same data.
You can't do remote admin from our IBM mainframe either even though you
can with V2.0 NTS/TCP.  The remote admin mode only works from another
NTS100 or certain UNIX machines.
Has anyone any ideas what is wrong and perhaps can suggest a cure.


-- 
Martin C. Holland       Internal e/mail: HOLLANDM@PHIRHV1
Philips Research Labs.  External e/mail: HOLLANDM@prl.philips.co.uk
Redhill, Surrey. U.K.
Tel: 0293 785544

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 89 14:57:47 GMT
From:      wayne@gollum.UUCP (wayne hutchinson)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Needed: TCP/IP for OS/2

I'm interested in finding a version of TCP/IP to run with OS/2.
The folks at FTP Software told me on 8/9/89 that a socket library for
OS/2 would be available this Fall. Is is currently available anywhere else ?


Wayne L. Hutchinson
wayne@gollum.Columbia.NCR.COM
Advanced Systems Development
NCR Corporation - E&M Columbia

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 89 15:48:49 GMT
From:      chenn@tame.cs.umd.edu (Jenn-San Peter Chenn)
To:        comp.protocols.tcp-ip
Subject:   Re: Novell and TCP/IP


 I would like to make more infomation about tcp/ti on ibmpc. With or 
W/O Novell. What HW or SW do I need? Who is selling them ? Thank you.

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 89 16:49:18 GMT
From:      jjr@nandi.ESD.3Com.COM (Janardan Ramesh)
To:        comp.protocols.tcp-ip
Subject:   "tnlib: Net telnet utility library (Reposting)



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

From jjr Fri Aug  4 10:30:00 1989
To: tcp-ip@nic.ddn.mil
Subject: tnlib: New telnet utility library(?)

I understand that this library was done by Van Jacobson recently. Is it
available for annonymous FTP anywhere? I am looking for it to develop
some applications. I would appreciate any information on the
availability of this library for annonymous FTP. 

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

J. Ramesh
jjr@nandi.ESD.3com.COM

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 89 17:05:37 GMT
From:      beame@maccs.dcss.mcmaster.ca (Carl Beame)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: How to get an urgent message to an arbitrary system

In article <681@east.East.Sun.COM> geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
>One of the questions I am often asked about PC-NFS is "how come
>there's no way for me to find out when a particular file server
>is going down? Unix users get notified." I point out that (at least
>on SunOS) the mechanism used is "rwall", which is an RPC service, and that
>for size reasons we can't afford to embed a version of rpc.rwalld in 
>PC-NFS. This explanation is reasonable, but unsatisfactory. 
>
>
>Comments?
>

Since we implemented a rwalld in our BWNFS (PC based NFS client), I checked
to see how much memory it takes. Not counting the initialization code, (which
is not resident in memory), it takes 192 (decimal) bytes. 
But I guess if you write in C it takes a lot more :-)

- Carl Beame
  Beame@McMaster.CA

P.S: Geoff, does the new PC-NFS come with a fixed version of rpc.lockd for
     Sun OS4.0.1  ?

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 89 17:19:00 GMT
From:      WIMMER@RVAX.CCIT.ARIZONA.EDU (Terry Wimmer)
To:        comp.protocols.tcp-ip
Subject:   RE: Token Ring on PCs

Mike Anello  Manello@Simpact.com

Yes!  I'm interested in the final scorecard.  Please post to this list or
send to:
	Wimmer@arizrvax   or
	Wimmer@rvax.arizona.edu

Thanks

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 89 17:27:15 GMT
From:      adelman@TGV.COM (Kenneth Adelman)
To:        comp.protocols.tcp-ip
Subject:   Re: DecNet on TR

> I know this is perhaps blasphemous so I'll put on my asbestos suit.

    At least my answer will be less blasphemous...

> As far as I know the only media that DecNet currently runs over is
> serial lines and ethernet.  Are there other media that DecNet is being
> implemented on?

    Yes.  As part of our MultiNet (VMS TCP/IP) product we encapsulate
DECnet packets in IP datagrams.  This lets you run DECnet over the
wide variety of devices supported by IP, and across wide-area networks
which only support IP.

    At SRI we even run DECnet over IP over an ethernet because we have
Interlan cards in our 750 and 780 and by layering DECnet over IP we
don't need to buy DEC ethernet cards (for you non-DECies, DECnet/VAX
only supports DEC's own ethernet cards).

						    Kenneth Adelman
						    TGV

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 89 19:27:00 GMT
From:      rxz@STC10.CTD.ORNL.GOV ("RXZ")
To:        comp.protocols.tcp-ip
Subject:   TCP-IP E-mail list

Please add rutledge@msr.epm.ornl.gov to the TCP-IP e-mail list.

Thank You,
Ron Rutledge, M/S 7038
Martin Marietta Energy Systems
P.O. Box 2003
Oak Ridge, TN 37831-7038

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 89 19:55:15 GMT
From:      gors@well.UUCP (Gordon Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: LU6.2 over SOCKETS

In general, SNA Services are implemented on top of the IP layer, rather
than the TCP/UDP layer.  This is because SNA has its own transport
mechanisms, including multiplexing of NAUs and LUs streams.

This, of course, includes the LU6.2 (Application level) Host-Host 
facility.

-- 
				{apple, pacbell, hplabs, ucbvax}!well!gors
							gors@well.sf.ca.us
(Doolan) | (Meyer) | (Sierchio) | (Stewart)

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 89 19:58:18 GMT
From:      gors@well.UUCP (Gordon Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: Sockets book(s)


Sun's documentation on sockets, contained in the IPC Primer section
of whatever manual it's in, is exemplary.  It gives a good explanation
of the UNIX domain and IN domain sockets, connection- and connectionless-
oriented sockets, and provides useful examples.


-- 
				{apple, pacbell, hplabs, ucbvax}!well!gors
							gors@well.sf.ca.us
(Doolan) | (Meyer) | (Sierchio) | (Stewart)

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 89 20:42:24 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Sun RARP doesn't follow RFC 903

I was playing around at parsing the random RARP packets our 386i (SunOS 4.0)
generates, and found that it wasn't using either of the "ar$op" values
defined in RFC 903 for RARP (it defines 3 and 4, the 386i sends 5).  While
I understand "why" in general terms (what else is new), I am somewhat
interested in knowing what 5 "officially" means (and 6, if they send it also).
"YP request" and "YP reply", perhaps?

jbvb

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 89 21:43:46 GMT
From:      neerma@cod.NOSC.MIL (Merle A. Neer)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip.ibmpc
Subject:   advice on software

At NOSC, we are building tcp/ip clients/servers and have used
at one time or other both Network Research Corp. FUSION and
now CMC TCP/IP for PC, DOS.  We are now interested in using
a different TCP/IP possibly public domain.  It is frustrating
when commercial packages dont work and changes arent made thus
a public domain where source is available might be the answer or
another  alternative is a : PRODUCT THAT WORKS!

We're also pitching our 3C505 cards and thinking of WD8003.

It seems most people use these commercial TCP/IPs to telnet
and ftp around; i.e. they dont build clients/servers so they
never encounter the bugs.  We do.  Our servers/clients are
heavy users; they need lots of connections, lots of buffers,
a tcp that does what the spec says, and preferably a tcp that
lets the user application know how the connection is doing,
but one thats bug free would at least be a starting point.

So, what I would like to hear is advice from those that have
had experience building client/servers on what software to
go after.  In particular, I am interested in the version of
KA9Q that comes with a socket library interface for developing
applications.  We have an earlier version that is not.  Others
on this list have referred to the problem: it comes with a
makefile that makes net.exe.  net.exe has telnet, ftp, etc.
We dont want all that we just want tcp/ip.  

Has anyone, by the way, had a favorable experience building
client/servers on a tcp/ip package of any sort?

Thanks,

Merle

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 89 00:08:00 GMT
From:      gaf@uucs1.UUCP (gaf)
To:        comp.protocols.tcp-ip
Subject:   Seeking references for IP routing


Not being an Internet site, this subject is blurry to me (and perhaps to
others in similar situations).  How does one establish a TCP connection with
a process on another machine which is reachable (only) by some means other
than Ethernet (e.g.  X.25, SLIP, etc)?  I assume that from the program's
point of view it is the same as establishing a connection over an Ethernet. 
That is, it does the same socket() & connect() calls. 

How does the connection get routed though?  What config files are involved?
How are such things administered?

I'd be happy if someone could point me at reference material on the subject,
or at least dispell any illusions I may be suffering from.
-- 
Guy Finney					It's that feeling of deja-vu
UUCS inc.   Phoenix, Az				all over again.
ncar!noao!asuvax!hrc!uucs1!gaf	sun!sunburn!gtx!uucs1!gaf

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Aug 89 09:04:43 CST
From:      IIIG007%TWNMOE10.BITNET@CUNYVM.CUNY.EDU
To:        TCP-IP@NIC.DDN.MIL
Subject:   Thank all of you!!
I have already got enough information about SMTP by now. I am very
appreciate for your assistance. Thank all of you again!
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Aug 89 11:41:57 EDT
From:      BDK@UNB.CA
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: PCroute 2.0 ($800 IP router) now available
This looks very interesting. How can we get a copy if we are not
on the internet and do not have access to anonymous FTP? We are on
BITNET though.
Brian Kaye
University of New Brunswick
> Hello,
>
> Well, at long last, PCroute2.0 is available for anonymous FTP
> from accuvax.nwu.edu (129.105.49.1).  Both the executable and
> the source can be found in the directory ~ftp/pub/pcroute.
>
> I am planning on talking to uunet to see if I can put the code
> there so that people without internet access can get at the code.
> So if you can't FTP, please be patient.
>
> Version 2.0 is a big step forward for PCroute.  In particular
> SLIP support has now been added.  For those unfamiliar with PCroute
> here is a short description.
>
> Vance
>
> ----------------------------------------------------------------
>
>
>            PCROUTE - an IP routing program from the IBM PC
>                             Vance Morrison
>                        morrison@accuvax.nwu.edu
>
>    Traditionally IP routers have been fairly high performance,
> expensive machines.  Typically they run about $5000-$10,000 a unit.
> Until now a IP router for under $5000 was just about impossible
> to get.  Recent developments in PC hardware, however, has made
> it possible to convert a PC to an IP router for a TOTAL of $800
> a unit.  This price is less that the cost of many ethernet boards
> and thus it now makes sense to always use dedicated router to
> perform IP gatewaying functions.
>
> ---------------------------------------------------------------------
> What is PCroute?
>
>    PCroute is software written for an PC/XT (or AT) or clone that will
> allow it to act as a IP router.   At present the following interfaces
> are supported.
>
>        Ethernet - (WD8003E card) (recommeded no more than 4
> interfaces) Starlan  - (WD8003S card) (up to 6 interfaces)
>        Localtalk - (Apple localtalk card for the PC) (1 interface max)
>        SLIP      - (COM1..COM4)  (2 interfaces max)
>
>   One of the most common configuration for the router is as an
> ethernet-ethernet router, but this is not the only configuration
> possible. The software supports up to 6 interfaces of varying types,
> so many many configurations are possible.  Exact details on what is
> possible is explained in the installation/compilation manual
>
>   In addition to the XT, the only other hardware needed are the
> networking cards, which at present run about $225 a piece (for
> ethernet). Since you can buy an XT (10Mhz, without an monitor) for
> $350, the total cost for the hardware is $800
>
> ---------------------------------------------------------------------
> What do I need to install PCroute?
>
>        1) An XT computer (does not need monitor) with a floppy
>        2) The proper interface cards
>                Ethernet : WD8003E              Ethercard Plus
>                Starlan  : WD8003S,WD8003SH     Starcard,Starlink Plus
>                Localtalk: Apple localtalk PC card
>                SLIP     : COM[1-4] ports
>
> ---------------------------------------------------------------------
> How Fast is PC route?
>
>    Some may argue that a PC simply is not fast enough to be a
> good IP router.  For slow networks (Localtalk SLIP) this is not really
> an issue.  For Ethernet it is a real concern.  Luckily, in the case
> of Ethernet (and starlan), the Western Digital cards do a lot of the
> work. All the input packet queuing is done by the card, freeing the PC
> to do the routing task.   By programming in assembler and optimizing
> for peak efficiency (the main loop has NO procedure calls), the PC is
> up to the task.
>    Actual tests indicate that that following formula is a worst case
> estimate of the throughput of PCroute on a 4.77Mhz XT (based on actual
> measurments).
>
>        packet_delay = .51 + .00406 * len      msec
>
>   Where 'len' is the length of the packet in bytes.  Thus PCroute has
> a fixed per packet overhead of .51 msec and takes .00406 msec/byte to
> transfer the packet from one network to the other.
>
>
>
>
>
>    Thus for the largest packet size (1514) we get throughput of
>
>        packet_delay = .51 + .00406 * 1514 = 6.65 ms
>        throughput = len*8/packet_delay = 1.8 Mbit/sec
>
>    For the smallest packet size (64) we get a throughput of
>
>        packet_delay = .51 + .00406 * 64 = .77 ms
>        throughput = len*8/packet_delay = .66 Mbit/sec
>
>   If you are going to by the XT needed, please buy a clone (without
> a monitor) with a 10Mhz CPU speed (cost < $350).  This will almost
> double the throughput measured above.  If you need more speed you can
> go with an AT clone and a even faster CPU speed.  Here are some
> actual measurements of packet speeds for some common machines.
>
>                 per packet       per byte     Packet rate
> Throughput delay           delay        (64bytes)     (1500 bytes)
> ----------------------------------------------------------------------
> 4.77 Mhz XT    | .51 msec       .00406 msec     1300 /sec    1.8
> Mbits/sec 10 Mhz XT      | .237 msec      .00254 msec     2500 /sec
> 3.0 Mbits/sec 6 Mhz AT       | .169 msec      .00228 msec     3200
> /sec    3.3 Mbits/sec 12 Mhz AT (est)| .100 msec      .00220 msec
> 4150 /sec    3.5 Mbits/sec 16 Mhz AT      | .050 msec      .00190 msec
>    5800 /sec    4.1 Mbits/sec
>   As you can see, at the high end, the PCrouter can sustain a
> thoughput of close to half the BANDWIDTH of a ethernet (remember
> 5Mbits of sustained load is a HEAVY load for an ethernet).  Also
> remember that this is packets routed THOUGH the router.  Thus even if
> 4/10 of the ethernet bandwidth is being used (that is your ethernet is
> HEAVILY loaded) and ALL that traffic is going though the router,
> PCroute can still keep up.
>   Note also that the throughput measurements are based on packet
> delay. This tends to underestimate the thoughput of the router since
> it ignores the fact that there are in fact three processes in the
> router that are doing work concerently.  Thus the router can actually
> handle slightly more traffic than what the above figure would
> indicate.
>   In addition the Ethernet boards have an on-board 6.5K packet input
> buffer. Thus packets that come at the PCrouter too fast for it to
> process will be queued.  This queueing happens on board and can keep
> up with the maximum 10Mbit/sec bit rate.  Thus the router will start
> dropping packets only after this 6.5K buffer is exhausted.
>
>   Note that since SUN NFS likes to send 8K blocks in fast spurts
> this will sometimes cause the router to drop packets (since this is
> larger than the input queue buffer size).  If you are running NFS
> through the router, I suggest that you set the NFS block size down to
> 4K for file systems that are mounted though the router (look for
> 'rsize' and 'wsize' in man fstab).  We use NFS quite heavily here at
> NU and as long as rwize and wsize are set to 4K we have no problem.
>
> ---------------------------------------------------------------------
> What about SLIP speeds?
>
>    PCroute also supports up to 2 serial lines in addition to the other
> interfaces.  These lines can operate at all the common baud rates
> up to 19.2K.  In PCroute with a faster processor (10Mhz XT or an AT
> clone) can handle 38.4K or even 57.6K.   All of this using the
> standard 8250 serial ports.
>
>    Note because PC serial ports interupt the processor on EVERY
> character SLIP consumes a fair amount of the CPU.  On a 4.77MHZ XT the
> interupts for two SLIP ports running at 19.2K Baud consume about 1/2
> the available CPU time.  (actually measurements show that two slip
> lines running full tilt at 19.2K consume slightly less than 1/2 the
> CPU).  Thus packet delays will double.  Obviously the situation gets
> better as CPU speed increases. On a 12Mhz AT interupts consume less
> than 1/10 of the CPU.
> ---------------------------------------------------------------------
> What PC route supports?
>
>   PCroute was designed to be a fully functional IP router.  In
> particular it supports
>
>        1) IP routing with Subsets (however the subnet mask
>           must begin with 255.255)
>        2) Static routing with up to 250 routes.
>        3) responds to ICMP echo (ping)
>        4) Sends ICMP TTL, Redirect, Unreachable when appropriate
>        5) Fragmentation where necessary
>        6) RIP dynamic routing protocol
>        7) Up to 6 interfaces of varying types
>        8) Error logging using BSD syslog
>        9) Optional proxy ARP
>        10) Bootp forwarding
>
> Note that although the software supports up to 6 interfaces, the
> total throughput of the router is fixed by the speed of the processor.
> For fast boards (ethernet) this gets excessive after 4 interfaces
> are installed.
>
> ---------------------------------------------------------------------
> What PC route DOESN'T support?
>
>        1) Ethernet cards besides WD8003E.  It is possible to write
>           the driver code for other cards, but I personally have no
>           desire to do so.
>
> ---------------------------------------------------------------------
> Wish List
>
> These are things that I would like to add to PCroute, but it looks
> like I will not have the time.
>
>        1) SNMP support.  Everybody wants SNMP support.  Well there is
>           nothing that says PCroute can't have it.  I have written the
>           code with this support in mind.  In addition, some people at
> CMU have already written the hard part of SNMP and all that would
>           be necessary is to graft that code onto the various
> databases inside PCroute.   I think this would take about 1-2 months
> of half time progamming effort.
>
>        2) Any other interface that someone might what (T1 or X.25 for
>           example).   PCroute has been designed to make this addition
>           relatively simple.
>
> ---------------------------------------------------------------------
> Hints
>
>        1) We found that the 10Mhz XT clones that Jamco and others sell
>           work very well.  One nice feature about these units is their
>           BIOS.  By setting the dip switches in the PC, you can tell
> it that there is no Monitor.  This also tells the BIOS not to
>           check for a keyboard either.  Thus you don't need to buy
> either the keyboard or the monitor.  Other XT BIOS ALWAYS check for
>           the keyboard, and thus you have to plug it in even though
> you never use it.
>
> ---------------------------------------------------------------------
> Reliability
>
>        The reliability of PCroute has been EXCELLENT.  We have been
>        using these routers for months now in ten places with
> absolutely no failures.   If you wish to PING one for yourself here
> are some PC routers on our campus
>
>                129.105.49.13
>                129.105.1.1
>                129.105.7.1
>
> ---------------------------------------------------------------------
> Comments and Bug reports
>
>        I am interested in finding out what you think of PCroute and
>        how well it performs for you.  I am also interested in hearing
>        about any problems you have or bugs in the documentation.
>        You should send your comments to
>
>                Vance Morrison <morrison@accuvax.nwu.edu>
>
>        Note that since I am not paid to support this software, I can
>        not guarantee that I can respond to your problem, but I will
>        try.
>
>
>                                                Vance Morrison
>                                                Northwestern University
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Aug 89 13:15 CDT
From:      Michael Stack                                    <A01MES1%NIU.BITNET@UICVM.uic.edu>
To:        Internet TCP/IP List Submissions         <TCP-IP@SRI-NIC.ARPA>
Subject:   Re: the worm and internet security
> One of the problems that surfaces over and over in this forum is the
> fact that the major vendors don't bother to fix the known security
> problems in their products.  The reason they don't fix these problems
> is that they don't have much motivation to do so. ...

The problem is much more difficult than that:

   KEEP THE NETWORKS OPEN.  Virtually all of the people involved in a
   network are basically well-meaning and careful.  The challenge is
   protecting them and the system from the tiny number who are
   malicious or foolish.  Making it impossible for the latter to carry
   out their nefarious activities might seriously inconvenience
   everyone else.  We must seek out ways of controlling aberrant
   activities without impeding communication.

                                          James H. Morris
                                          Professor of Computer Science
                                          Carnegie Mellon University
                                          from CACM, June 1989, p 661

Needless to say, the above is taken from a very long letter and must
be considered as taken out of context.  Nonetheless, it is an expression
of the view that too much security can be a barrier to convenient use of
computer networks.  As it relates to the problem of fixing security holes,
I suspect that this view is a much greater obstacle than vendor motivation.


Michael Stack
Northern Illinois University
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Aug 89 14:41:48 CST
From:      Cheng-ping Chang <IIIG010%TWNMOE10.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Thank all of you!!
Hello,

I have already got enough information about BSMTP by now. I am very
appreciate your kind assistance. Thank all of you again!!
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Aug 89 17:46:59 CDT
From:      texbell!neisse!root@att.att.com
To:        tcp-ip@sri-nic.arpa
Subject:   Please remove my name from the tcp-ip-relay group


Thanks,

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 89 14:04:46 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Re: pcroute 2.0 ($800 ip router) now available

please get a copy of this and leave in on pennzoil. thanx


UID: 2073
From tcp-ip-RELAY@NIC.DDN.MIL  Thu Aug 10 22:49:24 1989
Received: by vax.ftp.com 
	id AA06735; Thu, 10 Aug 89 22:49:24 EDT
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 8 Aug 89 11:07:56 PDT
Received: by ucbvax.Berkeley.EDU (5.61/1.37)
	id AA04964; Tue, 8 Aug 89 10:40:31 -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: 8 Aug 89 17:10:48 GMT
From: mailrus!accuvax.nwu.edu!morrison@tut.cis.ohio-state.edu  (Vance Morrison )
Organization: Northwestern Univ. Evanston, Il.
Subject: PCroute 2.0 ($800 IP router) now available
Message-Id: <1017@accuvax.nwu.edu>
Sender: tcp-ip-relay@NIC.DDN.MIL
To: tcp-ip@NIC.DDN.MIL

Hello,

Well, at long last, PCroute2.0 is available for anonymous FTP
from accuvax.nwu.edu (129.105.49.1).  Both the executable and
the source can be found in the directory ~ftp/pub/pcroute.

I am planning on talking to uunet to see if I can put the code
there so that people without internet access can get at the code.
So if you can't FTP, please be patient.

Version 2.0 is a big step forward for PCroute.  In particular
SLIP support has now been added.  For those unfamiliar with PCroute
here is a short description.

Vance

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


            PCROUTE - an IP routing program from the IBM PC
                             Vance Morrison
                        morrison@accuvax.nwu.edu

    Traditionally IP routers have been fairly high performance,
expensive machines.  Typically they run about $5000-$10,000 a unit.
Until now a IP router for under $5000 was just about impossible
to get.  Recent developments in PC hardware, however, has made
it possible to convert a PC to an IP router for a TOTAL of $800
a unit.  This price is less that the cost of many ethernet boards
and thus it now makes sense to always use dedicated router to
perform IP gatewaying functions.  

---------------------------------------------------------------------
What is PCroute?

    PCroute is software written for an PC/XT (or AT) or clone that will 
allow it to act as a IP router.   At present the following interfaces
are supported.

        Ethernet - (WD8003E card) (recommeded no more than 4 interfaces)
        Starlan  - (WD8003S card) (up to 6 interfaces)
        Localtalk - (Apple localtalk card for the PC) (1 interface max)
        SLIP      - (COM1..COM4)  (2 interfaces max)

   One of the most common configuration for the router is as an
ethernet-ethernet router, but this is not the only configuration possible.
The software supports up to 6 interfaces of varying types, so many
many configurations are possible.  Exact details on what is possible
is explained in the installation/compilation manual

   In addition to the XT, the only other hardware needed are the
networking cards, which at present run about $225 a piece (for ethernet).  
Since you can buy an XT (10Mhz, without an monitor) for $350, the total
cost for the hardware is $800

---------------------------------------------------------------------
What do I need to install PCroute?

        1) An XT computer (does not need monitor) with a floppy
        2) The proper interface cards
                Ethernet : WD8003E              Ethercard Plus
                Starlan  : WD8003S,WD8003SH     Starcard,Starlink Plus
                Localtalk: Apple localtalk PC card
                SLIP     : COM[1-4] ports

---------------------------------------------------------------------
How Fast is PC route?

    Some may argue that a PC simply is not fast enough to be a
good IP router.  For slow networks (Localtalk SLIP) this is not really
an issue.  For Ethernet it is a real concern.  Luckily, in the case
of Ethernet (and starlan), the Western Digital cards do a lot of the work.  
All the input packet queuing is done by the card, freeing the PC to do the
routing task.   By programming in assembler and optimizing for peak 
efficiency (the main loop has NO procedure calls), the PC is up to the task.  

    Actual tests indicate that that following formula is a worst case 
estimate of the throughput of PCroute on a 4.77Mhz XT (based on actual 
measurments).

        packet_delay = .51 + .00406 * len      msec

   Where 'len' is the length of the packet in bytes.  Thus PCroute has a 
fixed per packet overhead of .51 msec and takes .00406 msec/byte to transfer 
the packet from one network to the other.  
 




    Thus for the largest packet size (1514) we get throughput of 

        packet_delay = .51 + .00406 * 1514 = 6.65 ms
        throughput = len*8/packet_delay = 1.8 Mbit/sec

    For the smallest packet size (64) we get a throughput of

        packet_delay = .51 + .00406 * 64 = .77 ms
        throughput = len*8/packet_delay = .66 Mbit/sec

   If you are going to by the XT needed, please buy a clone (without
a monitor) with a 10Mhz CPU speed (cost < $350).  This will almost
double the throughput measured above.  If you need more speed you can
go with an AT clone and a even faster CPU speed.  Here are some 
actual measurements of packet speeds for some common machines.

                 per packet       per byte     Packet rate    Throughput
                   delay           delay        (64bytes)     (1500 bytes)
-----------------------------------------------------------------------------
4.77 Mhz XT    | .51 msec       .00406 msec     1300 /sec    1.8 Mbits/sec
10 Mhz XT      | .237 msec      .00254 msec     2500 /sec    3.0 Mbits/sec
6 Mhz AT       | .169 msec      .00228 msec     3200 /sec    3.3 Mbits/sec
12 Mhz AT (est)| .100 msec      .00220 msec     4150 /sec    3.5 Mbits/sec
16 Mhz AT      | .050 msec      .00190 msec     5800 /sec    4.1 Mbits/sec

   As you can see, at the high end, the PCrouter can sustain a thoughput
of close to half the BANDWIDTH of a ethernet (remember 5Mbits of sustained 
load is a HEAVY load for an ethernet).  Also remember that this is packets
routed THOUGH the router.  Thus even if 4/10 of the ethernet bandwidth is
being used (that is your ethernet is HEAVILY loaded) and ALL that traffic
is going though the router, PCroute can still keep up.
   
   Note also that the throughput measurements are based on packet delay.
This tends to underestimate the thoughput of the router since it ignores
the fact that there are in fact three processes in the router that are
doing work concerently.  Thus the router can actually handle slightly more
traffic than what the above figure would indicate.

   In addition the Ethernet boards have an on-board 6.5K packet input buffer.
Thus packets that come at the PCrouter too fast for it to process will be 
queued.  This queueing happens on board and can keep up with the maximum
10Mbit/sec bit rate.  Thus the router will start dropping packets only 
after this 6.5K buffer is exhausted.

   Note that since SUN NFS likes to send 8K blocks in fast spurts
this will sometimes cause the router to drop packets (since this is
larger than the input queue buffer size).  If you are running NFS through
the router, I suggest that you set the NFS block size down to 4K for
file systems that are mounted though the router (look for 'rsize' and 
'wsize' in man fstab).  We use NFS quite heavily here at NU and as 
long as rwize and wsize are set to 4K we have no problem. 

---------------------------------------------------------------------
What about SLIP speeds?

    PCroute also supports up to 2 serial lines in addition to the other
interfaces.  These lines can operate at all the common baud rates 
up to 19.2K.  In PCroute with a faster processor (10Mhz XT or an AT clone)
can handle 38.4K or even 57.6K.   All of this using the standard 8250
serial ports.

    Note because PC serial ports interupt the processor on EVERY character
SLIP consumes a fair amount of the CPU.  On a 4.77MHZ XT the interupts 
for two SLIP ports running at 19.2K Baud consume about 1/2 the available 
CPU time.  (actually measurements show that two slip lines running full 
tilt at 19.2K consume slightly less than 1/2 the CPU).  Thus packet delays
will double.  Obviously the situation gets better as CPU speed increases.
On a 12Mhz AT interupts consume less than 1/10 of the CPU.

---------------------------------------------------------------------
What PC route supports?

   PCroute was designed to be a fully functional IP router.  In 
particular it supports

        1) IP routing with Subsets (however the subnet mask
           must begin with 255.255)
        2) Static routing with up to 250 routes.
        3) responds to ICMP echo (ping) 
        4) Sends ICMP TTL, Redirect, Unreachable when appropriate
        5) Fragmentation where necessary
        6) RIP dynamic routing protocol
        7) Up to 6 interfaces of varying types
        8) Error logging using BSD syslog
        9) Optional proxy ARP
        10) Bootp forwarding

Note that although the software supports up to 6 interfaces, the 
total throughput of the router is fixed by the speed of the processor.
For fast boards (ethernet) this gets excessive after 4 interfaces 
are installed.  

---------------------------------------------------------------------
What PC route DOESN'T support?

        1) Ethernet cards besides WD8003E.  It is possible to write
           the driver code for other cards, but I personally have no
           desire to do so.

---------------------------------------------------------------------
Wish List

These are things that I would like to add to PCroute, but it looks like
I will not have the time.

        1) SNMP support.  Everybody wants SNMP support.  Well there is
           nothing that says PCroute can't have it.  I have written the
           code with this support in mind.  In addition, some people at CMU
           have already written the hard part of SNMP and all that would
           be necessary is to graft that code onto the various databases
           inside PCroute.   I think this would take about 1-2 months of
           half time progamming effort.

        2) Any other interface that someone might what (T1 or X.25 for
           example).   PCroute has been designed to make this addition
           relatively simple.

---------------------------------------------------------------------
Hints

        1) We found that the 10Mhz XT clones that Jamco and others sell
           work very well.  One nice feature about these units is their
           BIOS.  By setting the dip switches in the PC, you can tell it
           that there is no Monitor.  This also tells the BIOS not to
           check for a keyboard either.  Thus you don't need to buy either
           the keyboard or the monitor.  Other XT BIOS ALWAYS check for
           the keyboard, and thus you have to plug it in even though you
           never use it.

---------------------------------------------------------------------
Reliability

        The reliability of PCroute has been EXCELLENT.  We have been
        using these routers for months now in ten places with absolutely 
        no failures.   If you wish to PING one for yourself here are some 
        PC routers on our campus

                129.105.49.13
                129.105.1.1
                129.105.7.1

---------------------------------------------------------------------
Comments and Bug reports

        I am interested in finding out what you think of PCroute and
        how well it performs for you.  I am also interested in hearing
        about any problems you have or bugs in the documentation.
        You should send your comments to 
                
                Vance Morrison <morrison@accuvax.nwu.edu>

        Note that since I am not paid to support this software, I can
        not guarantee that I can respond to your problem, but I will
        try.


                                                Vance Morrison
                                                Northwestern University

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 89 14:25:00 GMT
From:      hughes@silver.bacs.indiana.edu
To:        comp.protocols.tcp-ip
Subject:   Re: the worm and internet security


/* Written  2:48 pm  Aug  7, 1989 by jdp@polstra.UUCP in silver:comp.protocols.tcp-ip */
One of the problems that surfaces over and over in this forum is the
fact that the major vendors don't bother to fix the known security
problems in their products.  The reason they don't fix these problems
is that they don't have much motivation to do so.  I would like to
suggest a way to provide the missing motivation.

Somebody (the DoD, a major university, or an interested member of the
press) ought to organize an annual competition, in which each of the
vendors would try to crack its competitors' systems.  A mini-network
would be set up, and each vendor's tiger team would try to crack as
many other systems in as many ways as possible during some fixed time
interval.  The results would be published openly so that potential
customers could take security issues into account when choosing
vendors.

The vendors would be doubly motivated to keep abreast of all known
security weaknesses.  First, they would be looking for ways to
embarrass the competition.  Second, they would be trying to minimize
their own vulnerability as much as possible.

The press would love it, because security issues sell newspapers these
days.  Also, members of the press IMHO get a charge out of embarrassing
people and (especially) corporations.

There would be no need to openly publish the methods used for breaking
into systems, so the rest of the Internet would not need to worry about
zillions of evil computer hackers suddenly finding out how to mess with
their systems.  On the other hand, the rules could require that vendors
share their successful methods with the manufacturers of the systems
that were defeated by them.  (This could be part of the process of
validating a break-in.)

If the competition were held periodically, say once or twice a year,
then one could also keep track of weaknesses which had been previously
exposed and remained uncorrected.

Comments, anyone?

-- John Polstra               jdp@polstra.UUCP
   Polstra & Co., Inc.        ...{uunet,sun}!practic!polstra!jdp
   Seattle, WA                (206) 932-6482
-- 

-- John Polstra               jdp@polstra.UUCP
   Polstra & Co., Inc.        ...{uunet,sun}!practic!polstra!jdp
   Seattle, WA                (206) 932-6482
/* End of text from silver:comp.protocols.tcp-ip */

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 89 14:42:00 GMT
From:      hughes@silver.bacs.indiana.edu
To:        comp.protocols.tcp-ip
Subject:   Re: the worm and internet security


jdp@polstra.UUCP writes:

> One of the problems that surfaces over and over in this forum is the
> fact that the major vendors don't bother to fix the known security
> problems in their products.  The reason they don't fix these problems
> is that they don't have much motivation to do so.  I would like to
> suggest a way to provide the missing motivation.
>
> Somebody (the DoD, a major university, or an interested member of the
> press) ought to organize an annual competition, in which each of the
> vendors would try to crack its competitors' systems.  A mini-network
> would be set up, and each vendor's tiger team would try to crack as
> many other systems in as many ways as possible during some fixed time
> interval.  The results would be published openly so that potential
> customers could take security issues into account when choosing
> vendors.
> ...

I see your point, but I have a few comments.

First, this assumes that the "tiger teams" would each stand on
equal footing, which is probably not the case.  If this approach
were to be taken, a more effective approach might be to have
an impartial third party try to break each system.

Second, I know people who are excellent at breaking programs, yet 
are not very good at designing or implementing programs.  And an 
operating system is, after all, just a collection of programs.

Third, and to me more important, I think this type of
competition would do more harm than good.  We can motivate
others by rewarding or punishing them, and there is a place
for both.  But to rely more on punishing will certainly
take the heart out of the industry...which is already suffering
enough from fierce and greedy competition.

In other words...shouldn't our motivation as programmers
to produce a quality product be coming more from an
internal inspiration, rather than from a fear of what
others will say or think?

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

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 89 15:00:13 GMT
From:      pat@grebyn.com (Pat Bahn)
To:        comp.protocols.tcp-ip
Subject:   Re: MacII FTP speeds on Ethernet

In article <3258@internal.Apple.COM> desnoyer@apple.com (Peter Desnoyers) writes:
>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 
>
>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).  
>


 Barry You are doing approximately 3.5 times faster on your FTP then I
was doing on a benchmark we had using a mac2x and a mac2.  We felt the
bottleneck was the disks as using an excelan LANALYZER we observed
peak performance in excess of 100kbs so the card and memory were capable
of quite a good clip.  The only parameters that might help may involve
increasing the memory buffers FTP uses.  We had notoriously slow disks
on our system.  Unless you want to buy some disks there is nothing
you can do.  AS an experiment get some software for a turbo disk
(quasidisk, whatever) and see if that helps you out.  I  would not
expect you to ever beat 100kbs though.  If you do let me know I am very
interested.  

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



I have one caveat, the work I was doing involved AUX on both systems.  
I would expect MACOS stuff to run faster as the system is more mature
and has a better design.  But I would look at the disks as the problem.
We felt the bus and memory were more then fast enough and that the
CPU had the throughput.  But we saw a large variance as we changed
disks around.  I did not have the documentation on how to tune FTP
so I don't know what was possible, but I don't think the MACTCP or
the file system is it.

Pat

B
Stuff follows to defeat inews.  type n to escape.








A
A
A
A
A



















-- 
=============================================================================
Pat @ grebyn.com  | If the human mind was simple enough to understand,
301-948-8142      | We'd be too simple to understand it.   
=============================================================================

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 89 15:04:43 GMT
From:      IIIG007@TWNMOE10.BITNET
To:        comp.protocols.tcp-ip
Subject:   Thank all of you!!

I have already got enough information about SMTP by now. I am very
appreciate for your assistance. Thank all of you again!

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 89 15:41:06 GMT
From:      geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: How to get an urgent message to an arbitrary system

In article <1989Aug10.170537.1823@maccs.dcss.mcmaster.ca> beame@maccs.dcss.mcmaster.ca (Carl Beame) writes:
>Since we implemented a rwalld in our BWNFS (PC based NFS client), I checked
>to see how much memory it takes. Not counting the initialization code, (which
>is not resident in memory), it takes 192 (decimal) bytes. 

I presume you're not including the portmapper in this total? We don't
run a portmapper in PC-NFS, since we don't normally run any RPC based servers
on the PC. (After all, we don't want to undercut our workstation
business :^) "rwall" uses a pmap_rmtcall to contact rpc.rwalld, but
to be correct you have to handle both direct and indirect calls, don't
you?

Also, are you doing the any duplicate filtering?

>But I guess if you write in C it takes a lot more :-)

I'm sure you know that none of the resident PC-NFS code is written in C...


Geoff Arnold,                              Internet: geoff@East.Sun.COM
PCDS Group, Sun Microsystems Inc.
---------------------------------------------------------------------------
Just think: If Unix had been developed in England, we'd all be using BCPL...

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 89 17:02:02 GMT
From:      hoodr@csusac.uucp (Robert Hood)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   RARP server

I am looking for a RARP server to be used with packages lke NCSA Telnet
and Stanford's PCIP.  Does anybody know where I can find one of these
for UNIX.  Thanks in advance...


		Robert Hood
		California State University: Sacramento
		UUCP: ..ucdavis!cssexb!hoodr

-- 
------------------------------------------------------------------------
  Robert Hood   -- California State University:  Sacramento (ooooh...)
    UUCP:  ..csusac!hoodr
    BITNet:  NCTP003@CCS.CSUSCC.CALSTATE.EDU

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 89 18:15:00 GMT
From:      A01MES1@NIU.BITNET (Michael Stack)
To:        comp.protocols.tcp-ip
Subject:   Re: the worm and internet security

> One of the problems that surfaces over and over in this forum is the
> fact that the major vendors don't bother to fix the known security
> problems in their products.  The reason they don't fix these problems
> is that they don't have much motivation to do so. ...

The problem is much more difficult than that:

   KEEP THE NETWORKS OPEN.  Virtually all of the people involved in a
   network are basically well-meaning and careful.  The challenge is
   protecting them and the system from the tiny number who are
   malicious or foolish.  Making it impossible for the latter to carry
   out their nefarious activities might seriously inconvenience
   everyone else.  We must seek out ways of controlling aberrant
   activities without impeding communication.

                                          James H. Morris
                                          Professor of Computer Science
                                          Carnegie Mellon University
                                          from CACM, June 1989, p 661

Needless to say, the above is taken from a very long letter and must
be considered as taken out of context.  Nonetheless, it is an expression
of the view that too much security can be a barrier to convenient use of
computer networks.  As it relates to the problem of fixing security holes,
I suspect that this view is a much greater obstacle than vendor motivation.


Michael Stack
Northern Illinois University

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 89 20:41:48 GMT
From:      IIIG010@TWNMOE10.BITNET (Cheng-ping Chang)
To:        comp.protocols.tcp-ip
Subject:   Thank all of you!!

Hello,

I have already got enough information about BSMTP by now. I am very
appreciate your kind assistance. Thank all of you again!!

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 89 22:49:58 GMT
From:      jkrey@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   re: Sun RARP doesn't follow RFC 903

jvbv:

ARP opcodes 5, 6, and 7 are assigned to dynamic reverse ARP.

Joyce.

DYNAMIC REVERSE ARP

Assignments:

Operation Code (op)

         5  DRARP-Request
         6  DRARP-Reply
         7  DRARP-Error

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 89 23:15:49 GMT
From:      jkp@cs.HUT.FI (Jyrki Kuoppala)
To:        comp.protocols.tcp-ip
Subject:   Re: How to get an urgent message to an arbitrary system

In article <681@east.East.Sun.COM>, geoff@hinode (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
>My reaction was to say "let's ask the NIC for a UDP port so that
>we can use it to send unsolicited messages to PCs running PC-NFS."
>That would certainly do the trick. However, a moment's thought
>reveals that the problem is bigger than just PC-NFS. Surprisingly,
>there is at present no simple ubiquitous message protocol to fulfil this
>function. rwall is fine for SunOS and other ONC licensees, but
>what about other systems? Do I have to rely upon SMTP? That's
>incompatible with the idea of broadcasting a simple message
>such as "The backbone will be down for five minutes at 12:00
>to replace a bridge." 

Not exactly what you need, but to get experience with SunRPC, I wrote
a program called `rmsg' which can be used to send short (a few lines)
messages to users on other machines.  The program works quite like the
bitnet send / tell feature, except that it directly contacts the
remote machine with tcp/ip instead of using user-mode links as it's
done on bitnet.

Rmsg is available for anonymous ftp on sauna.hut.fi (128.214.3.119) in
the directory pub/tcpip.  Due to disk malfunctioning, anon ftp is not
in use currently, but hopefully will be again in a few days.

I haven't yet looked at zephyr, but I suppose it has more features and
solves the problem of inter-user communications well.  However, rmsg
might be simpler to install.  I hope it's useful to someone; we've
been using it locally for some time, and it's nice because it's not as
much a hassle as a full-screen application like talk is.

Enjoy,

//Jyrki

Here's a README file from rmsg:

This directory contains a messaging system which can be used to send
write-like messages to logged-on users.  The system can cross machine
boundaries, so if another machine has the rmsgd program running, you can
send messages to users on it.

The system also allows bitnet virtual machine-like 'virtual users'
to whom any user can send messages and they can answer the messages.
The rmsgd server makes this possible by allowing a command 'exec' in a users
.msgconf file, and whenever the user receives a message this command is
executed and the message is piped to it.

It is also possible to log incoming and outgoing messages and resend previous
sent message.  You can specify a file to which the last (or every) incoming
message will be stored.

Using the programs:
-------------------

Rmsgd:

Rmsgd is the server program for the system.  It should be started by root,
but for now it works even if started by ordinary users, even though
some capabilities are disabled for security reasons (that is, exec and 
logging of incoming messages, since that would be done by the user-id
who started rmsgd and not the receiver).

At any time, there should be only one rmsgd running.  It doesn't do any harm
to have several rmsgds other than the newly-started servers unmap the
previous and thus the previous servers are unusable.

The server should be named 'rmsgd' to have it start as a daemon.


Rmsg:

Rmsg is the client end of the system.  Rmsg is used by ordinary users
to send messages.  For example, rmsg foo@bar hello there !  ^D would
send a message 'hello there !' to user foo at machine bar.  By
default, rmsg stores the last outgoing message in the user's home
directory in the file .msgout.  Then msg -r user@machine can be used
to resend the message.  Message is normally read from standard input
until EOF.

Configuration:
--------------

The messages system has many options which the user can set by making
a file '.msgconf' in her home directory and placing various command in it.
Read the manual page for rmsg for more information.
-- 
Jyrki Kuoppala    Helsinki University of Technology, Finland.
Internet :        jkp@cs.hut.fi           [128.214.3.119]
BITNET :          jkp@fingate.bitnet      Gravity is a myth, the Earth sucks!

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 89 00:15:09 GMT
From:      morrison@accuvax.nwu.edu (Vance Morrison )
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   PCbridge: Super cheap bridge ($800-$1500) software available

Hello again,

From the person who brought you PCroute we now bring you PCbridge.
Software that turns a PC into a Ethernet-Ethernet bridge.  So for
all you DECNET, IPX, ISO people, here is you chance to join the fun.

PCbridge is availble from accuvax.nwu.edu (129.105.49.1) in the
directory ~ftp/pub/pcroute/bridge.  The tar file contains both the
bridge executable and source.  

As you might expect, bridging places more demands on the CPU so you
really should have an AT class machine unless your load is light.  
Here are the vital statistics

		 Packet Filtering    Packet Forwarding (60byte)
		    rate (PPS)		    rate (PPS)
    -------------------------------------------------------------
    4.77Mhz XT	    4080 PPS		    1677 PPS
    10Mhz XT (est)  8000 PPS		    3000 PPS
    16Mhz AT	    26214 PPS		    5832 PPS

While packet filtering is independant of packet size, packet forwarding
is dependent on the size of the packet.   The packets I used where the
smallest ethernet packet (60 bytes).  
		
For comparison purposes a low end Retix bridge costs $2000 (actually
more if you want thin ethernet) and has a forwarding rate of 6000 PPS
and a filtering rate of 10000 PPS.  

See the readme.doc on accuvax to see where I got these numbers.

As you can see, the XT clones are fine under low load, but you probably
don't need a bridge unless you net is loaded already, so an XT as a 
bridge is dubious.  On the other hand, a 16Mhz compares well, and can
be but together for about $1400.   

(What I really need is a 16 bit memory mapped cheap ethernet card, then
the thing would really fly).

So, if this is useful to you, let me know.  Also If any of you think
a bridge-router is useful let me know.  I have the code to make PCroute
a bridge-router, but I have never taken the time to test it enough.
(We are an IP only house).   Maybe I will take a crack at it if enough
people think it is useful.

Vance

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 89 21:07:38 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun RARP doesn't follow RFC 903

In article <8908112249.AA00352@akamai.isi.edu> jkrey@VENERA.ISI.EDU writes:
>ARP opcodes 5, 6, and 7 are assigned to dynamic reverse ARP.

Is this documented in an RFC?  I don't recall it.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 89 22:56:03 GMT
From:      db@helium.East.Sun.COM (David Brownell)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun RARP doesn't follow RFC 903

In article <8908102042.AA04628@vax.ftp.com> jbvb@VAX.FTP.COM (James Van Bokkelen) writes:

> I was playing around at parsing the random RARP packets our 386i (SunOS 4.0)
> generates, and found that it wasn't using either of the "ar$op" values
> defined in RFC 903 for RARP (it defines 3 and 4, the 386i sends 5).  While
> I understand "why" in general terms (what else is new), I am somewhat
> interested in knowing what 5 "officially" means (and 6, if they send it also).
> "YP request" and "YP reply", perhaps?

The RFC for this is still sitting in folk's internal review piles ... looks like the
IETF isn't the only process that needs streamlining to get RFCs out faster!  (:-)

Here's a capsule summary of Dynamic RARP, in fact the original proposal with minor
updates.  The RFC is more precise, accurate, and explanatory, and I certainly hope
it gets out to Jon Postel soon.

    We propose a version of RARP to solve a specific problem arising when a
    system which is unknown on a given network tries to join it:  there is
    no way for it to acquire an protocol address unless the system has been
    configured on the network by a third party.

    In our preferred model, systems may join or rejoin an arbitrary network
    without advance network preparation.  Specific examples might be workstations
    being installed or relocated in a building housing multiple Ethernets.
    Joining a network must not ** require ** any administrative action.

    To solve the problem of acquiring an address, we propose a protocol with
    the working name of "Dynamic Reverse Address Resolution Protocol" (DRARP).
    The packet format and (on Ethernet and IEEE 802 networks) ethertype are
    those of RARP (hence the opcodes include those of ARP and RARP), but three
    new opcodes are defined:  DRARP_REQUEST, DRARP_RESPONSE, and DRARP_ERROR:

	-   DRARP_REQUEST (opcode 5) packets are exactly like RARP_REQUEST
	    packets except for the operation code.  They are a request to
	    return either the published target protocol address corresponding
	    to the target hardware address field, or one allocated on a temporary
	    basis.
	    
	-   DRARP_RESPONSE (opcode 6) packets are responses to DRARP_REQUEST packets
	    containing protocol addresses which are not guaranteed to be valid
	    for more than an hour.  These could be reallocated to another system
	    after this time elapses, unless a separate protocol is used to ensure
	    that this reallocation does not occur.  (These addresses are termed
	    "transient".)

	    All DRARP servers on a network segment must return the same value
	    in a DRARP_RESPONSE packet.

	-   RARP_RESPONSE (opcode 4) packets may be sent in response to
	    DRARP_REQUEST packets if the address returned is not subject
	    to automatic reallocation.  (These are termed "persistent".
	    They get reallocated too, only LOTS more slowly.)

	-   DRARP_ERROR (opcode 7) packets may be sent in response to DRARP_REQUESTs.
	    The format is that of a RARP_RESPONSE, but the the target protocol
	    address field is instead used to encode an error status describing
	    why no target protocol address is being returned.  The codes are all
	    one byte long (on the grounds that all protocol addresses are at
	    least one byte long).  The currently defined codes are:

		DRARPERR_RESTRICTED (1) --
		    This network does not support dynamic address assignment.
		    The response is definitive; the network is controlled
		    so that no other response to a DRARP_REQUEST is possible
		    right now.

		DRARPERR_NOADDRESSES (2) --
		    This network supports dynamic address assignment, but
		    all available network (or subnetwork) protocol addresses
		    have been allocated, so that none can be allocated now. 

		DRARPERR_SERVERDOWN (3) --
		    A transient failure to allocate an address, due for
		    example to a server being unavailable, or allocation just
		    taking a long time.

		DRARPERR_MOVED (4) --
		    Analagous to DRARPERR_RESTRICTED, but with the additional
		    information that the system is recognized as being on the
		    "wrong" network.

		DRARPERR_FAILURE (5) --
		    Some other failure mode resulted in an inability to 
		    allocate an address.

    Assigning addresses using DRARP_RESPONSE requires a network-wide (or
    subnetwork-wide) address assignment authority.  If such an authority
    is not present, no DRARP_RESPONSE or DRARP_ERROR packets may be sent.

    DRARP servers should probe for spurious DRARP servers, which might have
    a different idea of who the address authority is.  They should probe
    the a network to see if a transient address has been seized by some
    other system before handing it out in a DRARP_RESPONSE packet.

There are a number of problems that are tough in an Internet
environment.  For example, who really has authority to allocate
addresses?  AppleTalk only has transient addressing, but in IP land you
can have addresses persistently allocated by someone you didn't think
really had the authority.  You can't rely on nameserver reverse address
lookups on today's networks.

Also, handing out transient addresses emphasizes what a bad idea it is
to base any security scheme on IP addresses.  On an Ethernet, you can
always just grab an address you've got a hankering for, but somehow
sites still keep trusting IP addresses.  (Steve Bellovin's article had
a lot more issues than just ARP level theft.)

There are a number of additional problems to solve if you want to do any
sort of automatic system installation, beyond just getting an address:

    - Getting the subnet mask.
    - Getting a router address.
    - Persistently allocating a name.
    - Sometimes, allocating server resources.
    - Selecting one of several zones on the network.
    - Proving the system's identity on the network.
    - Determining the system's role in running the network.

AppleTalk standardizes the routing stuff (netmask, router address), but it's
missing the concepts of persistent network entities and systems interdependence
(a diskless client and its server).  A system's whole network configuration
changes every time it joins a network.  Which isn't an inaccurate model for
most systems (i.e. ones with disks), but it ends up looking rather Byzantine
after a while even there.

For the Sun386i, we got automatic system installation up to the point
that you could do manual setup of one machine (the "master server") and the
rest could either automatically install themselves, or tell you why they
couldn't.  It interoperates with existing networks ("just turn it off").


    David Brownell			dbrownell@sun.com
    Sun Entry Systems Software		sun!suneast!db
    Billerica, MA

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 89 02:06:38 GMT
From:      beame@maccs.dcss.mcmaster.ca (Carl Beame)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: How to get an urgent message to an arbitrary system

In article <693@east.East.Sun.COM> geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
>
>I presume you're not including the portmapper in this total? We don't
>run a portmapper in PC-NFS, since we don't normally run any RPC based servers
>on the PC. (After all, we don't want to undercut our workstation
>business :^) "rwall" uses a pmap_rmtcall to contact rpc.rwalld, but
>to be correct you have to handle both direct and indirect calls, don't
>you?

 We didn't implement the portmapper in total, we have a port 111 interrupt
routine which checks for pmap_rmtcall to rwalld. The 179 bytes refers to
all code (including portmapper check routine) which is resident and executed
above the UDP level.

>
>Also, are you doing the any duplicate filtering?
>
 No.
>
>I'm sure you know that none of the resident PC-NFS code is written in C...
>
  No I didn't know that.

-  Carl Beame
   Beame@McMaster.CA

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 89 07:19:00 GMT
From:      WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   PCroute 2.0 ($800 IP router) now available

Brian,

PCroute 2.0 is available via ANONYMOUS FTP from WSMR-SIMTEL20.ARMY.MIL
as the file PD1:<MSDOS.NETWORK>PCROUT20.ARC.  Many of the PC-specific
utilities announced to this list are also available here, including
the NCSA and KA9Q files.

BITNET users on this side of the Atlantic can request files from
LISTSERV@RPIECS or LISTSERV@NDSUVM1.  These servers cache files from
our MSDOS, CP/M, and MISC collections.  EARN servers, in turn, cache
files from the RPIECS cache.

EARN users should make their file requests through the closest TRICKLE
server on the European continent: AWIWUW11 (Austria), BANUFS11
(Belgium), DKTC11 (Denmark), DB0FUB11 (Germany), FINTUVM (Finland),
IMIPOLI (Italy), EB0UB011 (Spain), and TREARN (Turkey).

These EARN servers also cache files from our UNIX-C and MACINTOSH
collections through another LISTSERV cache host.  Many of the
Unix-specific files announced on this list are in the UNIX-C
collection, including the 4.3bsd network updates.

The basic introductory information on the use of these servers will be
sent in response to the command:

TELL LISTSERV AT LISTSERV-nodename /HELP

or

TELL TRICKLE AT EARN-nodename /HELP

Or simply entering the command /HELP in a regular email message
containing a replyable From: line from the perspective of these
servers.

--Frank

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 89 16:53:04 GMT
From:      grant@clleth.UUCP (Grant Fengstad)
To:        comp.protocols.tcp-ip
Subject:   Re: Novell and TCP/IP

In article <18985@mimsy.UUCP>, chenn@tame.cs.umd.edu (Jenn-San Peter Chenn) writes:
> 
>  I would like to make more infomation about tcp/ti on ibmpc. With or 
> W/O Novell. What HW or SW do I need? Who is selling them ? Thank you.

Probably as far as getting support from Novell is concerned, your best bet
would be to go with the Excelan Solution.  It is quite expensive but also
is a good performer.  Other manufacturers that I am aware of are:
 
	Wollongong, Inc.
	3-Com
	Excelan
	FTP


-- 
Grant M. Fengstad     "The ideas expressed are my own - not my employers"
Sr. CSR, Systems Integration - ComputerLand (Canada)
UUCP:  !uunet!{ubc-cs|utai}!calgary!xenlink!clroslyn!clleth!grant
"There's nothing worse than a confirmed fanatic"

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 89 17:44:18 GMT
From:      bob@giza.cis.ohio-state.edu (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: DecNet on TR

In article <8908100159.AA18417@ucbvax.Berk?ley.EDU> cire@CISCO.COM (cire|eric) writes:
   As far as I know the only media that DecNet currently runs over is
   serial lines and ethernet.

In days of yore DECnet's only medium was a parallel interface like the
Unibus DR11-W.  Ethernet was a major step forward at the time, and its
advent was the cause of much rejoicing.  It probably still runs on
parallel interfaces.  Also, you might consider the fiber links to the
DEC mass storage server (sorry, I've forgotten the name/number) to be
a token ring, and I believe they can be a host's only connections to
the rest of a DECnet.

   Are there other media that DecNet is being implemented on?  In
   particular are there other implementations of DecNet on Token Ring?

Proteon's networks can pass DECnet, much as they can pass IP and XNS.
OSU has some PROnet-80 routers configured for DECnet service, though
throughput suffers markedly if DECnet shuffling is enabled.  It's
something about DECnet relying on {broad,multi}cast and that absorbing
too much juice from the router's CPU.  I don't recall the details; we
were just happy when the DECnet folks got their own router and freed
up our box for just IP and XNS.

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 89 05:17:14 GMT
From:      hans@ditmela.oz (Hans Eriksson)
To:        comp.protocols.tcp-ip
Subject:   Re: World record furthest telnet: Australia -> Sweden

In article <8906302219.AA12582@beast.ddn.mil> stjohns@BEAST.DDN.MIL (Mike St. Johns) writes:
> Actually, there is an IP link via the eastern hemisphere.  Its a 
> MILNET sattelite shot via a bird over the indian ocean.

Aah, could you give me some adress info so I can get onto it ;-)

/hans
-- 
Hans Eriksson (hans@ditmela.oz.au)
CSIRO/DIT, 55 Barry Street, Carlton, Victoria 3053, Australia (we are GMT+10)
Tel: +61 3 347-8644 Fax: +61 3 347-8987 Home: +61 3 534-5188
On a years leave from Swedish Institute of Computer Science (hans@sics.se)

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 89 14:06:17 GMT
From:      wayne@gollum.UUCP (wayne hutchinson)
To:        comp.protocols.tcp-ip
Subject:   Looking for TCP/IP source

Is the source for TCP/IP available in the public domain?


Wayne L. Hutchinson
wayne@gollum.Columbia.NCR.COM
Advanced Systems Development
NCR Corporation - E&M Columbia

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 89 16:43:57 GMT
From:      gfb@wsc-sun (Gareth Beale)
To:        comp.protocols.tcp-ip
Subject:   Yellow Pages question


I would like to hear of other's experiences using Yellow Pages across
vendor
boundaries.  We currently have two Sun servers each supporting a number
of
Sun Workstations.  A similar setup is being added with a Vax server and
workstations.  We run Yellow Pages on the Suns (unfortunately, for the
moment
one server is at SunOS 3.5 and one is at 4.0), and would like the Vax
workstations to be a part of the YP domain on one of the Suns.

First, does anyone out there have some experience to relate regarding a
similar
environment?  Second, is it easier for the Vaxes to talk to YP at SunOS
3.5 or
4.0?  I hope the answer is 4.0 or no difference, as we expect to
upgrade the
lagging Sun to 4.0 as soon as we can upgrade the hardware.

Email direct or post to the net if you feel it is of general interest.


Gareth Beale (206)865-5375  #
Mail Stop 7A-35             #  e-mail:
Boeing Computer Services    #  gfb@wsc-sun.boeing.com
P.O. Box 24346              #  or:
Seattle, Wa. 98124-0346     #  gfb%wsc-sun@atc.boeing.com

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 89 17:21:18 GMT
From:      shore@adobe.COM (Andrew Shore)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Naive questions about subnets & domains

I have a couple of naive questions about subnets and domain names.

Adobe currently has an official domain name (adobe.com), and MX forwarder
(decwrl.dec.com), and an official class B network number (with 8 bit
subnets).  However, we are NOT currently a "connected network" -- we
aren't on the Internet for IP traffic.

We may soon have private IP connections to some of our remote offices 
(e.g., Boston and Amsterdam) through various leased services.

Subnet question:  Is it best for me to give each remote office a subnet
of my class B net, or get them there own (class C) network number?
I ask this because it is my impression that subnet topology should
ideally be invisible wrt. external routing decisions, and if we ever DO
connect up to the Internet (especially if we connect in more than one
location), then some very strange things could get routed through Adobe.
Another way to phrase this question is: was it the intention of the subnet
scheme that subnets must be geographically close or only topologically "close" 
for routing purposes?  If they must be topologically close, am I better off
	1) using subnets for remote networks and limiting my connections
	   in the future
or	2) getting distinct network numbers to leave me flexibility in the
	   future
Any practice and experience out there?

Domain question: Clearly our Boston office should be a subdomain of adobe.com
(ne.adobe.com -- Boston [Burlington actually] is our "NorthEast regional
office"), but what about Amsterdam?  Don't some of the European countries
require country-wise domain naming (e.g., something.adobe.nl)? For that
matter, how does one go about registering a host in the .nl domain?
How do other companies with foreign offices handle this?

Thanks in advance,
--Andy Shore
  shore@adobe.com

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 89 18:30:48 GMT
From:      louis@aerospace.aero.org (Louis M. McDonald)
To:        comp.protocols.tcp-ip
Subject:   Summary of sockets programming refereneces


The following is a summary of the messages I received about books
on programming in sockets. Thanks to all who sent me a response
	
		-- Louis McDonald

1) "Using C on the UNIX System", David A. Curry, O'Reilly & Associates
   Available in computer bookstores, or call 1-800-338-NUTS.

   There are two chapters discussing sockets - one for UNIX-domain sockets
   and one for TCP/IP sockets.  Plenty of examples (and you can ftp the
   code for the examples from uunet.uu.net).

2) UnixWorld recently ran a two-part series on "Programming with BSD-Style 
   Sockets", in their July and August 1989 issues.  I just picked up the
   August issue and noticed that they give a simple client/server application
   example.  

3) Marc J. Rochkind's book on "Advanced Unix Programming" (Prentice-Hall,
   1985), if I remember correctly  also covers sockets, but they may be 
   System V style sockets.

4) The Design and Implementation of the 4.3BSD UNIX Operating System
   by Samuel J. Leffler, Marshall Kirk McKusick, Michael J. Karels, and
   John S. Quarterman
   Addison-Wesley, 1989
   ISBN 0-201-06196-1

5) Internetworking with TCP/IP
   by Douglas Comer
   Prentice-Hall, 1988
   ISBN 0-13-470154-2

6) Harspool, R. Nigel, "C Programming in the Berkeley Unix Environment",
   Prentice-Hall, Canada, 1986.

7) Kochan, Stephen G. and Wood, Patrick K. (ed),
   "Unix Networking", Hayden Books Unix System Library, Hayden Books (part of
   Sams books), Indianapolis, Indiana, 1989.

-- 
Louis McDonald
The Aerospace Corporation
louis@aerospace.aero.org

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 89 18:40:05 GMT
From:      "Tony_Sikavi.ESAE"@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Sun tcp/ip problem

I have a SUN 3/60 with OS/4.0.1 and a Sun 3/80 with OS/4.0.3.  I am
experiencing an unusual problem.

I have both the /etc/hosts file and /etc/ethers file configured correctly
on the net for both machines.  The net daemons are running.  NFS is not.  I
can do 'spray' and 'ping' from the 3/80 to the 3/60.  I can do the same on
the 3/60 to itself and the 3/80 to itself.  But, I cannot make the 3/60
talk to the other machine.  Neither ping nor spray work from the 3/60 to
the 3/80.  We had isolated some enet hardware problems and replaced the cpu
board on the 3/60.  Now, selftest and the extended ethernet diagnostics run
fine.  Has anyone had a similar problem and how was it fixed?
//Tony

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 89 21:26:28 GMT
From:      ron@hardees.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: Horsepower of IBM 8232 TCP/IP interface

Mousepower is more like it.  David Lipkke of University
of Texas, Dallas, did a thing called the Texas Shoot Out
where he measured the performance of the various network
attachment units for the IBM channel.  The 8232 is generally
regarded as a loser, being an IBM-PC with a channel interface
and an Ungermann-Trout Ethernet Card.  The winner was the
BusTek box being both faster and cheaper than the other choices.

You might try asking the question on the IBMTCP-L@CUNYVM mailing list
where you're more likely to get informed answers.  No, I do not have
the telephone number for BTI.

-Ron

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 89 23:41:10 GMT
From:      mogul@decwrl.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: Naive questions about subnets & domains

In article <1072@adobe.UUCP> shore@adobe.COM (Andrew Shore) writes:
>[Adobe is] NOT currently a "connected network" -- we
>aren't on the Internet for IP traffic.
>
>We may soon have private IP connections to some of our remote offices 
>(e.g., Boston and Amsterdam) through various leased services.
>
>Subnet question:  Is it best for me to give each remote office a subnet
>of my class B net, or get them there own (class C) network number?
>I ask this because it is my impression that subnet topology should
>ideally be invisible wrt. external routing decisions, and if we ever DO
>connect up to the Internet (especially if we connect in more than one
>location), then some very strange things could get routed through Adobe.
>Another way to phrase this question is: was it the intention of the subnet
>scheme that subnets must be geographically close or only topologically "close" 
>for routing purposes?  If they must be topologically close, am I better off
>	1) using subnets for remote networks and limiting my connections
>	   in the future
>or	2) getting distinct network numbers to leave me flexibility in the
>	   future

The most basic rule of subnetting is that, if you go with option #1,
the subnets must be connected to each other via a path that doesn't
ever leave your class B network.  If you cannot arrange internal links
between the home office and the branch offices, then you are not really
allowed to use option #1.

If you can use option #1, there are two potential problems:
    (a) Except for sites with hand-crafted routes into your network, it
    will nearly impossible to say "use gateway X between the Internet
    and the home office, but use gateway Y between the Internet and the
    Amsterdam office."  This means that there may be some packets that
    go around the world when they only need to travel a few miles.  For
    example, if your primary Internet gateway is in California, and a
    customer in Amsterdam tries to send a packet to the Amsterdam office,
    the packet will flow via California.
    
    This is sad, but nothing is perfect.  You could hope that this doesn't
    happen too often (how many Europeans run IP, after all?); in cases
    where it is important, your customers could install hand-crafted
    routes to your externally-visible Amsterdam host(s).

    (b) Nasty people in Amsterdam, if they know that Adobe is paying
    for an internal IP link between their city and California, could
    try to save money on their own phone bills by routing their
    packets through your network.  This should not happen with normal
    routing protocols; anyway, it is a simple matter to provide access
    control mechanisms in your routers to deny forwarding of such
    "transit" packets.

If you use option #2, then neither of these two problems exists.
On the other hand, the size of the Internet routing tables is
growing at a frightening rate, and I'm sure people would rather that
you kept the number of networks as low as possible.  Although
option #2 may be better for some specific situations, for the
community as a whole, the fewer networks the better.

-Jeff

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 89 23:51:33 GMT
From:      km3t@jjmhome.UUCP (Dave Pascoe)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Subject:   How to get remote directories via FTP?

I have access to the Internet through a VAX (running VMS) at work.  I think
the machine is running an "older" TCP/IP package (I don't know which).  At
any rate, the machine is not running the Wollongong package.

My question is this:  How can one get directory info from remote machines
if he knows at least the directory path on that machine?  My machine's package does not seem to support the DIR command.  If there is no way to
get it via ftp, then is there a way to request the file names in a public
directory from someone like "postmaster@site"?  Is there a standard procedure
for this type of thing?  There must be others with the same problem.

-- 
                      Internet: pascoe@godot.GTE.COM
Dave Pascoe           Smart Mailer: km3t@jjmhome.UUCP 
  KM3T/1              UUCP: ....!harvard!m2c!jjmhome!km3t
                      Packet Radio: KM3T @ K1UGM.MA.USA.NA

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Aug 89 07:37:38 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        tcp-ip@nic.ddn.mil, ubc-cs!alberta!calgary!xenlink!clroslyn!clleth!grant@beaver.cs.washington.edu
Subject:   Re: Novell and TCP/IP
The question of "coordinating" use of TCP/IP with a proprietary protocol,
such as Novell's Netware, surfaces on one of the lists periodically.  In
looking for solutions, it is important to be clear about the problem, since
there are two, VERY different operational styles and they need two, VERY
different kinds of solutions:

1.  Proprietary Network

The entire (sub-)network operates with the proprietary protocol, but you
would like to connect it to a TCP/IP network.  This requires that the
various hosts on the proprietary network communicate over their
sub-network through some sort of relay device (router/gateway) which
connects the proprietary protocol into the TCP/IP protocols.  There are
different technical solutions to this.

2.  Shared Network

You wish to run the proprietary protocols AND TCP/IP over the SAME wire and
want you host (pc) to be able to use BOTH sets of protocols.  If done
efficiently, this requires having the protocol stacks share the network
device driver for the host.  (An alternative is to make this case look
like #1, above, and have the relay device connected twice to the network,
so that the proprietary network looks as if it is on a separate wire.)

It is my understanding that the Excelan product, which was suggested in
a previous note, solves only case #2, for shared networks.  (Note that if
{you already have another network interface card, you get to buy the
Excelan card anyhow.  There are alternate products whi allow you to share
various other cards.

Dave
-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 89 02:01:21 GMT
From:      kent@sas.UUCP (Paul Kent)
To:        comp.protocols.tcp-ip
Subject:   novice TCP-IP / UNIX questions

hello,

this is a first posting, so please be gentle if i screw up.

I have written a client/server pair of programs modelled on the
whois_client/whois_server pair in "Internetworking with TCP/IP"
by Douglas Comer. (a very useful book, thanks!)

For those who might help, but do not have the book, the server
does this (and a bit of error checking too :-)

   hp = gethostbyname(host);
   s  = socket(hp->h_addrtype, SOCK_STREAM, 0);
   bind(s, &sa, sizeof(sa) );
   listen(s, 5);
   for(;;)
     {
       t = accept(s, ..
       read(t, ...)
       process(...)
       write(t, ...)
       close(t)
     }

while the client does this:

   hp = gethostbyname(host);
   s  = socket(hp->h_addrtype, SOCK_STREAM, 0);
   connect(s, &sa, sizeof(sa) );
   write(s, ...)
   read(s, ...)
   exit(0)


Under Apollo bsd4.2 (SR9.7 and SR10) , as well as Ultrix (RISC),
they work nicely if i start the server in one shell, and then run the 
client in another.

I am interested in having inetd start my tcp server process, as soon
as it hears a request from a client. This is where the wheels fall off.

My pair of programs use the "well known" (to the pair at least)
service "pmka", whose entry in /etc/services is:

pmka            601/tcp  # See Paul Kent

The entry in inetd.conf is: (the executable is not owned by root)

pmka stream tcp nowait /udr/saspmk/tcp/com/pmkad pmkad

now, the inetd man page says that it starts the client with a socket
descriptor of 0 for the service requested.



Question 1:  do i accept connections on descriptor 0, 

       -or-  do i read/write it hoping that inetd accepted
             the connection for me?

       -or   am i supposed to bind it in some fashion?

 example fragments most welcome... i have no unix source access or i
   would snoop around ftpd and telnetd

 ditto for things your mother should have told you 
   about inetd spawned servers, but forgot to.


Question 2:  any tips on how to debug a process launched by inetd?


Question 3:  i ultimately want to write client/server code to support
             communications between two SAS sessions via the internet.
             (SAS/Share and micro-to-host link if you know our products)

             how do i request that a well know number be assigned to
             my/SAS's application?




Thank You

Paul
R&D -- applications




-- 
---- nothing ventured, nothing disclaimed ----
paul kent, SAS Institute, box 8000, cary nc 27512-8000 -- 919 467 8000
.... {seismo|mcnc}!rti!sas!kent  or  kent@sas.UUCP

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 89 04:50:47 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for TCP/IP source

Wayne,  It is my understanding the Berkeley Unix TCP/IP is essentially
in the public domain.  They (Berkeley) have gone to great lenghts to 
ensure that that specific code does not need the usual AT&T license.
By "essentially" I mean that one has to sign a document that "holds
harmless" the Regents of the University of California -- this means that
if they accidently gave you something they did not own, you will not
sue them.  No one has lost on this bet yet...

Dan
-------

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 89 05:06:27 GMT
From:      tmac@MACVAX.ENGIN.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Sun tcp/ip problem

>	... But, I cannot make the 3/60
> talk to the other machine.  Neither ping nor spray work from the 3/60 to
> the 3/80...

Hmm.  Are the interfaces configured properly on both machines?
I know I've pulled my hair many times before realizing I misset
the broadcast or something like that.  Spray and ping
shouldn't rely on /etc/ethers at all and should only rely
on /etc/hosts if you specify the target in hostname format.

Do an 'ifconfig le0' and confirm that both machines are
using the same broadcast, same netmask, same trailers (we
prefer none).

And of course check that the interfaces are up ;-)

	_T

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Aug 89 12:20:11 EDT
From:      BDK@UNB.CA
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: TCP/IP and 8232 Token Ring
For a brief description consult  gx20-1850 System/370 Reference Summary.
For a more detailed description consult the Principles of Operations
manual.
> Starting TCP/IP on a VM/XA SP2 system to connect a Token Ring via
> 8232 LAN station I got following errors:
>
> PCCA3 device lcs1: unexpected CSW from senseid command on device 0220
>    keys: 00 CcwAddress: 002C3138
>    unit status: 0C, channel status: 20
>    byte count: 1
>
> Anybody on the list ever seen that and can explain the return codes
> for unit status and channel status?
> Any help very much appreciated.
>
> /Eva
-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 89 14:18:46 GMT
From:      adnan@sgtech.UUCP (Adnan Yaqub)
To:        comp.protocols.tcp-ip
Subject:   To Whom Does One Report Errors In an RFC?

In RFC783 (TFTP) a description of the UDP header is given.  In this
description, the length field is described as follows:

>Length          Number of bytes in packet after Datagram header.

while in RFC768 (UDP) the length field is:

>Length  is the length  in octets  of this user datagram  including  this
>header  and the data.   (This  means  the minimum value of the length is
>eight.)

Who needs to be told to correct RFC783?
--
Adnan Yaqub
Star Gate Technologies, 29300 Aurora Rd., Solon, OH, USA, +1 216 349 1860
...uunet!abvax!sgtech!adnan

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 89 14:37:38 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: Novell and TCP/IP

The question of "coordinating" use of TCP/IP with a proprietary protocol,
such as Novell's Netware, surfaces on one of the lists periodically.  In
looking for solutions, it is important to be clear about the problem, since
there are two, VERY different operational styles and they need two, VERY
different kinds of solutions:

1.  Proprietary Network

The entire (sub-)network operates with the proprietary protocol, but you
would like to connect it to a TCP/IP network.  This requires that the
various hosts on the proprietary network communicate over their
sub-network through some sort of relay device (router/gateway) which
connects the proprietary protocol into the TCP/IP protocols.  There are
different technical solutions to this.

2.  Shared Network

You wish to run the proprietary protocols AND TCP/IP over the SAME wire and
want you host (pc) to be able to use BOTH sets of protocols.  If done
efficiently, this requires having the protocol stacks share the network
device driver for the host.  (An alternative is to make this case look
like #1, above, and have the relay device connected twice to the network,
so that the proprietary network looks as if it is on a separate wire.)

It is my understanding that the Excelan product, which was suggested in
a previous note, solves only case #2, for shared networks.  (Note that if
{you already have another network interface card, you get to buy the
Excelan card anyhow.  There are alternate products whi allow you to share
various other cards.

Dave

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 89 15:21:02 GMT
From:      dpz@convex.com (David Paul Zimmerman)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for TCP/IP source


Here's the announcement from last December of BSD TCP/IP code availability...

						David

From: bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic)
Newsgroups: comp.bugs.4bsd.ucb-fixes
Subject: V1.73 (BSD Networking Software, Release #1)
Date: 7 Dec 88 01:54:54 GMT

We are happy to announce the availability of the first release of the BSD
networking software.  It consists of the standard user level applications,
(along with their manual pages and some related documentation) and some
kernel and C library support.  It should be noted that this software has
only been tested for compilation and operation on 4.3BSD and 4.3BSD-tahoe.
A complete list of files is attached to this message.

The TCP and IP code is approximately the same as that recently made
available via the ARPANET and Usenet.  Several new algorithms are used in
TCP, in particular Van Jacobson's slow start and dynamic window size
selection algorithms and Phil Karn's modification to the roundtrip timing
algorithm.  These changes increase throughput and reduce congestion and
retransmission.  Several fixes were made in the handling of IP options
and other gateway support.

This software suite is copyright The Regents of the University of California
and may be freely redistributed.  No previous license, either AT&T or
Berkeley is required.  The release costs $400.00 US.  To request an order
form, please contact our distribution office by phone at 415-642-7780, or
by email at bsd-dist@ucbarpa.berkeley.edu or uunet!ucbarpa!bsd-dist, or
by U.S. Mail at:

	CSRG, Computer Science Division
	University of California
	Berkeley, CA  94720

Mike Karels
Kirk McKusick

========================

XNSrouted	hostname	ping		rshd		telnet
arp		htable		rcp		ruptime		telnetd
comsat		ifconfig	rdist		rwho		tftp
egp		implog		rexecd		rwhod		tftpd
finger		include		rlogin		sendmail	timed
fingerd		inetd		rlogind		slattach	trpt
ftp		lib		rmt		sys		trsp
ftpd		lpr		route		syslogd		uucp
gettable	named		routed		talk		whois
hostid		netstat		rsh		talkd

XNSrouted:
Makefile	defs.h		main.c		table.h		trace.c
XNSrouted.8	if.c		output.c	tables.c	trace.h
af.c		input.c		protocol.h	timer.c
af.h		interface.h	startup.c	tools

XNSrouted/tools:
query.c

arp:
Makefile	arp.8		arp.c

comsat:
Makefile	comsat.8	comsat.c

egp:
Makefile	egp.conf	if.c		init.c		rt_table.c
defs.h		egp.h		if.h		main.c		rt_table.h
egp-notes	egp_param.h	include.h	rt_egp.c	trace_egp.c
egp.c		ext.c		inet.c		rt_init.c	trace_egp.h

finger:
Makefile	finger.1	finger.c

fingerd:
Makefile	fingerd.8	fingerd.c

ftp:
Makefile	cmdtab.c	ftp.1		ftp_var.h	main.c
cmds.c		domacro.c	ftp.c		glob.c		ruserpass.c

ftpd:
Makefile	ftpd.8		glob.c		newvers.sh	vers.c
ftpcmd.y	ftpd.c		logwtmp.c	popen.c		version

gettable:
Makefile	gettable.8	gettable.c

hostid:
Makefile	hostid.1	hostid.c

hostname:
Makefile	hostname.1	hostname.c

htable:
Makefile	htable.c	parse.y
htable.8	htable.h	scan.l

ifconfig:
Makefile	ifconfig.8	ifconfig.c

implog:
Makefile	implog.8	implog.c	implogd.8	implogd.c

include:
arpa		netdb.h		protocols	resolv.h	sysexits.h

include/arpa:
ftp.h		inet.h		nameser.h	telnet.h	tftp.h

include/protocols:
routed.h	rwhod.h		talkd.h		timed.h

inetd:
Makefile	inetd.8		inetd.c

lib:
libc	libutil

lib/libc:
gen	inet	net	ns	tahoe

lib/libc/gen:
getusershell.c

lib/libc/inet:
Makefile	inet_lnaof.c	inet_netof.c	inet_ntoa.c
inet_addr.c	inet_makeaddr.c	inet_network.c	profiled

lib/libc/inet/profiled:

lib/libc/net:
Make.resolv	getprotoent.c	hosttable	res_comp.c	rexec.c
Makefile	getprotoname.c	named		res_debug.c	ruserpass.c
getnetbyaddr.c	getservbyname.c	net.tahoe	res_init.c
getnetbyname.c	getservbyport.c	net.vax		res_mkquery.c
getnetent.c	getservent.c	profiled	res_query.c
getproto.c	herror.c	rcmd.c		res_send.c

lib/libc/net/hosttable:
Makefile	gethostent.c	gethostnamadr.c	profiled

lib/libc/net/hosttable/profiled:

lib/libc/net/named:
Makefile	gethostnamadr.c	profiled	sethostent.c

lib/libc/net/named/profiled:

lib/libc/net/net.tahoe:
Makefile	htons.s		ntohs.s
htonl.s		ntohl.s		profiled

lib/libc/net/net.tahoe/profiled:

lib/libc/net/net.vax:
Makefile	htons.s		ntohs.s
htonl.s		ntohl.s		profiled

lib/libc/net/net.vax/profiled:

lib/libc/net/profiled:

lib/libc/ns:
Makefile	ns_addr.c	ns_ntoa.c	profiled

lib/libc/ns/profiled:

lib/libc/tahoe:
DEFS.h

lib/libutil:
Makefile	login.c		logout.c	logwtmp.c

lpr:
Makefile	lp.h		lpdchar.c	lptest.1	rmjob.c
cmds.c		lp.local.h	lpq.1		lptest.c	startdaemon.c
cmdtab.c	lpc.8		lpq.c		pac.8		vfilters
common.c	lpc.c		lpr.1		pac.c
displayq.c	lpc.h		lpr.c		printcap.c
etc.printcap	lpd.8		lprm.1		printjob.c
filters		lpd.c		lprm.c		recvjob.c

lpr/filters:
Makefile	lpf.c

lpr/vfilters:
Makefile	railmag.c	sidebyside.c	vpf.c		vpltdmp.c
chrtab.c	rvcat.c		vcat.c		vplotf		vpsf.c
necf.c		rvsort.c	vdmp.c		vplotf.c	vsort.c

named:
CHANGES		db_dump.c	master		ns_forw.c	ns_stats.c
Makefile	db_load.c	namebuf		ns_init.c	storage.c
README		db_lookup.c	named.8		ns_main.c	tools
Version.c	db_reload.c	named.reload	ns_maint.c	version
databuf		db_save.c	named.restart	ns_req.c
databufs	db_update.c	newvers.sh	ns_resp.c
db.h		doc		ns.h		ns_sort.c

named/doc:
DynamicUpdate	rfc1033.lpr	rfc1035.lpr	rfc974.lpr
rfc1032.lpr	rfc1034.lpr	rfc920.lpr

named/master:
:pwedit			named.boot		named.rev
Index			named.boot.master	root.cache
README			named.hosts
atod.y			named.local

named/tools:
Makefile	nslookup	nsquery.c	nstest.c

named/tools/nslookup:
Makefile	getinfo.c	nslookup.1	send.c
commands.l	list.c		nslookup.help	skip.c
debug.c		main.c		res.h		subr.c

netstat:
Makefile	if.c		main.c.oldimp	ns.c
host.c		inet.c		mbuf.c		route.c
host.c.oldimp	main.c		netstat.1	unix.c

ping:
Makefile	ping.8		ping.c

rcp:
Makefile	rcp.1		rcp.c

rdist:
Makefile	defs.h		expand.c	lookup.c	rdist.1
cron.entry	docmd.c		gram.y		main.c		server.c

rexecd:
Makefile	rexecd.8	rexecd.c

rlogin:
Makefile	rlogin.1	rlogin.c

rlogind:
Makefile	rlogind.8	rlogind.c

rmt:
Makefile	rmt.8		rmt.c

route:
Makefile	route.8		route.c

routed:
Makefile	if.c		main.c		table.h		trace.c
af.c		inet.c		output.c	tables.c	trace.h
af.h		input.c		routed.8	timer.c
defs.h		interface.h	startup.c	tools

routed/tools:
Makefile	query.c		trace.c

rsh:
Makefile	rsh.1		rsh.c

rshd:
Makefile	rshd.8		rshd.c

ruptime:
Makefile	ruptime.1	ruptime.c

rwho:
Makefile	rwho.1		rwho.c

rwhod:
Makefile	rwhod.8		rwhod.c

sendmail:
include	src

sendmail/include:
asm.sed.tahoe	asm.sed.vax	useful.h	userdbm.h

sendmail/src:
Makefile	conf.c		err.c		readcf.c	stats.c
READ_ME		conf.h		headers.c	recipient.c	sysexits.c
Version.c	convtime.c	macro.c		savemail.c	trace.c
alias.c		daemon.c	mailstats.h	sendmail.8	usersmtp.c
arpadate.c	deliver.c	main.c		sendmail.h	util.c
clock.c		domain.c	parseaddr.c	srvrsmtp.c	version.c
collect.c	envelope.c	queue.c		stab.c

slattach:
Makefile	slattach.8	slattach.c

sys:
Makefile.sun	h		netimp		sys
README		implog		netinet		vaxif
TCP_INSTALL	net		netns

sys/h:
domain.h	protosw.h	socketvar.h	unpcb.h
mbuf.h		socket.h	un.h

sys/implog:
Makefile	implog.8	implog.c	implogd.c

sys/net:
af.c		if.h		if_sl.c		raw_cb.h	route.h
af.h		if_arp.h	netisr.h	raw_usrreq.c
if.c		if_loop.c	raw_cb.c	route.c

sys/netimp:
hosts		hosttable	if_imp.h	if_imphost.h
hosts.nxt	if_imp.c	if_imphost.c	raw_imp.c

sys/netinet:
icmp_var.h	in_pcb.h	ip_input.c	tcp_fsm.h	tcp_usrreq.c
if_ether.c	in_proto.c	ip_output.c	tcp_input.c	tcp_var.h
if_ether.h	in_systm.h	ip_var.h	tcp_output.c	tcpip.h
in.c		in_var.h	raw_ip.c	tcp_seq.h	udp.h
in.h		ip.h		tcp.h		tcp_subr.c	udp_usrreq.c
in_cksum.c	ip_icmp.c	tcp_debug.c	tcp_timer.c	udp_var.h
in_pcb.c	ip_icmp.h	tcp_debug.h	tcp_timer.h

sys/netns:
idp.h		ns_error.c	ns_output.c	spidp.h		spp_var.h
idp_usrreq.c	ns_error.h	ns_pcb.c	spp_debug.c
idp_var.h	ns_if.h		ns_pcb.h	spp_debug.h
ns.c		ns_input.c	ns_proto.c	spp_timer.h
ns.h		ns_ip.c		sp.h		spp_usrreq.c

sys/sys:
sys_socket.c	uipc_mbuf.c	uipc_socket.c	uipc_syscalls.c
uipc_domain.c	uipc_proto.c	uipc_socket2.c	uipc_usrreq.c

sys/vaxif:
if_acc.c	if_css.c	if_hdh.c

syslogd:
Makefile	syslogd.8	syslogd.c

talk:
Makefile	display.c	init_disp.c	look_up.c	talk.c
ctl.c		get_addrs.c	invite.c	msgs.c		talk.h
ctl_transact.c	get_names.c	io.c		talk.1		talk_ctl.h

talkd:
Makefile	print.c		table.c		talkd.c
announce.c	process.c	talkd.8

telnet:
Makefile	Source		telnet.1

telnet/Source:
commands.c	general.h	network.c	sys_dos.c	tn3270.c
defines.h	main.c		ring.c		telnet.1	types.h
externs.h	makedep		ring.h		telnet.c	utilities.c
fdset.h		n.telnet.c	sys_bsd.c	terminal.c

telnetd:
Makefile	telnetd.8	telnetd.c

tftp:
Makefile	main.c		tftp.1		tftp.c		tftpsubs.c

tftpd:
Makefile	tftpd.8		tftpd.c

timed:
Makefile	cksum.tahoe.c	globals.h	slave.c		timedc.h
acksend.c	cksum.vax.c	master.c	timed.8
byteorder.c	cmds.c		measure.c	timed.c
candidate.c	cmdtab.c	networkdelta.c	timedc.8
cksum.m68000.c	correct.c	readmsg.c	timedc.c

trpt:
Makefile	trpt.8		trpt.c

trsp:
Makefile	trsp.8		trsp.c

uucp:
uucpd.c

whois:
Makefile	whois.1		whois.c



David Paul Zimmerman                                             dpz@convex.com
CONVEX Computer Corp                                                 convex!dpz

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 89 16:31:38 GMT
From:      jkrey@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Sun RARP doesn't follow RFC 903

The draft RFC by Sun Microsystems (specifically David Brownell)
on DRARP is pending resubmission to the RFC Editor.

JKREY

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 89 16:45:34 GMT
From:      chenn@tame.cs.umd.edu (Jenn-San Peter Chenn)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP on ibmpc running MS/DOS

Is it possible that an ibmpc can connect to Internet with some proper
HW/SW? If I am doing the as an individual, Can it be legally done?
Which orgnization should I contact? What will be the most inexpensive 
way of doing this? What would be the most possible way to make the connection?

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 89 16:55:13 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: novice TCP-IP / UNIX questions


	inetd(8) does the accept(2) for you; descriptor 0 is an ESTABLISHED
state (as opposed to LISTEN state) TCP socket.

	Re: debugging.

	I found it useful to write some inetd-like functions that do the
accept(2) and dup2(2) it onto descriptor 0. I then used "#ifdef DEBUG"'s to
include or exclude the function that does the setup. The remaining code (the
server proper) works the same with or without inetd.
	Further, you can do dbx-debugging easily if the accept is done in
the same process (ie, no fork(2) after the accept(2)). When it works, just
recompile without "DEBUG" defined and you're done.
	The code I have is for a particular server I'm working on, so it's
not really worth posting, but it is easily adapted and I'll send it on
request to anyone who asks (via mail). Actually, reproducing it yourself
isn't a bad exercise in using sockets, either...
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 89 17:47:15 GMT
From:      hwajin@wrs.wrs.com (Hwajin Bae)
To:        comp.protocols.tcp-ip
Subject:   Re: novice TCP-IP / UNIX questions

In article <1149@sas.UUCP> kent@sas.UUCP (Paul Kent) writes:
>now, the inetd man page says that it starts the client with a socket
>descriptor of 0 for the service requested.
>Question 1:  do i accept connections on descriptor 0, 
>       -or-  do i read/write it hoping that inetd accepted
>             the connection for me?

Inetd will automaticallly dup descriptor 0 to be the new socket 
connection established.  You can safely assume that the descriptor 0 will
be the socket descriptor for the connection you desire on the server side.
To be able to find out the address of the remote peer who just made a
connect() call to the server (invoked by the inetd), you can use 
getpeername() call.


-- 
Hwajin Bae
Wind River Systems
1350 Ocean Ave
Emeryville, CA 94608

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 89 19:27:48 GMT
From:      morrison@accuvax.nwu.edu (Vance Morrison )
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   PCroute and PCbridge posted to comp.binaries.ibm.pc


Hello,

Due to popular demand an a lack of enough mail servers, I am
posting the binaries to PCroute and PCbridge to comp.binaries.ibm.pc.
People who can't ftp them from accuvax.nwu.edu can pick them up
from that newsgroup.  

PCbridge comes with the source, PCroute does not since the source
is big and not necessary to get going.  

Vance

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 89 19:39:35 GMT
From:      lance@belltec.UUCP (Lance Norskog)
To:        comp.protocols.tcp-ip
Subject:   Re: World record furthest telnet: Australia -> Sweden

In article <8906302219.AA12582@beast.ddn.mil>, stjohns@BEAST.DDN.MIL (Mike St. Johns) writes:
> Actually, there is an IP link via the eastern hemisphere.  Its a 
> MILNET sattelite shot via a bird over the indian ocean.

Does the secret link between nsavax and kremvax go via the Atlantic 
or the Pacific or the North Pole?  Or is it a carrier wave atop Tesla 
crust wave generators?

Inquiring minds want to know!

Lance Norskog
Streamlined Networks

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 89 20:34:57 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: novice TCP-IP / UNIX questions

Question 1:  do i accept connections on descriptor 0, 
       -or-  do i read/write it hoping that inetd accepted
            the connection for me?
       -or   am i supposed to bind it in some fashion?

Answer 1:  Number 2 is correct.  Inetd accepts the connection for you and
	forces it to be file descriptor zero.

Question 2:  any tips on how to debug a process launched by inetd?

Answer 2:  Most of the inetd started servers have a -d option that allows
	you to start up the job with the old socket/bind/accept sequence
	so you can test it without having to change the inetd configuration.
	Actually, since all that grungy bind stuff is taken care of it's
	easier to write inetd applications.

Question 3:  i ultimately want to write client/server code to support
             communications between two SAS sessions via the internet.
             (SAS/Share and micro-to-host link if you know our products)
             how do i request that a well know number be assigned to
             my/SAS's application?

Answer 3:  The numbers are enumerated in a document known as assigned
	numbers.  My guess is that Postel is still responsible for
	dealing them out.


> paul kent, SAS Institute, box 8000, cary nc 27512-8000 -- 919 467 8000

Gee, that address sounds familiar.  Seems to be on a few zillion output runs
here.

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 89 21:06:54 GMT
From:      fwerbel@dhldev.DHL.COM (What? No window seats left!!!)
To:        comp.protocols.tcp-ip
Subject:   Porting RPC to ATT Environment



I've recently acquired the version 4.0 public domain source code for
Sun RPC.  When attempting to port this code to an ATT environment, we've
run into one stumbling point concerning registerrpc().

The registerrpc() routine appears to select a port number and socket address
and then verify its accessibility.  The problem arises in the
value of the 'rm_direction' field initialized by clntudp_create() and checked
in clntudp_call().   The initial value is set to CALL by the create routine.
The clntudp_call() routine calls xdr_replymsg() to verify the data that was
received (sent) to the socket.  This function expects the 'rm_direction'
field to have the value REPLY.  It appears from our testing that the
value at the xdr_replymsg() function is still set to CALL.

Our question:  How, or does, the 'rm_direction' field get set to REPLY?

Any input would be greatly appreciated.

Thanks.

				Fred Werbel
				fwerbel@dhl.com

Voice: (703) 749-2206
Snail Mail:  NetExpress Communications
	     1953 Gallows Rd
	     Vienna, VA  22182

Disclaimers: so it is written, so let it be disclaimed.
				uucp: uunet!netxcom!fwerbel
Fred Werbel

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 89 23:12:34 GMT
From:      dave@celerity.uucp (Dave Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: the worm and internet security

In article <24248@santra.UUCP> jkp@cs.HUT.FI (Jyrki Kuoppala) writes:
>The Berkeley ucb-fixes list already does a very good job at this -
>but apparently it isn't enough, as many vendors seem to neglect the
>security fixes which Berkeley puts out.  For example, how many have
>fixed the one with rshd and rlogind accepting connections from ports
>under 512 ?  It seems that someone has to make public the information
>how to use the bug before the vendors believe it.

One problem we have had in implementing the fixes is the reluctance of
BSD to explain what the problem is!  Our code has diverged from the
BSD stuff in parts and receiving a ten-line context diff which doesn't
apply to our code and "fix this now!" is really not very helpful.  
Especially since in order to be sure that we've fixed the bug we need to
know what the bug is so we can test it afterwards.  In addition, since 
our architecture is different from the VAX some bugs (like the fingerd 
hole) don't happen on our machine or may happen in a different way.

The idea of a security list circulating amongst the vendors and then going
public after a few months is an excellent idea.  Pretending the problems
don't exist is silly.

(these views, of course, are mine and not the property of FPS Computing,
 who would probably disown me if they knew the kind of silly stuff I have
 been posting)
David L. Smith
FPS Computing, San Diego
ucsd!celerity!dave
"Repent, Harlequin!," said the TickTock Man

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 89 00:37:55 GMT
From:      dpz@convex.com (David Paul Zimmerman)
To:        comp.protocols.tcp-ip
Subject:   Re: Naive questions about subnets & domains

You'll probably see a lot of similarities to your original in this reply...

Convex currently has an official domain name (convex.com), and MX forwarder
(uxc.cso.uiuc.edu), and an official class B network number (with 8 bit
subnets).  However, we are NOT currently a "connected network" -- we aren't on
the Internet for IP traffic.

We currently do have private IP connections to some of our remote
offices (e.g., CA, FL, MD) through various leased services.

Subnet answer: So far, our connected remote sites are subnets under our class
B, whether US or foreign.  Since I'm in Engineering, not MIS, I don't have
direct control over this, but hopefully (with a little nudging from me if
necessary :-) we can keep going in that direction.  I believe that subnets are
intended for topological groupings, so under that presumption, all the hosts
of your company would have addresses under your single class B.  If you've got
a lot, like Rutgers University does, but not enough to warrant a class A, you
may eventually have to go to multiple B networks.  How you deal with that is
pretty much up to you -- you probably could organize geographically by B
network, but I suspect that by the time you need the additional networks it
would be a major piece of work to pull off.

Distinct C network numbers can get to be more of a hassle than giving you
flexibility.  When I was at Rutgers, they had a remote net that was a class C,
and eventually redid them to be under their class B.  That net has since gone
forth and easily multiplied into a healthy number of subnets.  That is a
flexibility that you don't have when you have to get a class C allocated every
time you want to split or add a remote network or something.  Plus, it's a
waste of Internet network address mapping space if you've already got the
class B allocated.

Then again, Convex is only planning a single connection to the Internet, and
Rutgers didn't care if it played go-between for packets.  For multiple
connections, you could probably play routing protocol games to keep the
unwanted traffic off.  Haven't hacked routing protocols yet, so I can't say
how easy or hard this is.  It could just be a matter of telling your
routers-to-the-real-world to not advertise their knowledge to one another.

Domain answer: Our US sites are simply hosts as part of .convex.com, no
subdomains yet.  However, we do have a couple of remote sites in Europe, and
those just conform to the European geographical domains (.convex.oxford.ac.uk,
.convex.nl).  They're not on our network yet, so we get to them via UUCP.  You
can probably get more information about this whole issue from Piet Beertema
(piet@cwi.nl), who handles the European UUCP maps.

						David

David Paul Zimmerman                                             dpz@convex.com
CONVEX Computer Corp                                                 convex!dpz

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 89 00:55:06 GMT
From:      dpz@convex.com (David Paul Zimmerman)
To:        comp.protocols.tcp-ip
Subject:   Re: Naive questions about subnets & domains

> It could just be a matter of telling your routers-to-the-real-world to not
> advertise their knowledge to one another.

Argh... That doesn't make sense.  Your non-world-connected internal routers
could still propagate that information between your world-connected routers.
Told you I haven't hacked that stuff yet :-) What you would really want is to
have your internal net have all the routing information it wants, while, to
the real world, making all paths coming into your network look like dead ends.

						David

David Paul Zimmerman                                             dpz@convex.com
CONVEX Computer Corp                                                 convex!dpz

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 89 01:31:58 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Repeated ping responses?


	Can somebody tell me how this happens:

[...]
64 bytes from 132.247.5.1: icmp_seq=14. time=2418. ms
64 bytes from 132.247.5.1: icmp_seq=15. time=2570. ms
64 bytes from 132.247.5.1: icmp_seq=15. time=2613. ms
64 bytes from 132.247.5.1: icmp_seq=16. time=1700. ms
[...]
----132.247.5.1 PING Statistics----
51 packets transmitted, 49 packets received, 3% packet loss
round-trip (ms)  min/avg/max = 1612/2111/3479

	Note that ping 15 got answered twice.  What causes that?  It
doesn't seem like a fluke -- I tried pinging 132.247.5.1 three times and
each time got a doublet within the first 10 or 20 packets.  The machine in
question is in Cuernavaca, Mexico, with (to the best of my knowledge) a
terrestrial microwave link to Mexico City and some satellite link from
there.  You should see what telnets look like.
-- 
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"

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 89 02:00:21 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   Re: World record furthest telnet: Australia -> Sweden

Sheesh....

Let me rephrase -- the link I was referring to is a trunk circuit
between two MILNET Nodes.  As the MILNET routing is transparent
to the user, you'd find it difficult to guarantee that your
transmission is going via that link.  (Although, using some of the
stuff Dave Mills has done, you could probably detect the fact that
you are using this satellite shot).  

Mike

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 89 12:54:47 GMT
From:      dab@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Sun RARP doesn't follow RFC 903

It seems that BOOTP would have made a better base to do dynamic
address assignment from than RARP.  Why the choice?

						David Bridgham

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 89 15:58:35 GMT
From:      krvw@sei.cmu.edu (Kenneth Van Wyk)
To:        comp.protocols.tcp-ip
Subject:   CERT Internet Security Advisory


Many computers connected to the Internet have recently experienced
unauthorized system activity.  Investigation shows that the activity
has occurred for several months and is spreading.  Several UNIX
computers have had their "telnet" programs illicitly replaced with
versions of "telnet" which log outgoing login sessions (including
usernames and passwords to remote systems).  It appears that access
has been gained to many of the machines which have appeared in some of
these session logs.  (As a first step, frequent telnet users should
change their passwords immediately.)  While there is no cause for
panic, there are a number of things that system administrators can do
to detect whether the security on their machines has been compromised
using this approach and to tighten security on their systems where
necessary.  At a minimum, all UNIX site administrators should do the
following:

o Test telnet for unauthorized changes by using the UNIX "strings"
  command to search for path/filenames of possible log files.  Affected
  sites have noticed that their telnet programs were logging information
  in user accounts under directory names such as "..." and ".mail".

In general, we suggest that site administrators be attentive to
configuration management issues.  These include the following:


o Test authenticity of critical programs - Any program with access to
  the network (e.g., the TCP/IP suite) or with access to usernames and
  passwords should be periodically tested for unauthorized changes.
  Such a test can be done by comparing checksums of on-line copies of
  these programs to checksums of original copies.  (Checksums can be
  calculated with the UNIX "sum" command.)  Alternatively, these
  programs can be periodically reloaded from original tapes.

o Privileged programs - Programs that grant privileges to users (e.g.,
  setuid root programs/shells in UNIX) can be exploited to gain
  unrestricted access to systems.  System administrators should watch
  for such programs being placed in places such as /tmp and /usr/tmp (on
  UNIX systems).  A common malicious practice is to place a setuid shell
  (sh or csh) in the /tmp directory, thus creating a "back door" whereby
  any user can gain privileged system access.

o Monitor system logs - System access logs should be periodically
  scanned (e.g., via UNIX "last" command) for suspicious or unlikely
  system activity.

o Terminal servers - Terminal servers with unrestricted network access
  (that is, terminal servers which allow users to connect to and from
  any system on the Internet) are frequently used to camouflage network
  connections, making it difficult to track unauthorized activity.
  Most popular terminal servers can be configured to restrict network
  access to and from local hosts.

o Passwords - Guest accounts and accounts with trivial passwords
  (e.g., username=password, password=none) are common targets.  System
  administrators should make sure that all accounts are password
  protected and encourage users to use acceptable passwords as well as
  to change their passwords periodically, as a general practice.  For
  more information on passwords, see Federal Information Processing
  Standard Publication (FIPS PUB) 112, available from the National
  Technical Information Service, U.S. Department of Commerce,
  Springfield, VA 22161.

o Anonymous file transfer - Unrestricted file transfer access to a
  system can be exploited to obtain sensitive files such as the UNIX
  /etc/passwd file.  If used, TFTP (Trivial File Transfer Protocol -
  which requires no username/password authentication) should always be
  configured to run as a non-privileged user and "chroot" to a file
  structure where the remote user cannot transfer the system /etc/passwd
  file.  Anonymous FTP, too, should not allow the remote user to access
  this file, or any other critical system file.  Configuring these
  facilities to "chroot" limits file access to a localized directory
  structure.

o Apply fixes - Many of the old "holes" in UNIX have been closed.
  Check with your vendor and install all of the latest fixes.


If system administrators do discover any unauthorized system activity,
they are urged to contact the Computer Emergency Response Team (CERT).


Kenneth R. van Wyk
Computer Emergency Response Team
cert@SEI.CMU.EDU
(412) 268-7090  (24 hour hotline)

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 89 16:04:47 GMT
From:      lear@NET.BIO.NET (Eliot Lear)
To:        comp.protocols.tcp-ip
Subject:   Re: Naive questions about subnets & domains


This is more of a question than an answer, but you might find it
interesting...

It would seem to me that whether you stick your other sites in your
class B depends on whether those remote sites will eventually have
entry points to outside networks.  Existing routing technology is
pretty wretched about such things.  Case and point:

Suppose you have a network that consists of two or more locations,
that looks something like the following:


	Site A			 T 1		Site B
	Highspeed Internet	<--->		Backup Link
	Link

Well, what happens if the T1 goes down?  If each site has a different
net number, then with the blessing of appropriate routing gods, one
might even route through the Internet to get around the break
(forgetting policy issues, for the moment).  If you use the same
network, then Site A continues to advertise it as before, and the
chances are that Site B will most likely be screwed, depending on what
routing protocol is in use.

My question:

Does anyone see an answer to this problem, or have I defined the
problem incorrectly?

One way to handle such a break would be to transmit a subnet mask with
the route.  Yes, this would increase routing traffic, but one would
only do such a thing when attempting to correct a situation like the
one I described.
-- 
Eliot Lear
[lear@net.bio.net]

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 89 19:48:08 GMT
From:      bzs@ENCORE.COM (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   DecNet on TR


Decnet also runs over DMR11's (or it's older version, the DMC11.)

It had a few modes of interface including serial. At BU we ran DECNET
over DMR's using triax between a 2060 a VMS/780. We ran the DMR's at
250Kb, it ran at up to 1Mb but I remember field service mumbling
something about the DN20 or some such at that speed so we turned it
down.

	-Barry Shein

Software Tool & Die, Purveyors to the Trade
1330 Beacon Street, Brookline, MA 02146, (617) 739-0202

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 89 20:35:23 GMT
From:      mogul@decwrl.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: Naive questions about subnets & domains

In article <Aug.16.09.04.47.1989.26446@NET.BIO.NET> lear@NET.BIO.NET (Eliot Lear) writes:
>Suppose you have a network that consists of two or more locations,
>that looks something like the following:
>
>
>	Site A			 T 1		Site B
>	Highspeed Internet	<--->		Backup Link
>	Link
>
>Well, what happens if the T1 goes down?  If each site has a different
>net number, then with the blessing of appropriate routing gods, one
>might even route through the Internet to get around the break
>(forgetting policy issues, for the moment).  If you use the same
>network, then Site A continues to advertise it as before, and the
>chances are that Site B will most likely be screwed, depending on what
>routing protocol is in use.
 [...]
>One way to handle such a break would be to transmit a subnet mask with
>the route.  Yes, this would increase routing traffic, but one would
>only do such a thing when attempting to correct a situation like the
>one I described.

If I understand your suggestion, what you propose is that routing
protocol servers on the boundaries between a subnetted network and the
rest of the Internet would transmit subnet information about the
subnetted network to "external" routers.  I perceive an intention here
to allow routers outside the "broken" network to send packets via the
right boundary gateway.

 [I'm not quite sure how sending a "subnet mask" would accomplish this;
 knowing only the mask for a network doesn't allow one to infer what
 gateway is the optimal entry point for a given destination.]

The IP subnetting model does not allow this.  The whole point of
subnetting is to hide a certain amount of detail, in order to simplify
protocols and administration, and to keep the routing tables small.
Doing this only when the subnetted network is broken doesn't help; If a
large network with oodles of subnets partitions, the other routers on
the Internet would be hit with tremendous increase in routing table
complexity ... like a dam which bursts and floods the villages
downstream.

Subnetting reduces complexity at the expense of functionality.  You
can't compute "optimal" routes if you ignore certain kinds of
information, but that may be the price we must pay to be able to
compute routes at all.

There are better solutions to the "partitioned subnetted network with
multiple external gateways problem" (PSNWMEGP?).  For example, one could
do the responsible thing and provide multiple internal paths between
Site A and Site B.  Or, one could do something topologically
equivalent, which is to set up a "tunnel" between Site A and Site B
that acts like a real link between the sites, but is actually
implemented by source-routing packets through the Internet.  (There are
policy issues to worry about here.)  The most cost-effective solution
might be to set up a temporary SLIP link, over a dialup line, between
the two sites for the duration of the partition.

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 89 21:32:12 GMT
From:      chris@SALT.ACC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   Interop demo meeting?

Good afternoon,
		The response to my call for vendors interested in an SNMP
demo at Interop has been, in a word, GREAT!!! UNfortunately, it's now
getting hard to keep an up to date maillist of all those interested in
attending the meeting. People have said that the last week in August looks
good(somewhere between the 28th and the 31st). Now that I've gotten the
phone list together we are going to have the folks at ACE worrry about the
logistics of getting everyone to the same meeting room in San Jose on the
same day. We are going to float Wednesday as a possible date(Aug 30th).
Please let us know whether this looks feasible,
				Thanks for the interest,
							Chris VandenBerg
							ACC
							chris@salt.acc.com
							805-963-9431

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 89 21:33:48 GMT
From:      hughes@silver.bacs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip
Subject:   connect(2) timeout

Does anyone know how to modify the default time that it
takes for a connect(2) to time out?  I've tried
setsockopt(2) without success (I think that's for
reads and writes, not connect).  The default time of
1:15 is too long for my application.

I've even resorted to issuing a signal(3) for SIGALRM,
which causes the connect to fail with errno EINTR,
but it only works the first time.  Does anyone know
why?

Thanks for any information...

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



-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 89 22:32:39 GMT
From:      wingo@ncrcae.Columbia.NCR.COM (Dave Wingo)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip and T1


I am looking for some help in understanding tcp/ip utilizing a T1 interface.
Does a multiplexor exist that supports a tcp/ip connection directly? Do
I have to provide a SLIP type interface to gain access to an RS232 type 
multiplexor? Do multibus 1 cards exist which support direct T1 connections?
Is there interest in tcp/ip connections via T1? Any help on these questions
will be greatly appreciated...........

Thanks in advance..... David Wingo

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 89 00:18:58 GMT
From:      lap@udel.EDU (Larry Pearlstein)
To:        comp.protocols.tcp-ip
Subject:   Info on implementation details...

Can anyone tell me:

At what levels (interrupt, daemon, system driver, application 
program) are each of the seven network layers generally 
implemented in a typical TCP/IP system.  I imagine that the 
answers might differ depending on whether the host was a 
microcomputer, mini, or mainframe?  Since most micros are 
single-tasking, would daemons be available?

Thanks for any info.

                                   Larry Pearlstein
                                   lap@huey.udel.edu

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 89 13:21:32 GMT
From:      geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on implementation details...

In article <21853@louie.udel.EDU> lap@udel.EDU (Larry Pearlstein) writes:
>Can anyone tell me:
>
>At what levels (interrupt, daemon, system driver, application 
>program) are each of the seven network layers generally 
>implemented in a typical TCP/IP system. 

What seven levels? Not even ISO has seven levels. You need to read
Mike Padlipsky's "Elements of Networking Style" to get rid of
any such mystical numerological superstitions before embarking on
a study of real-world implementations. Then go read RFC817: Dave Clark
on "Modularity and efficiency in protocol implementation", and McKusick
on 4.3BSD.  One day John Romkey et al may get around to writing about
the PC/IP experience (John?). Comer's Xinu and TCP/IP books are
invaluable.

The bottom line: there are a LOT of different solutions that have been
tried.

Geoff Arnold,                              Internet: geoff@East.Sun.COM
PCDS Group, Sun Microsystems Inc.
---------------------------------------------------------------------------
My disclaimer is available via anonymous FTP as a compressed tar archive....

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 89 13:53:39 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Repeated ping responses?

Roy,

You may have caught it in an ugly mood. Using ICMP Timestamp messages, it
has a most satisfying and stable delay of 1609-1616 ms delay and clock
jitter of 8 ms max. With more data as yours, I would look for clusters of delay separated by 270 ms or so, the roundtrip
satellite delay. 

Dave

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 89 18:31:08 GMT
From:      hwajin@wrs.wrs.com (Hwajin Bae)
To:        comp.protocols.tcp-ip
Subject:   Re: connect(2) timeout

In article <24692@iuvax.cs.indiana.edu> hughes@silver.bacs.indiana.edu (larry hughes) writes:
>Does anyone know how to modify the default time that it
>takes for a connect(2) to time out?  I've tried
>setsockopt(2) without success (I think that's for
>reads and writes, not connect).  The default time of
>1:15 is too long for my application.

When connect() is requested, TCP protocol implementation in BSD 4.3-Tahoe 
will send a SYN packet and start a keep-alive timer.  Initially, when the
remote machine you're trying to connection to doesn't respond within
75 seconds (TCPTV_KEEP_INIT) with an ACK/SYN (initial phase of the TCP 
three-way handshake connection set-up protocol), the keep-alive timer will 
start sending a keep-alive packet (<SEQ=SND.UNA-1><ACK=RCV.NXT><CTL=ACK)>)
every 75 seconds (TCPTV_KEEPINTVL) until it receives a packet from the
other side or upto 8 times (TCPTV_KEEPCNT).   So, 8 * 75 => 600 == 10 minutes
in 4.3 BSD.  The constants in parentheses are defined in netinet/tcp_timer.h.
You can change the global variables "tcp_keepintvl" to change the
kernel's idea of TCPTV_KEEPINTVL using adb on BSD Unix.  As in,

% adb -k -w /vmunix /dev/mem
  tcp_keepintvl?W 60

Note also that these numbers tend to vary in different implementations as
well as in various releases of BSD Unix code itself.  Pre-4.3-tahoe releases
of the networking code only had TCPTV_KEEP (45 sec) and 
TCPTV_MAXIDLE (8 * 45 sec).

-- 
Hwajin Bae
Wind River Systems
1350 Ocean Ave
Emeryville, CA 94608

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 89 18:57:12 GMT
From:      hwajin@wrs.wrs.com (Hwajin Bae)
To:        comp.protocols.tcp-ip
Subject:   Re: connect(2) timeout

Of course, the 10 minute keep-alive timeout scenario is only valid
if you don't get anything from the remote system after sending the
initial SYN packet.  If you get something back from the remote system
that cancels the keep-alive timeout, TCP will get into a bit more
complicated retransmission stage -- and subsequently will take
longer for connect() to actually time out.  TCP will keep on retransmitting
the SYN packet until it receives ACK/SYN for it.  TCP retransmission back-off
is based on the binary exponential algorithm 
	(1, 2, 4, 8, 16, 32, 64, 64, 64, 64, 64, 64, 64)
and the retransmission time will vary from 1 to 64 seconds and happend
upto 12 times.

-- 
Hwajin Bae
Wind River Systems
1350 Ocean Ave
Emeryville, CA 94608

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 89 00:34:45 GMT
From:      kwang@infmx.UUCP (Kwang Sung)
To:        comp.protocols.tcp-ip
Subject:   SQL Engine running under ISODE interfacing with STREAMS TLI on 386

Question 1. 
	     Is there anybody know the SQL Engine Products running under
	     ISODE interfacing with STREAMS TLI on IBM 80386 ????

Question 2.  Is there any way to know the status of ISODE without
	     accessing ARPANET/MILNET ????

Kwang Sung
Informix Software, Inc
415-926-6758
UUCP: ...!uunet\!infmx\!kwang

-----------[000182][next][prev][last][first]----------------------------------------------------
From:      pyramid!infmx!kwang@hplabs.hp.com  (Kwang Sung)
To:        tcp-ip@NIC.DDN.MIL
Subject:   SQL Engine running under ISODE interfacing with STREAMS TLI on 386
Question 1. 
	     Is there anybody know the SQL Engine Products running under
	     ISODE interfacing with STREAMS TLI on IBM 80386 ????

Question 2.  Is there any way to know the status of ISODE without
	     accessing ARPANET/MILNET ????

Kwang Sung
Informix Software, Inc
415-926-6758
UUCP: ...!uunet\!infmx\!kwang
-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 89 06:10:05 GMT
From:      neil@zardoz.UUCP (Neil Gorsuch)
To:        comp.protocols.tcp-ip
Subject:   Re: the worm and internet security

In article <24248@santra.UUCP> jkp@cs.HUT.FI (Jyrki Kuoppala) writes:
>It's been proposed that security problems like those what the worm
>used, whenever found, should first be published on a restricted-access
>mailing list as soon as possible.  This mailing list should have all
>major Un*x vendors on it, so that they can rush bug-fixes to their
>clients as soon as possible.  Then, with for example a three-month or
>so delay, this mailing list would be relayed to a Usenet newsgroup.

The restricted access unix security mailing list already exists.  It
is primarily meant to be an advance warning system of newly found
security holes and problems.  I am appending the official blurb, which
eplains it more fully.  Please mail requests to join (after reading
the rest of this message, of course 8<), to security-request@cpd.com,
rather than directly to me at neil@cpd.com.  Be patient if I don't
answer your request in a timely manner, my mailbox is overloaded at
best, and I receive hundreds of new messages each week from various
sources.  Of course, if I don't respond to you within 2 or 3 weeks, it
can't hurt to try again, mail has been known to disappear 8<).

Neil Gorsuch
neil@cpd.com
uunet!zardoz!neil
(AKA security-request)

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

UNIX SECURITY MAILING LIST

The unix security mailing list exists for these reasons:

1. To notify system administrators and other appropriate people of
   serious security dangers BEFORE they become common knowledge.
2. Provide security enhancement information.

Most unix security mailing list material has been explanations of, and
fixes for, specific security "holes".  I DO NOT believe in security
through obscurity, but I certainly don't spread "cracking" methods to
the world at large as soon as they become known.  The unix security
list is, in my opinion, an excellent compromise between the two ideas.
It is not intended for the discussion of theoretical security
techniques or "Should we thank Mr. Morris?" types of subjects, there
is no need for secrecy regarding such matters, and appropriate usenet
news groups already exist that serve those purposes.  It is, however,
appropriate to post security checkup programs and scripts, and
specific security enhancement methods to this list in addition to the
proper news groups.  I assume that since the members of the list made
a special effort to join, they might appreciate appropriate material
being sent via email so that they don't have to sort through many news
groups to "catch" everything.

zardoz is well connected, having 51 uucp links including uunet, and is
in the process of becoming part of the Internet.  Reliable delivery is
available to any bang path or internet address.  Each mailing list
destination can choose to receive either automatically "reflected"
postings of all received material, or moderated digests that are sent
out about once a week.  There is a seperate posting address for
emergencies that reflects the received material to the entire mailing
list without any intervention on my part.

I typically require that destinations have an interest in unix site
security, or are involved in adding security enhancement software to
unix, but I am flexible.  To apply for membership, send email from one
of the following or send email requesting that I contact one of the
following (please arrange the former, it saves me time):

1.	For uucp sites with a uucp map entry, the listed email contact,
	map entry writer, or root.
2.	For internet sites, the NIC "WHOIS" listed site contact, or root.

Please include the following:

1.	The uucp map entry and map name to find it in, or the WHOIS
	response from the NIC and the request handle.
2.	The actual email destination you want material sent to.  It
	can be a person or alias, but must be on the same machine
	that you use as a reference, or in a sub-domain of said machine.
3.	Whether you want immediate reflected postings, or the weekly
	moderated digests.
4.	The email address and voice phone number of the administrative
	contact if different from the above.
5.	The organization name, address, and voice phone number if not
	listed already.

Please don't do any of the following:

1.	send email from root on machine_17.basement.podunk_U.edu and
	expect that to be sufficient for membership.  With
	workstations being so prevalent, and being so EASY to "crack",
	root doesn't mean much these days.
2.	send email from root on the uucp map entry listed site
	toy-of-son and expect that to be sufficient.  If you would prefer
	material sent to a home machine, verify your credentials through
	one of the previously mentioned methods.
3.	send mail from a network that I don't have any way to verify,
	such as bitnet or others.  I can verify uucp and internet sites.
	Send me some way to verify your credentials if you can't use
	an appropriate listed uucp or internet site.
4.	send me mail saying I can verify your identity and credentials
	by telephoning a long distance number.  I will continue to donate
	the extra computer capacity required for sending and archiving
	this list, and I will continue to spend the money on the extra
	uucp/internet communication costs that this list requires, but I
	draw the line at spending money on voice long distance phone calls.
5.	send me an application request that involves a lot of time and
	special procedures for verification.  Please try to make my
	processing of your application an easy matter.

All email regarding this list should be sent to:

security-request@cpd.com (INTERNET sites)
uunet!zardoz!security-request (UUCP sites)

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 89 06:23:45 GMT
From:      neil@zardoz.UUCP (Neil Gorsuch)
To:        comp.protocols.tcp-ip
Subject:   Re: the worm and internet security

In article <433@celit.UUCP> dave@celerity.UUCP (Dave Smith) writes:
>The idea of a security list circulating amongst the vendors and then going
>public after a few months is an excellent idea.  Pretending the problems
>don't exist is silly.

Sheesh, I should probably hire an ad agency, nobody knows about the
unix security mailing list 8<).  Please see my previous posting for
more information, or write to security-request@cpd.com.

Neil Gorsuch
(AKA security-request)
neil@cpd.com
uunet!zardoz!neil

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 89 07:27:52 GMT
From:      viktor@phoenix.Princeton.EDU (Viktor Dukhovni)
To:        comp.protocols.tcp-ip
Subject:   SubSubNets ???


	Consider following topology:

			.... The universe
			|
			|
 G0
			|
			|
 ==Net 1===============================   Subnetted Class B net
			|			 with say 6 subnet bits
			|  
 G1
			|
			|
       ===Net 2==============================  Same Class B net with 9
	       |			|	       subnet bits ???
	       G2			G3
	       |			|
	=====Net 3=====		    =====Net 4====  Both have 9 subnet bits.
						    Still same class B net???


	Usually one would assign Class C addresses to
nets 3 & 4, not subsubnet,  and advertise routing information for both.

	Instead it is tempting to hide the interior topology from the rest of
the world,  by having different netmasks on the two interfaces of G1.

	This should cause no problem for G0 which should perceive
the network behind G1 as being flat,  also G2 & G3 are ok since they
can simply "route add default G1".

	All the potential trouble arises on G1,  which no longer has a clear
notion of the correct subnet mask for the class B net in question.

	And yet I think that there is a natural scheme for allowing this
new behaviour.

Rule:
-----
	Given an address X, whose standard network part (Y) matches
the standard network part of a non zero number of interfaces on a host,
consider the network part of that address to be:	

1)  X & IPNETMASK(i),  if  (X & IPNETMASK(i)) == (IPADDR(i) & IPNETMASK(i))
	for some interface i.
    That is, if X is an address of a host on the network connected to
    interface i [ Or we think is so anyway, this network could be further
    subsubnetted,  but what we don't know can't hurt us, right???
    After all we are tryin to play hide redundant information! ]

or
2)  X & Intersection(IPNETMASK(i))  if  none of the interfaces are directly
	  std(i)=Y
    connected to X.

	The motivation behind part 2, is that in a sub-subnet situation
addresses not on one of the "would be Class C" nets,  must be on the 
other side of G1,  and so should use the coarser netmask.

	The host part of the address should then be X & ~(IN_NETOF(X)).
	
	Such schemes are not supported by the current sys/netinet/in.c
code.  Here is a proposed change to  in_netof(),  that would implement part
of this policy.
	
	I would like to solicit comments on the folly/wisdom of
this analysis.  

--
	Viktor Dukhovni		<viktor%math@Princeton.EDU>	: ARPA
				<...!princeton!math!viktor>	: UUCP

------- in.c -------
*** /tmp/da2073	Fri Aug 18 02:26:12 1989
--- sys/netinet/in.c	Fri Aug 18 02:25:58 1989
***************
*** 78,83 ****
--- 78,84 ----
  {
  	register u_long i = ntohl(in.s_addr);
  	register u_long net;
+ 	register u_long mask = ~0L ;
  	register struct in_ifaddr *ia;
  
  	if (IN_CLASSA(i))
***************
*** 90,102 ****
  		return (0);
  
  	/*
! 	 * Check whether network is a subnet;
! 	 * if so, return subnet number.
  	 */
  	for (ia = in_ifaddr; ia; ia = ia->ia_next)
! 		if (net == ia->ia_net)
! 			return (i & ia->ia_subnetmask);
! 	return (net);
  }
  
  /*
--- 91,112 ----
  		return (0);
  
  	/*
! 	 * Check whether network is subnetted;
! 	 * Allow a subnet gateway to SUBSUBNET!
! 	 * This means that the subnet mask is
! 	 * The smallest is no interface matches,
! 	 * or the subnet mask for a particular interface 
! 	 * if that interface matches.
! 	 *  Note that this code reduces to the usual case
! 	 *  if all the netmasks are the same.
  	 */
  	for (ia = in_ifaddr; ia; ia = ia->ia_next)
! 		if ( net == ia->ia_net ) {
! 			if ( (i & ia->ia_subnetmask) == ia->ia_subnet )
! 				return(ia->ia_subnet) ;
! 			mask &= ia->ia_subnetmask ;
! 		}
! 	return (~mask ? mask&i : net);
  }
  
  /*

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 89 13:20:58 GMT
From:      randall@uvaarpa.virginia.edu (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: questions about subnets & domains

%	1) using subnets for remote networks and limiting my connections
%	   in the future
% or	2) getting distinct network numbers to leave me flexibility in the
%	   future

In article <164@jove.dec.com> mogul@decwrl.dec.com (Jeffrey Mogul) writes:
>The most basic rule of subnetting is that, if you go with option #1,
>the subnets must be connected to each other via a path that doesn't
>ever leave your class B network.  If you cannot arrange internal links
>between the home office and the branch offices, then you are not really
>allowed to use option #1.
>
>If you can use option #1, there are two potential problems:
>    (a) Except for sites with hand-crafted routes into your network, it
>    will nearly impossible to say "use gateway X between the Internet
>    and the home office, but use gateway Y between the Internet and the
>    Amsterdam office."  This means that there may be some packets that
>    go around the world when they only need to travel a few miles.  For
>    example, if your primary Internet gateway is in California, and a
>    customer in Amsterdam tries to send a packet to the Amsterdam office,
>    the packet will flow via California.

I imagine that most of the traffic would be mail and with mail it is
simple to set up MX records so that mail to a site in Europe would go
via European gateways and mail destined for the US would go via
US gateways.  In short, I'm not sure that the above is all that
overriding a concern.

>    (b) Nasty people in Amsterdam, if they know that Adobe is paying
>    for an internal IP link between their city and California, could
>    try to save money on their own phone bills by routing their
>    packets through your network.  This should not happen with normal
>    routing protocols; anyway, it is a simple matter to provide access
>    control mechanisms in your routers to deny forwarding of such
>    "transit" packets.

Again, this really isn't much of a problem because as noted above,
you can configure things so that such improper forwarding would
be prevented.  

>If you use option #2, then neither of these two problems exists.
>On the other hand, the size of the Internet routing tables is
>growing at a frightening rate, and I'm sure people would rather that
>you kept the number of networks as low as possible.  Although
>option #2 may be better for some specific situations, for the
>community as a whole, the fewer networks the better.

Really neither of these is much of a "problem" even for option 1
and if I were in the position of trying to manage an internal
network of this size, I'd make sure it was all internally connected
and go with option 1 because I'd find that easier to manage.

In the case of GE, all of our sites interconnect and are setup
such that we always use the internal connections to pass traffic
rather than sending data over someone else's network.  In most
cases, this kind of setup is preferable both for the firm and
for the network community as a whole.

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 89 15:58:00 GMT
From:      gors@well.UUCP (Gordon Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on implementation details...

In article <718@east.East.Sun.COM> geoff@East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
>
>What seven levels? Not even ISO has seven levels. You need to read
>Mike Padlipsky's "Elements of Networking Style" to get rid of

	Physical Layer
	Data Link Layer
	Network Layer
	Transport Layer
	Session Layer
	Application Layer
	Presentation Layer

I count seven. But then, I'm off caffeine this week, so maybe I miscounted! :-)

In answer to the original query, and your flippant reply, it is true that most
implementations provide a programmatic interface, which means Transport level
at best, with some Session material (connection-oriented sockets).

There is considerable effort to implement all seven (SEVEN, count 'em) layers
of ISO OSI on top of TCP/IP, despite the fact that they are not isomorphic
in the first few layers. DOD and others have a big investment in TCP/IP, but
there is a billion dollar push for OSI.

The physical and data-link layers are usually hardware/device - driver level;
The Network and Transport level services are provided by daemon processes
in most unix systems - session level services involve library function calls
that give access to lower levels.




-- 
				{apple, pacbell, hplabs, ucbvax}!well!gors
							gors@well.sf.ca.us
(Doolan) | (Meyer) | (Sierchio) | (Stewart)

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 89 16:10:19 GMT
From:      keith@spider.co.uk (Keith Mitchell)
To:        comp.protocols.tcp-ip
Subject:   Re: Naive questions about subnets & domains


I believe the solution which puts international subsidiaries into
subdomains of the country they are in is not, in general at least,
the correct solution.

My understanding is that the the domain name space reflects an
*organisational* not geographical, hierarchy.  It is thus valid to
have sites which are in another country be subdomains of the parent
company that is a sub-domain in its own country.

i.e. We are "spider.co.uk". We have US and French subsidaries, which
are "boston.spider.co.uk" and (soon) "paris.spider.co.uk" . These
are sub-organisations within the bigger spider organisation, and the
names reflect the organisational heirarchy.

I would say that ".convex.oxford.ac.uk" is invalid, as a company
cannot be part of Oxford University in its role as part of the UK
Academic Community.

For spider, mail routing works because our only point of contact
with the external world is a UK site, international delivery is an
internal operation.

Now, if our international subsdiaries had their own links to the
outside world, in the country they are geographically located in,
then it would be appropriate for them to be registered in that
country's domain (e.g. spider.com and spider.fr).

Without the external links in the relevant country, routing which is
done on top-level domains will get confused. i.e. If we were to
register our US site as spider.com, someone in the UK mailing this
would have it routed to a US backbone site that knows about .com,
which would know you get to Spider via the UK, so back it goes.

Whether the internal and external links use UUCP, the Internet or damp
string is actually irrelvant to naming.

So, I think the general rule is to register a site as a sub-domain of
the country its mail link to the outside world is in. This does not
preclude registering a site more than once.

What we would ideally like is to have a domain ".spider", which all
our machines and sites are in from an internal point of view. This
would be registered as a sub-domain of all necessary countries, with
an external mail link in each of them. Thus, edinburgh.spider.com,
boston.spider.fr, and paris.spider.co.uk are all valid, the top level
domain merely dictating the point of entry to our internal mail
system, and the bottom one where it finishes up.  This fits in with
global mail routing based on domains.

Is this sensible ? Does the domain name system permit the same entity
appearing in distinct sub-domains, or have I the wrong end of the stick ?

I better make it clear that the above represents my current thoughts on
this topic, rather than any offically decided company policy.

Keith Mitchell

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

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

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 89 18:15:15 GMT
From:      sscott@camdev.UUCP (Steve Scott)
To:        comp.protocols.tcp-ip
Subject:   Need tftp and bootp sources



-- Flame deflector shields up, Scotty

I KNOW that sources are to be requested elsewhere but this
source is so intimately tied to this discussion group that I
thought that I would be brave (brazen?) and post it here

I need Sys V bootp and tftp source for use with some cisco Systems
routers which we recently purchased.  Unfortunately for me, my
software vendor (who shall remain unnamed) provides neither of these
with their unix derivative HP/UX.  How is that for skirting the
"let's point the proverbial finger" issue 8-)?

Any hints/clues/suggestions?

P.S.  I do not have internet (anonymous FTP) capability YET.  So,
if anyone can help, we will have to work out a mail/tar tape, etc
solution


-- 
Steve Scott            UUCP: {attctc|texbell}!camdev!sscott
Motorola, Inc.         Telephone : 1-817-232-6317

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 89 18:57:13 GMT
From:      haral@unisol.UUCP (Haral Tsitsivas)
To:        comp.dcom.lans,comp.sys.mac,comp.protocols.tcp-ip,comp.protocols.appletalk
Subject:   Re: Summary: Backup via network

In article <1989Jul21.014826.19864@comp.vuw.ac.nz> tony@rata.vuw.ac.nz (Tony Martindale) writes:
>	 BACKUP VIA NETWORK, REQUEST FOR INFO. SUMMARY
>	 =============================================
> *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.
> ...

I would have posted this earlier but I am just catching up with my news
reading...

Take a look at one of our products, SysAdmin...  Among other features,
it provides backup, restore and archive functions, with support for
both remote tape drives and remote filesystems for either System V or BSD 
systems.  Only TCP/IP is needed...

-- 
--Haral Tsitsivas
  UniSolutions Associates
  (213) 542-0068
  ...!uunet!ashtate!unisol!haral

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 89 22:04:13 GMT
From:      desnoyer@apple.com (Peter Desnoyers)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   More about NCSA Telnet FTP speed

Well, after all the discussion back and forth about FTP speed on the 
Macintosh, I went out and did a few experiments. All of these were with 
NCSA Telnet 2.3, with a release letter dated July 15. Make of it what you 
may. Disclaimer - I am not speaking for Apple, your mileage may vary, etc.

   Sun 3 -> Macintosh II, NCSA Telnet with NCSA TCP code -
        4.4kbyte/sec ASCII, 4.9kbyte/sec binary

   Sun 3 -> Sequent Balance (for comparison) (didn't have 2 sun accounts)
        75kbyte/sec ascii, 212kbyte/sec binary

   Sun 3 -> Macintosh II, NCSA Telnet with MacTCP, 8000 byte write buffers
        35kbyte/sec ascii, 45kbyte/sec binary

   Sun 3 -> Mac II, NCSA Telnet with MacTCP, 65536 byte file buffers
        43kbyte/sec ascii, 45kbyte/sec binary

   Sun 3 -> Mac II, NCSA Telnet, MacTCP, write calls commented out 
   (no disk traffic)
        49kbyte/sec ascii, 48kbyte/sec binary

   File write benchmark, Mac II with SC80 hard drive -
        8000-byte buffers - 277kbyte/sec
        30000-byte buffers - 452kbyte/sec
        100000-byte buffers - 385kbyte/sec
[note - I'm not too confident in this benchmark, especially the 
452kbyte/sec figure. ]

                                      Peter Desnoyers
                                      Apple ATG
                                      (408) 974-4469

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 89 23:12:36 GMT
From:      lap@udel.EDU (Larry Pearlstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on implementation details...

> At what levels (interrupt, daemon, system driver, application 
> program) are each of the seven network layers generally 
> implemented in a typical TCP/IP system.  I imagine that the 

I have received a proper scolding for using the "seven layer model"
in the same sentence with "TCP/IP".  I actually was aware that TCP/IP
did not strictly adhere to the ISO model.  Still, it has been my impression
that a "typical" TCP/IP system might correspond roughly as follows:

	Physical & data link		Ethernet
	Network				IP
	Transport			TCP
	Session				RPC
	Presentation			XDR
	Application			user application

Is there some heresy in this conceptualization?

I didn't want to spell out the RPC, XDR, ... layers in the question
in the hopes of receiving the most general responses.

Thanks for all those who responded (either by mail or on the net).  If
I get a few more mail messages, I'll summarize to the net.

                                   Larry Pearlstein
                                   lap@huey.udel.edu

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 89 00:58:26 GMT
From:      perand@ttds.UUCP (Per Andersson)
To:        comp.protocols.tcp-ip
Subject:   Re: Novell and TCP/IP

In article <18985@mimsy.UUCP> chenn@tame.cs.umd.edu (Jenn-San Peter Chenn) writes:
>
> I would like to make more infomation about tcp/ti on ibmpc. With or 
>W/O Novell. What HW or SW do I need? Who is selling them ? Thank you.


One thing you might want to try is using a packet driver ( See packet driver 
announcements ). This allows you to let your own PC run both IPX and , for 
example NCSA Telnet simultanously ( is my spelling correct ? ). You have
to get a special version of IPX from Novell of course. And you might have to
change the drivers on the server too. I think you have to have the type-field/
length field in the ethernet frames set to 8137, which is assigned to Novell.
In some versions of Novells drivers the field is interpreted as a length field
( that's 802.3 i think ). In this case you can run applications which support 
packet driver from your local disc. If you run them from the server you will 
need a server that support RARP or something equal. This because if you, 
as you can do in NCSA Telnet, put a fixed IP-number in a configuration file, 
all clients starting the program will get the same IP-number. BANG - goes your 
network. I have been running this configuration for a couple of weeks and it
has been working really well.

Per
-- 
Per Andersson
Royal Institute of Technology, Stockholm, Sweden
perand@admin.kth.se, @tds.kth.se, @nada.kth.se 
or perhaps {backbone}!sunic!ttds!perand

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 89 01:39:36 GMT
From:      smart@ditmela.oz (Robert Smart)
To:        comp.protocols.tcp-ip
Subject:   Re: CERT Internet Security Advisory

Australia is about to establish a Research network. Security is a hot topic.
I have been arguing the need for the network to have a security officer to
coordinate security measures, and to cooperate with other research
networks and with computer vendors on security matters. So I am pleased
to hear about the Computer Emergency Response Team.

In article <3858@fy.sei.cmu.edu> krvw@sei.cmu.edu (Kenneth Van Wyk) writes:
>
> o Test telnet for unauthorized changes by using the UNIX "strings"
>   command to search for path/filenames of possible log files.  Affected
>   sites have noticed that their telnet programs were logging information
>   in user accounts under directory names such as "..." and ".mail".

It seems that the code could easily be written so that "strings" doesn't
show anything.
>
> o Test authenticity of critical programs - Any program with access to
>   the network (e.g., the TCP/IP suite) or with access to usernames and
>   passwords should be periodically tested for unauthorized changes.
>   Such a test can be done by comparing checksums of on-line copies of
>   these programs to checksums of original copies.  (Checksums can be
>   calculated with the UNIX "sum" command.)  Alternatively, these
>   programs can be periodically reloaded from original tapes.

Is "sum" designed to be a security device? If not it is probably easy
to arrange for the checksum to be unchanged. I would like to see a
checksum like program that was designed like an encryption algorithm:
very hard to alter and keep the checksum the same.

> o Apply fixes - Many of the old "holes" in UNIX have been closed.
>   Check with your vendor and install all of the latest fixes.

Vendors remain shockingly unconcerned about security issues. What do
we do about machines which don't have software maintenance? Should they
be barred from Internet access? Since the BSD 4.3 network stuff is 
publically available I think we should be able to plug network holes
in unix systems, even for machines which don't have software
maintenance.
>
> If system administrators do discover any unauthorized system activity,
> they are urged to contact the Computer Emergency Response Team (CERT).
>

So what does CERT do between emergencies? What I would like to see is
the creation of a shell script to check machines out for security. It
should be something like the "rn" installation script [a brilliant
bit of work]: work out what its environment is, and make appropriate
investigations and even offer to install updated software where appropriate:
It might go like this:

  % security-check

  Still running SunOS 3.5 eh? For internet network performance you should
  switch to a more recent version.

  Gack! You're still running the old fingerd. You must remove it! Would
  you like me to install a safe version [yn]?

etc.

The shell script should also check for obvious bad passwords: words, first
names, password=login name, etc. It should check for potential configuration
problems (like + in hosts.equiv). 

It would be nice to see similar mechanisms for other common operating
systems, which probably means VMS. This would require cooperation from
the vendors of VMS tcp/ip software. Non-cooperaters banned from the internet!

Another thing CERT could do is check machines from the internet to see
if they exhibit known security bugs. 

Bob Smart <smart%ditmela.oz.au@uunet.uu.net>

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Aug 89 09:04:12 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        lap@louie.udel.edu, tcp-ip@nic.ddn.mil
Subject:   Re: Info on implementation details...
Previous messages certainly have pointed out the dangers of asking about
TCP and the seven-layer model and protocol implementation.  They certainly
are correct that there is no straightforward, objective, single "truth"
in dealing with either.

However,

It is useful to try to view TCP in terms of the 7-layer model, simply
because the 7-layer model is the international lingua franca for protocol
discussions.

Your suggested association of Ethernet/IP/TCP/RPC/XDR/Appl is quite
reasonalbe, as a first-order approximation.  I used just that model for
a couple of years, until a few other beat me unmercifully.  The
modifications that I suggest are:

IP resides at the internet SUB-layer of the network layer.  X.25 has 3
sub-layers, of which the top resides at the SUB-network SUB-layer of
the network layer(layer 3).  (Yes, it is a mouthful.)  When using
ethernet, the subnetwork layer is null.

TCP has some session functionality in it, and therefore crosses into part
of layer 5.

Referring to XDR and RPC is correct, but mostly confusing, since they
are used by so few of the application protocols.  (I.e., none of the
official, standard applications.)

With respect to implementation choices -- and keeping in mind the obvious
religious furvor that this topic can generate:

Physical layer usually is in a device driver and link layer (or part of
it) often is.

Network and Transport usually are in the kernel, both for performance and
multiplexing reasons.  (They have multiple clients and many o/s's have trouble
getting applications to provide reasonable service from one user program to
a number of others.)

For the TCP world, the rest is in individual user-level programs.

For the OSI world, there seems to be a tendency to put layers 5-7 into
individual user-level programs, but I have run into at least a few attempts
to put session into the kernel.  Haven't heard of Presentation being in the
kernel, and my current level of understanding suggests that that would not
make sense, anyhow.

Dave
-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 89 04:16:09 GMT
From:      karn@ka9q.bellcore.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Repeated ping responses?

In article <3936@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>
>	Note that ping 15 got answered twice.  What causes that?  It
>doesn't seem like a fluke -- I tried pinging 132.247.5.1 three times and
>each time got a doublet within the first 10 or 20 packets. [...]

A few days ago I was pinging my way around the NSFNet/Internet, measuring
round trip delays and comparing them to some expected values I had computed.
I too noticed that quite a lot of packet duplication was going on.

When pinging berkeley.edu from rotgut.bellcore.com, I consistently saw a 10%
packet duplication rate. Traceroute showed a perfectly reasonable path from
bellcore-net through JvNCNet, NSFNet and BARRNET to Berkeley.

This got me curious, so I started to isolate the problem. I could ping JvNC's
last router (the one adjacent to their NSF backbone switch) with no packet
duplication and virtually no loss. But when I pinged the NSS at Merit, just
one hop away from JvNC, I began to see duplicate packets.

I therefore concluded that the duplication was happening inside NSFNet. Does
anyone have any independent knowledge of this, or can anyone offer an
explanation of what mechanism could be responsible? It's hard to understand
how packets can get duplicated in the Internet unless there is a
retransmitting link-layer protocol somewhere.

Phil

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 89 06:11:13 GMT
From:      jim@syteke.UUCP (Jim Sanchez)
To:        comp.protocols.tcp-ip
Subject:   Re: Novell and TCP/IP

Since this question has come up several times, I thought I'd mention that
Hughes LAN Systems (Formerly Sytek) has had support for multiple protocols
for some 2.5 years now.  With our stuff you can run Novell, TCP/IP, and LAT
concurrently.  This is kinda nice when you want to FTP directly to a file
server without having to store the file on your pc in the interim.  Please
contact your local sales/tech guy at HLS for the details.  And, like any
good vendor, you have to buy our cards.
-- 
Jim Sanchez  {sun,hplabs}!sun!sytek!syteke!jim OR
Hughes LAN Systems, Brussels  mcvax!prlb2!sunbim!syteke!jim

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Aug 89 17:24:50 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        adobe!@decwrl.dec.com.shore, keith@spider.co.uk
Cc:        dpz@convex.com, tcp-ip@nic.ddn.mil
Subject:   Re: Naive questions about subnets & domains
The mail path for a specific host is unrelated to its location in the
domain name space.  Hence, Keith, your suggestion does seem to fit my
understanding of domain name/mail system performance, although it DOES
match most people's intuition about the system.

Any leaf entry (host reference) may have any IP address for itself or its
MX (mail relay) attributes.

Dave
-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 89 16:04:12 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on implementation details...

Previous messages certainly have pointed out the dangers of asking about
TCP and the seven-layer model and protocol implementation.  They certainly
are correct that there is no straightforward, objective, single "truth"
in dealing with either.

However,

It is useful to try to view TCP in terms of the 7-layer model, simply
because the 7-layer model is the international lingua franca for protocol
discussions.

Your suggested association of Ethernet/IP/TCP/RPC/XDR/Appl is quite
reasonalbe, as a first-order approximation.  I used just that model for
a couple of years, until a few other beat me unmercifully.  The
modifications that I suggest are:

IP resides at the internet SUB-layer of the network layer.  X.25 has 3
sub-layers, of which the top resides at the SUB-network SUB-layer of
the network layer(layer 3).  (Yes, it is a mouthful.)  When using
ethernet, the subnetwork layer is null.

TCP has some session functionality in it, and therefore crosses into part
of layer 5.

Referring to XDR and RPC is correct, but mostly confusing, since they
are used by so few of the application protocols.  (I.e., none of the
official, standard applications.)

With respect to implementation choices -- and keeping in mind the obvious
religious furvor that this topic can generate:

Physical layer usually is in a device driver and link layer (or part of
it) often is.

Network and Transport usually are in the kernel, both for performance and
multiplexing reasons.  (They have multiple clients and many o/s's have trouble
getting applications to provide reasonable service from one user program to
a number of others.)

For the TCP world, the rest is in individual user-level programs.

For the OSI world, there seems to be a tendency to put layers 5-7 into
individual user-level programs, but I have run into at least a few attempts
to put session into the kernel.  Haven't heard of Presentation being in the
kernel, and my current level of understanding suggests that that would not
make sense, anyhow.

Dave

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 89 00:24:50 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: Naive questions about subnets & domains

The mail path for a specific host is unrelated to its location in the
domain name space.  Hence, Keith, your suggestion does seem to fit my
understanding of domain name/mail system performance, although it DOES
match most people's intuition about the system.

Any leaf entry (host reference) may have any IP address for itself or its
MX (mail relay) attributes.

Dave

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 89 01:07:11 GMT
From:      dpz@convex.com (David Paul Zimmerman)
To:        comp.protocols.tcp-ip
Subject:   Re^2: Naive questions about subnets & domains

I agree that .convex.oxford.ac.uk is pretty bogus.  Optimally, what I'd like
to see is all our sites worldwide simply living under .convex.com.  Hopefully
this will become reality as we expand our internal network.

						David

David Paul Zimmerman                                             dpz@convex.com
CONVEX Computer Corp                                                 convex!dpz

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 89 06:49:18 GMT
From:      thomas@uplog.se (Thomas Hameenaho)
To:        comp.protocols.tcp-ip
Subject:   Re: IP on X.25


Thank you all for replying.
I should have said that we already have a connection to the nordunet that
works very well. However due to political reasons we are not allowed to
use it other than for mail and news. We can't even use it for mail
without restrictions as we get filtered out when we try to get outside
of the nordunet, we have to use a relay host that is not restricted.

I've talked to people in the management of the network and they said
it has been discussed but no decision has been made yet.

We are of course prepared to pay for the service and I think this could
be a way of partly financing the network. But no luck at this moment.

You guys on the other side of the big water should be grateful to
the military and the government you have that is foreseeing.
On this side we only have the greedy telecom companys and governments
that doesn't see longer than the nose reaches. No wonder that the
news in the computer business comes from your side.

Boy do I despise bureaucrats!

Thomas
--
Real life:	Thomas Hameenaho		Email:	thomas@uplog.se
Snail mail:	TeleLOGIC Uppsala AB		Phone:	+46 18 189406
		Box 1218			Fax:	+46 18 132039
		S - 751 42 Uppsala, Sweden

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 89 10:35:44 GMT
From:      wasc@cgch.UUCP (Armin Schweizer)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   SNMP Implementations




SNMP Implementations
____________________

We are running Internet and DECnet networks on our sites. Compared
with DECnets capabilities for network management, Internet has
been weak in our installations (is this also true in other
installations?).

Since SNMP has been standardized very fine in RFC1098 etc. I would
like to know if somebody knows of a complete implementation on the
market for SUN-UNIX and VAX-VMS machines.

As I understand from the RFC1098 etc. I get the understanding,
that SNMP is mainly intended for collecting (traffic ..) information,
but restricted in support for trouble shooting. I hope, there
is somebody who will correct this interpretation.

Is there somebody (or do you know somebody) who is running
Internet and DECnet concurrently? I would like to discuss
the related problems with him (e.g. how to collect
operator messages out of VMS, UNIX and gateway machines at a 
single location/printer).



       Armin R. Schweizer, CIBA-GEIGY AG, R1045.P.06, WRZ
                  4002 Basel / Switzerland
	          phone: -41-61-697'79'46

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 89 12:19:51 GMT
From:      rudolf@konech.UUCP (Heinz Rudolf)
To:        comp.protocols.tcp-ip
Subject:   Urgent data handling in TCP/IP


--- Skip this if you are not involved with protocols internals ----

  Maybe this has been asked before, but I couldn't find a clear description
in the MIL Spec's and wont take BSD as reference.

  As far as i interpret the MIL spec 1778, urgent data are handled as normal
data concerning sequence numbering. Some points are however are not clear.

- can their be more than one urgentdata request be outstanding in the sender?
  6.5.6.3.1 tells that for urgent data "sv_*.send_urg := sv_*.send_queue_length"
  which on alternate normal and urgent data sends may declare some normal
  data as expedited.

- If urgent data are present, they will be at the head of the segment text,
  (says 9.3.10). This is a difference ordering as done by the sequence
  numbers. Can the urgent data be sent alone, not starting at rcv_nxt ?
  (because there may be already lost of bytes of normal data, filling the
  sned buffer) If normal data are already present, must they be present up
  to the sequence numbers of the urgent data ? (would be according to
  "try to deliver 6.5.6.3.14")

- As far as i interpret 1778, urgent data will be subject to the normal
  sequence number ordering. This means that urgent data cannot be presented
  to ULP unless all normal data up to the start of urgent data have been
  received?

 
 May be this is answered in 1778, if so, it's not made very clear.

                            Thanks in advance

-------------------------------------------------------------------------------
 Heinz Rudolf                              mcvax!unido!konech!rudolf
 Kontron Elektronik
 West Germany 
-------------------------------------------------------------------------------
 Probleme - Igitt

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Aug 89 18:22:37 EDT
From:      Doug Nelson <08071TCP%MSU.BITNET@CUNYVM.CUNY.EDU>
To:        Keith Mitchell <keith@spider.co.uk>
Cc:        dpz@convex.com, "TCP/IP list (plus more)" <tcp-ip@nic.ddn.mil>
Subject:   Re: Naive questions about subnets & domains
>What we would ideally like is to have a domain ".spider", which all
>our machines and sites are in from an internal point of view. This
>would be registered as a sub-domain of all necessary countries, with
>an external mail link in each of them. Thus, edinburgh.spider.com,
>boston.spider.fr, and paris.spider.co.uk are all valid, the top level
>domain merely dictating the point of entry to our internal mail
>system, and the bottom one where it finishes up.  This fits in with
>global mail routing based on domains.
>
>Is this sensible ? Does the domain name system permit the same entity
>appearing in distinct sub-domains, or have I the wrong end of the stick ?

It's certainly possible to do this.  All you would need to do is register
spider.com and spider.fr as CNAMEs to spider.co.uk.  This should do just
what you're asking, apart from any MX's, etc.  But remember then that
all of your systems would have to be prepared for mail under any of the
three names.

Doug Nelson
Michigan State University
-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 89 15:58:52 GMT
From:      gary@dvnspc1.Dev.Unisys.COM (Gary Barrett)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Comparing Performance of TCP/IP or OSI on Multivendor Equipment


I would be interested in hearing from anyone on the net who is
wrestling with the problem of benchmarking TCP/IP and OSI software
across equipment from various vendors.

I have posted a similar inquiry on this subject about a month ago,
questioning whether there are any standard benchmarking programs to do
such an evaluation.  I had very few responses.  The only benchmark
tool seemingly available (for TCP/IP) is ttcp.  

Certainly, others "out there" must be wrestling with the problem of
of "standard" networking software. How can it be analyzed across
systems such that users can fairly decide whether one product is clearly
superior to another?  Standard benchmarks are evolving for Transaction
Processing.  So why not for standard network services like FTAM or
TELNET sessions?  I know that vendor Marketeers often quote numbers,
but unless those numbers are backed by agreed-upon benchmarks, those
numbers amount to snake-oil (at worst) and apples-to-oranges analyses
(at best).

I welcome any comments anyone may have on this subject.  I would be
especially interested in hearing from "users",  how you expect to
evaluate Open-Network offerings as part of your formal purchasing process.

Thanks.


Gary L. Barrett
Unisys
Devon Engineering Facility
Wayne,  PA

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 89 20:28:14 GMT
From:      morrison@accuvax.nwu.edu (Vance Morrison )
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   PCroute and PCbridge available from a MAIL server


Hello,

For all of you who have written me that you can't get PCroute or
PCbridge because you don't have FTP access, here is your solution.

Brian Nelson of the Univ. Of Toledo has very generously taken the
time and disk space to make PCroute and PCbridge available via
Bitnet and a MAIL server.  

I have personally tested the mail server and it seems to work.
Follow the instructions below and the mail server will send you about
20 mail messages (for PCroute) containing each of the files in the
distribution.  Binary (executable) files have been uuencoded.
You will have to edit out the mail headers on the ASCII file. (using
BITNET with the SEND command is preferable since you don't have to
edit out mail headers).  The mail server usually takes overnight
to retrieve your files for you, so be patient.

Please don't retrieve PCroute immediately if you don't need it,
have pity on the poor mail server.  Also you may want to drop a
quick thank you to Brian (brian@uoft02.bitnet) for providing this
service.

PCroute and PCbridge as always is also available by anonymous FTP 
from accuvax.nwu.edu (129.105.49.1) in pub/pcroute.

Vance

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

Vance,
 
The pcroute files are currently online. There are several ways in
which they can retrieved. For bitnet nodes running VAX/VMS and
Jnet software, a command of the form:
 
$ send vmsserv@uoft02 vmsdump pcroute.package
$ send vmsserv@uoft02 vmsdump pcroute-exe.package
 
will insure that no intervening nodes will affect character
translation. For those VMS sites (and non-Bitnet VMS sites) which will
have to use mail, send a mail to vmsserv@uoft02.bitnet with the line:
 
send pcroute-vms-share.package
 
in the body of the mail message. When all 50 parts arrive, concatenate
them and execute the resulting file as a dcl command procedure.
 
 
Nodes not running VMS can either mail or send a message to vmsserv
containing:
 
SEND PCROUTE.PACKAGE
 
Help is available, as well as a complete directory of all files via:
 
HELP
DIR
 
The same above apply to PCBRIDGE, simply replace PCBRIDGE with PCROUTE
resepectively.

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 89 22:29:42 GMT
From:      gahooten@titan (Gregory A. Hooten)
To:        comp.protocols.tcp-ip
Subject:   NCSA ftp verses direct connect Problems

I have NCSA vers 2.2 for PC and 2.3 for mac.  I am trying to log into a remote
server with the address of 128.149.32.3.  I am able to login and FTP with the
PC, and to FTP with the mac, but when I try a direct connection, I get an 
error of "Unable to connect to ..." and then "Local Host or Gateway not 
responding"  I have no idea what to do with this message, especially because
the other ways work so well.  Any help would be appreciated.  

I am running through ethernet on all computers, and have an ip number on each
entered into the MYIP line of Config.tel.  I can also log into Unix machines
that are local to me, i.e. within the company, but not outside of it.  This
is strange that the PC would access a system through essentially the same 
connections as the mac, but the mac will not connect. 

HELP

Greg Hooten
GAHOOTEN@ames.arc.nasa.gov

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 89 01:42:46 GMT
From:      shj@ultra.UUCP (Steve Jay)
To:        comp.protocols.tcp-ip
Subject:   Source for SYSV Telnet?

The 4.3-Tahoe Telnet has all of the system dependent terminal stuff
in one module, sys_bsd.c.  Has anyone done the work to create
the SYS V equivalent of that routine?  Is source for the SYS V
equivalent available?

Thanks for any help you can give me.

Steve Jay
Ultra Network Technologies	Domain: shj@ultra.com
101 Dagget Drive		Internet: ultra!shj@ames.arc.nasa.gov
San Jose, CA  95134		uucp:  ...ames!ultra!shj
(408) 922-0100

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 89 02:24:01 GMT
From:      morgan@Jessica.stanford.edu (RL "Bob" Morgan)
To:        comp.protocols.tcp-ip
Subject:   Re: Naive questions about subnets & domains


>Another way to phrase this question is: was it the intention of the subnet
>scheme that subnets must be geographically close or only topologically "close"
>for routing purposes?  If they must be topologically close, am I better off
>       1) using subnets for remote networks and limiting my connections
>          in the future
>or     2) getting distinct network numbers to leave me flexibility in the
>          future

This problem is a rather deep one, I think, that many institutions
will have to struggle through in the near future.  I have been
somewhat involved with the case of a local university that is in much
the same boat.  The computer science dept is very anxious to get
connected, and wants to lease a T1 line right away to the nearby
connection point of the local NSFNET-sponsored regional network.  The
computer center, however, is much happier to wait for the statewide
university system, which has an existing 56Kbps network, to start
supporting IP, connect to the Internet in one place, and eventually
upgrade the campus to T1.  

The question, to paraphrase the quote above, is the relative
importance of geographical versus institutional "closeness."  The
issues in this case have more to do with the cost of long-distance T1
circuits, funding timelines, and the quality of central support than
the technical details of IP address structure.  The choices that
individual institutions make will determine the structure of the
Internet for years to come, and the nature of the technical problems
(like enormous routing tables) that have to be solved.

The domain name system (one might note) reflects the same split.  Most
domains are now organized by institutional type (.edu, .gov) but the
use of geographical domains (.us, .au) is increasing, it seems.  Maybe
someday we'll be "stanford.ca.us."

 - RL "Bob" Morgan
   Networking Systems
   Stanford

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 89 03:09:02 GMT
From:      dheeraj@nile.cs.umd.edu (Dheeraj Sanghi)
To:        comp.protocols.tcp-ip
Subject:   IP_LSRR Option - how is it implemented?


Hi,
	I want to know what happens when I set the IP_LSRR option.
Let us assume a client-server model. The client just sends some fixed
number of packets to the server. The client wants to route the data
via gateway X, and the server wants to route the acks via gateway Y.
Client calls setsockopt and gives the next hop as X and 2nd hop as
the machine running the server, and everything goes fine. Now, server
doesn't know which machine is going to connect to it, so it can't
set the LSRR option, it would seem. What I am doing is setting the
next hop to be Y, and setting the final hop to be a random number.
Surprisingly, I do get the acks and the data goes through fine.

	Now I tried to look into the TCP/IP code (4.3 BSD) to see
if somewhere it "fixes" the final hop, but I don't seem to find any
such code. Would anyone explain me what's happening? To me it seems,
that the server should just send the ack packet to Y, which can't send
the packet any further (after all it sees an address, it doesn't know
about, I am using 0.0.0.1 as the "random number")

thanks in advance,

-dheeraj

Dheeraj Sanghi			(h):301-345-6024	(o):301-454-1516
Internet: dheeraj@cs.umd.edu	UUCP: uunet!mimsy!tove!dheeraj
	Namaste sada vatsale matrabhume,
	Twaya hindubhume sukham vardhitoham.

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 89 09:55:00 CST
From:      "DAVID BERGUM" <bergum@cim-vax.honeywell.com>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   Re: Two port multi-port.
Several weeks ago there was a description of a two port
multi-port transceiver.  When I saw it I thought, "Oh ya, I saw
that in a catalog."  Well, now I need one and I can't find any
reference to it and I didn't save the tcp-ip reference.  Can some
kind soul refreash my memory? 

------------------------------------------------+
-  | o |  -  Bergum@CIM-VAX.Honeywell.COM       |
- (| | |) -  Dave Bergum [MN26-3190]            |
-----------   2701 4-th Ave. S., Mpls, MN 55408 |
-----------   (612)870-5839                     |
------------------------------------------------+

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 89 13:38:24 GMT
From:      mckee@MITRE.MITRE.ORG (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on implementation details...

>that a "typical" TCP/IP system might correspond roughly as follows:
>
>[deleted] 
>
>	Application			user application
>
>Is there some heresy in this conceptualization?

There is, depending on your religious fervor, a small heresy:
The Application layer does not contain applications such as an editor,
spreadsheet, or matrix inversion; rather, it contains communications
routines, such as file transfer and e-mail, that may be used by 
applications.  For example, on the Ultrix system here, when the system
goes down, the editor vi uses e-mail to tell me how to recover the file 
I was working on.

Regards - Craig

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 89 15:32:21 GMT
From:      dab@opus.cray.com (Dave Borman)
To:        comp.protocols.tcp-ip
Subject:   Re:  IP_LSRR Option - how is it implemented?

> 	I want to know what happens when I set the IP_LSRR option.
> Let us assume a client-server model. The client just sends some fixed
> number of packets to the server. The client wants to route the data
> via gateway X, and the server wants to route the acks via gateway Y.
> Client calls setsockopt and gives the next hop as X and 2nd hop as
> the machine running the server, and everything goes fine. Now, server
> doesn't know which machine is going to connect to it, so it can't
> set the LSRR option, it would seem. What I am doing is setting the
> next hop to be Y, and setting the final hop to be a random number.
> Surprisingly, I do get the acks and the data goes through fine.
> 
> 	Now I tried to look into the TCP/IP code (4.3 BSD) to see
> if somewhere it "fixes" the final hop, but I don't seem to find any
> such code. Would anyone explain me what's happening? To me it seems,
> that the server should just send the ack packet to Y, which can't send
> the packet any further (after all it sees an address, it doesn't know
> about, I am using 0.0.0.1 as the "random number")
> 
> thanks in advance,
> 
> -dheeraj
> 
> Dheeraj Sanghi			(h):301-345-6024	(o):301-454-1516

The stock 4.3BSD code does not handle source route options properly.
What is supposed to happen is that in the IP layer, the source route
option is saved (via save_rte()), and then in tcp_input() it is retreived 
(via ip_srcroute()) for use in all packets being returned.  Thus,
the server code in userland doesn't have to do anything at all to
have the correct thing happen when a source routed SYN packet arrives.

If you set the source route on the socket that you are doing accept()
on, that information is not copied into the new socket that is created
when a new connection is received.  If you do a setsockopt() to set
the LSRR option on the new connection after the accept(), you will
wipe out the dynamically created LSRR option (if it was created),
and you will know the destination address, because it is handed to
you in the accept() call.

There are two problems in the stock 4.3BSD code.  The first is that
the source route is not correctly reversed.  The final destination
address was put at the beginning of the reversed route, not at the end.
However, due to a second bug, the fact that the offset into the route
was not reset, but left pointing to the end of the option, a loose
source route would actually get a reply to it, but the returned packet
would not be source routed.  Strict source routes did not work.

		-Dave Borman, dab@cray.com

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 89 15:55:00 GMT
From:      bergum@CIM-VAX.HONEYWELL.COM ("DAVID BERGUM")
To:        comp.protocols.tcp-ip
Subject:   Re: Two port multi-port.

Several weeks ago there was a description of a two port
multi-port transceiver.  When I saw it I thought, "Oh ya, I saw
that in a catalog."  Well, now I need one and I can't find any
reference to it and I didn't save the tcp-ip reference.  Can some
kind soul refreash my memory? 

------------------------------------------------+
-  | o |  -  Bergum@CIM-VAX.Honeywell.COM       |
- (| | |) -  Dave Bergum [MN26-3190]            |
-----------   2701 4-th Ave. S., Mpls, MN 55408 |
-----------   (612)870-5839                     |
------------------------------------------------+

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 89 18:00:00 GMT
From:      ljm@TWG.COM (Leo J McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   Re: Dave Crocker's Novell and TCP/IP message


>The question of "coordinating" use of TCP/IP with a proprietary protocol,
>such as Novell's Netware, surfaces on one of the lists periodically.  In
>looking for solutions, it is important to be clear about the problem, since
>there are two, VERY different operational styles and they need two, VERY
>different kinds of solutions:

Actually, Dave doesn't go far enough.  There are at least six different
proprietary network to TCP/IP network interoperabilty solutions currently
used today.

1.  The dual stack shared network where each host runs both TCP/IP
    and the proprietary stack.

2.  The network tunneled network where every host runs TCP/IP
    (and hopefully SNMP or CMOT), some using a proprietary software
    interface as the data-link medium.

3.  The front-end interface network where only one workstation on the
    proprietary network is a TCP/IP host and functions as an ARPA
    application server or proxy for the other workstations on the
    proprietary network.

4.  The application gateway network where one host translates mail and
    perhaps file sharing applications between the two networks.

5.  The NetBIOS bridged network where one host bridges NetBIOS
    applications between a proprietary NetBIOS and NetBIOS over TCP/IP.

6.  The NetBIOS over TCP/IP network where the old network's proprietary
    applications and hardware remain but the proprietary protocol
    stack has been replaced with TCP/IP.

These last two use the NetBIOS over TCP/IP specification (RFC 1001-1002)
which Dave helped write and only work on NetBIOS-based proprietary networks.

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

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 89 18:21:31 GMT
From:      dpz@convex.com (David Paul Zimmerman)
To:        comp.protocols.tcp-ip
Subject:   Subdomaining (and a plea for my own sanity?)

dpz@convex.com (David Paul Zimmerman) writes:

>I agree that .convex.oxford.ac.uk is pretty bogus.

Hmph.  Even more bogus is that it in fact seems to actually _be_ part of
Oxford, and not of us.  What threw me was the subdomain in the UUCP map.
Normally, you sort of expect subdomains to be either geographical or
departmental, but not by something like machine type.  Oxford's

oxcnvx  .convex.oxford.ac.uk

line sounded like we were hiding our UK office under .oxford.ac.uk (as far as
I can tell, our real UK office is the UUCP site "eurodem").  I wonder how many
"strange, but true" instances of subdomaining are out there.

						David

David Paul Zimmerman                                             dpz@convex.com
CONVEX Computer Corp                                                 convex!dpz

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 89 18:35:23 GMT
From:      dinolt@wdl1.UUCP (George W Dinolt)
To:        comp.protocols.tcp-ip
Subject:   Request for NETBLT Sources

I am looking for a public domain implementation (source) of NETBLT per RFC 998
running on Berkeley Unix.  Please reply to

dinolt@wdl1.fac.ford.com (INTERNET)

or 

...!sgi!wdl1!dinolt (uunet) 

Thanks.
George Dinolt

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 89 20:14:21 GMT
From:      melpar!toppin@uunet.uu.net  (Doug Toppin)
To:        tcp-ip@NIC.DDN.MIL
Subject:   TCP/IP close connection TIME_WAIT ?
We are using IBM Xenix 2 on the PC/AT with Network Research Corp
implementation of TCP/IP (called Fusion) and have hit a snag.
We often get the error EWOULDBLOCK on a heavily used socket (many
opens and closes).  In the Sept. MIPS magazine David Betz writes:
"after a close, the resources used by that connection are not freed
immediately... Since this time interval is in the tens of seconds,
eventually all the resources are tied up in this TIME_WAIT."
My questions are:
* is the time value a constant?
* is it tunable?
* is the value part of the TCP/IP specification?
* is it possible to detect that you are using the last available resource?
* is it possible to allocate more of these resources?
thanks
Doug Toppin
uunet!melpar!toppin
-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 89 20:57:06 GMT
From:      pvm@ISI.EDU (Paul Mockapetris)
To:        comp.protocols.tcp-ip
Subject:   Re: Naive questions about subnets & domains

Hierarchical names, such as those used in the DNS, X.500, and DNANS are
popular because you can distribute authority for name creation by
assigning a node to an organization, and then let it "grow" nodes
underneath.  Because of this use, the hierarchy must always follow the
delegation of control.

We might also like to have out hierarchies correspond to something else
as well.  For example, some like the organizational structure, others
want to have a top-level be network names, others feel EDU vs COM vs
ORG is right, etc.

Sooner or later, there are problems creating one hierarchy that follows
two different criteria.  The DNS doesn't show this problem much because
the organizational criteria and tree-delegation criteria are virtually
identical.  X.400 ORname allocation schemes are debated so much because
the designers are trying to serve multiple masters.

paul

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 89 22:51:07 GMT
From:      MKL@NIC.DDN.MIL (Mark Lottor)
To:        comp.protocols.tcp-ip
Subject:   New host tables from the NIC

The NIC is now offering two new host tables for your convenience:

NETINFO:HOSTS.TXT-Z
  A Unix (4.3BSD) "compress"ed file of HOSTS.TXT

NETINFO:MIL-HOSTS.TXT
  Just the MILNET hosts of HOSTS.TXT

Both files will have the same generation number as HOSTS.TXT.
The files are available via FTP or the HOSTNAME server on port 101.
When using FTP, be sure to specify "tenex" mode when requesting
the HOSTS.TXT-Z file.  The HOSTNAME server has two additional
commands for retreiving the new files:  ALL-Z and ALL-MIL.
-------

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 89 02:22:15 GMT
From:      bzs@ENCORE.COM (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   At Wit's End


This might not be the exact right forum but then again it might very
well be.

Apparently the country domain for Austria is .at, I recently received
a request to add such an address to the INFO-FUTURES mailing list.

Wanna guess what a lot of mailers do with foo.at? Like, change it to
foo.@ (urgh.)

Call it Internet black humor.

	-Barry Shein

Software Tool & Die, Purveyors to the Trade
1330 Beacon Street, Brookline, MA 02146, (617) 739-0202

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Aug 89 08:43:55 EDT
From:      snorthc@relay.nswc.navy.mil
To:        dvnspc1!gary@burdvax.prc.unisys.com, tcp-ip@NIC.DDN.MIL
Subject:   Re:  Comparing Performance of TCP/IP or OSI on Multivendor Equipment
> From: dvnspc1!gary@burdvax.prc.unisys.com  (Gary Barrett)
> Organization: Unisys Corporation, Devon, PA
> Subject: Comparing Performance of TCP/IP or OSI on Multivendor Equipment

> I would be interested in hearing from anyone on the net who is
> wrestling with the problem of benchmarking TCP/IP and OSI software
> across equipment from various vendors.

Here at the Naval Surface Warfare Center we are facing the same problem!

> The only benchmark tool seemingly available (for TCP/IP) is ttcp.  

I get the impression that tools like nfsstones and the X benchmark sw
available on expo aren't what you are after.  I have two subnets assigned
for testing purposes only.  I have measurement tools (Excelan Lanalyser
and FTP SW Lanwatch) stationed on these subnets.  By isolating the
hardware and software being tested I am getting reproducible results.
The problem with this approach is that it is very manual, because the
collection points are MS-DOS machines.  I am currently exploring using
SNMP agents on routers between the subnets to collect data and using
the SNMP client software from CMU to get the data from the agents for
analysis.  YES, there HAS to be a BETTER way!

I am trying to answer questions like these:

Given two protocols/applications with similar functionality such as:
	- TCP's FTP;
	- OSI's FTAM.
Which is more efficient?  This has to be considered over a wide
range of tests: establishing the connection; xfer small, large files;
various hw/sw vendor implementations; file management capabilities.....

Given a single protocol or application which vendors implementation
is "best":
	- meet standards such as RFC?
	- interoperate with other major vendors implementations?
(of course the first case should ensure the second :-) )
	- handle exception conditions.  This last can probably never
be tested properly with a pure standard benchmark.  There are zillions
of things worth testing; sticking to file xfer, try ftping a fairly
large file from a noisy subnet that has a Bridge/3com GS/3 as a router.
Many FTPs will break here because large efficient packets often won't
get through.  FTP SW's FTP has an option that allows you to change
the window size.  (anyone know how to do this with SUNOS or Ultrix?)

Given identical protocol/application/implementation what is the
effect of changing the network adapter or the router?

What are the protocols/applications required to support a:
	- OA user;
	- "business (lots of database access) user;
	- scientific user?
 
I am making some slow progress in collecting this data, the really
hard task is to build a model from the empirical base.  If anyone
has a good recommendation for a good simulation for a 
non-deterministic network (UNIX minis on ethernet with PC/MAC/workstation
clients) I am quite interested.

Any suggestions, comments are solicited.  Flames are OK, I used to be
a potter and own asbestos, fiberfrax, and kevlon protective gear.

	thank you for your support

	stephen northcutt (snorthc@relay.nswc.navy.mil)

My management is too busy trying to give my office to someone else
to worry about what I say.
-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 89 06:33:47 GMT
From:      efb@suned1.UUCP (Everett F. Batey II)
To:        comp.protocols.tcp-ip
Subject:   VMS 5.x TCP ?

Haven't read TCP in a while .. is there any VMS 5.x support, formal,
from TWG or CMU TCP ?

Thank you ..

-- 
           The_Main_User (So Calif SunLUG | Vta-SB-SLO-DECUS)
      efb@elroy.JPL.Nasa.Gov efb@suned1.UUCP efbatey@Vaxb.Navy.MIL
      Statements, Opinions ... MINE ... NOT those of my US Employer  

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 89 10:48:00 EDT
From:      "VAXB::DBURKE" <dburke%vaxb.decnet@nusc-npt.navy.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   Slip for the Macintosh
Date sent:  23-AUG-1989 10:47:53 

Hi,
	We currently have a DECNET/TCP network gated to a PC Proteon network.  
The gateway provides for direct SLIP support. Is there a SLIP package available 
for the Macintosh?  We only have one Mac, and the occasional up/down load 
doesn't justify the expense of an ethernet connection.

Or I have some DEC stuff if some one is willing to trade :-)

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)      ||         //       ||_____||
================================================================================

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 89 09:10:21 GMT
From:      epsilon@wet.UUCP (Eric P. Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: Naive questions about subnets & domains

In article <4699@portia.Stanford.EDU> morgan@Jessica.UUCP (RL "Bob" Morgan) writes:
>                                                   I have been
>somewhat involved with the case of a local university that is in much
>the same boat.  The computer science dept is very anxious to get
>connected, and wants to lease a T1 line right away to the nearby
>connection point of the local NSFNET-sponsored regional network.  The
>computer center, however, is much happier to wait for the statewide
>university system, which has an existing 56Kbps network, to start
>supporting IP, connect to the Internet in one place, and eventually
>upgrade the campus to T1.

Mr. Morgan somewhat misrepresents the facts.  The local
university campus in question has its own IP network, does not
subnet, and is for the most part in one place geographically.
It has its own secondary domain and no current plans to
subdivide it.  As such, I don't see what relevance this case has
to do with the current thread of discussion.

The statewide data network will never offer the performance or
reliability of a BARRNET connection.  The "connection in one
place" would be hundreds of miles away "in the wrong direction,"
through many gateways under different administrative control.
Furthermore, the majority of IP traffic is expected to be
exchanged with current BARRNET members.  The "computer center"
people have no experience with IP networking, having been
sidetracked into 3Com/Bridge XNS by an ex-employee.

The major problem comes from BARRNET's insistence that potential
members purchase Proteon hardware, while the University uses
Cisco equipment almost exclusively.  Nearly all serious
connectivity failures have been traced to existing Proteon
equipment.  The Cisco equipment has proven itself admirably.  If
the University has two active connections to the Internet, the
gateways must enforce policy-based routing.  Cisco, itself an
associate BARRNET member, has experience with this.  I've noticed
that, even with two competent vendors, you end up with a lot of
finger pointing when things don't work.

					-=EPS=-

// Opinions are mine, and do not necessarily reflect those of my
// employer.  I have no relation to either Proteon or Cisco.

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 89 12:43:55 GMT
From:      snorthc@RELAY.NSWC.NAVY.MIL
To:        comp.protocols.tcp-ip
Subject:   Re:  Comparing Performance of TCP/IP or OSI on Multivendor Equipment

> From: dvnspc1!gary@burdvax.prc.unisys.com  (Gary Barrett)
> Organization: Unisys Corporation, Devon, PA
> Subject: Comparing Performance of TCP/IP or OSI on Multivendor Equipment
 
> I would be interested in hearing from anyone on the net who is
> wrestling with the problem of benchmarking TCP/IP and OSI software
> across equipment from various vendors.

Here at the Naval Surface Warfare Center we are facing the same problem!

> The only benchmark tool seemingly available (for TCP/IP) is ttcp.  

I get the impression that tools like nfsstones and the X benchmark sw
available on expo aren't what you are after.  I have two subnets assigned
for testing purposes only.  I have measurement tools (Excelan Lanalyser
and FTP SW Lanwatch) stationed on these subnets.  By isolating the
hardware and software being tested I am getting reproducible results.
The problem with this approach is that it is very manual, because the
collection points are MS-DOS machines.  I am currently exploring using
SNMP agents on routers between the subnets to collect data and using
the SNMP client software from CMU to get the data from the agents for
analysis.  YES, there HAS to be a BETTER way!

I am trying to answer questions like these:

Given two protocols/applications with similar functionality such as:
	- TCP's FTP;
	- OSI's FTAM.
Which is more efficient?  This has to be considered over a wide
range of tests: establishing the connection; xfer small, large files;
various hw/sw vendor implementations; file management capabilities.....

Given a single protocol or application which vendors implementation
is "best":
	- meet standards such as RFC?
	- interoperate with other major vendors implementations?
(of course the first case should ensure the second :-) )
	- handle exception conditions.  This last can probably never
be tested properly with a pure standard benchmark.  There are zillions
of things worth testing; sticking to file xfer, try ftping a fairly
large file from a noisy subnet that has a Bridge/3com GS/3 as a router.
Many FTPs will break here because large efficient packets often won't
get through.  FTP SW's FTP has an option that allows you to change
the window size.  (anyone know how to do this with SUNOS or Ultrix?)

Given identical protocol/application/implementation what is the
effect of changing the network adapter or the router?

What are the protocols/applications required to support a:
	- OA user;
	- "business (lots of database access) user;
	- scientific user?
 
I am making some slow progress in collecting this data, the really
hard task is to build a model from the empirical base.  If anyone
has a good recommendation for a good simulation for a 
non-deterministic network (UNIX minis on ethernet with PC/MAC/workstation
clients) I am quite interested.

Any suggestions, comments are solicited.  Flames are OK, I used to be
a potter and own asbestos, fiberfrax, and kevlon protective gear.

	thank you for your support

	stephen northcutt (snorthc@relay.nswc.navy.mil)

My management is too busy trying to give my office to someone else
to worry about what I say.

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 89 14:13:26 GMT
From:      geoff@USAFA.AF.MIL (Capt Geoff Mulligan)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip and T1

We have a T1 line installed from the Academy to Kirtland AFB.  It is
connected to our ethernet via an Ungerman Bass ip router.  I don't
know if you need any other info.  Please let me know.

	geoff

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 89 14:48:00 GMT
From:      dburke%vaxb.decnet@NUSC-NPT.NAVY.MIL ("VAXB::DBURKE")
To:        comp.protocols.tcp-ip
Subject:   Slip for the Macintosh

Date sent:  23-AUG-1989 10:47:53 

Hi,
	We currently have a DECNET/TCP network gated to a PC Proteon network.  
The gateway provides for direct SLIP support. Is there a SLIP package available 
for the Macintosh?  We only have one Mac, and the occasional up/down load 
doesn't justify the expense of an ethernet connection.

Or I have some DEC stuff if some one is willing to trade :-)

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)      ||         //       ||_____||
================================================================================

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 89 16:52:04 GMT
From:      pprindev@wellfleet.com (Philip Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re: Novell and TCP/IP

> to get a special version of IPX from Novell of course. And you might have to
> change the drivers on the server too. I think you have to have the type-field/
> length field in the ethernet frames set to 8137, which is assigned to Novell.
> In some versions of Novells drivers the field is interpreted as a length field
> ( that's 802.3 i think ). In this case you can run applications which support

Well, it's sort of 802.3; if there was a valid SAP after the length, then this
would be legitimate.  But it isn't.  Fortunately, Novell ships there boxes with
checksumming turned off (sound familiar?) so that the checksum (the first two
bytes after the frame length) is always 0xffff.  This is not a valid LSAP, and
most hosts will ignore this.

This bogusity got me the first time.  Novell ships a tool called econfig, that
allows you to fix the driver to use Ethernet-II frames (and put 0x8137 in the
length/type field).  How many sites have their PC's using the pseudo-802.3
encapsulation?  Not many I hope, but I would be interested in hearing from you
if you do.

-Philip

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 89 17:15:00 GMT
From:      hwajin@wrs.wrs.com (Hwajin Bae)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP close connection TIME_WAIT ?

In article <227@melpar.UUCP> toppin@melpar.UUCP (Doug Toppin) writes:
>We are using IBM Xenix 2 on the PC/AT with Network Research Corp
>implementation of TCP/IP (called Fusion) and have hit a snag.
>We often get the error EWOULDBLOCK on a heavily used socket (many
>opens and closes).  In the Sept. MIPS magazine David Betz writes:
>"after a close, the resources used by that connection are not freed
>immediately... Since this time interval is in the tens of seconds,
>eventually all the resources are tied up in this TIME_WAIT."
>My questions are:
>* is the time value a constant?
	TCP Protocol Specification (RFC 793) defines 2*MSL (Maximum
	Segment Lifetime) to be the time-out value for the TIME_WAIT state
	to reach the CLOSED state.  
	TCB is not deleted until this time-out happens.
	BSD 4.3-tahoe TCP/IP uses MSL of 30 seconds.

>* is it tunable?
	If you have the source, yes.  If you have an operating system
	that let's you change operating system parameters on the fly, yes.

>* is the value part of the TCP/IP specification?
	In RFC 793,  MSL is defined to be 2 minutes -- the value seems to
	be arbitrary.

>* is it possible to detect that you are using the last available resource?
	If you have netstat program, you can to "netstat -a" to see a
	list of PCB's.  Count the TCP PCB's and subtract the number of the
	TCP PCB's from the maximum number of sockets configured into your
	kernel.

>* is it possible to allocate more of these resources?
	You should be able to tune the kernel by using kernel configuration
	package.  Each Unix system has its own different kernel tuning 
	mechanism.  You will need to read the documentation on your system
	to figure out how to re-build your kernel.  Mostly on system V
	dervied Unix OS's use "conf.c" and "config.h" files that are created
	by "config" program using the database files "master" and "dfile".

One thing that you can try to get around this TIME_WAIT state in TCP
implemenations is to set the SO_LINGER option on your SOCK_STREAM socket
with the linger time out value of 0.  When you close the socket that
has the SO_LINGER option on and the linger time is zero, 4.3 BSD based
TCP/IP will close the connection immediately.  In 4.2 BSD  based TCP
implementations SO_DONGLINGER option can be used.

	#include <socket.h>

	.....

#ifdef BSD_43
	struct linger linger;

	linger.l_onoff = 1;
	linger.l_linger = 0;
	setsockopt (sock, SOL_SOCKET, SO_LINGER, &linger, sizeof (linger));
#else
	int on = 1;

	setsockopt (sock, SOL_SOCKET, SO_DONTLINGER, &on, sizeof (on));
#endif /* BSD_43 */
-- 
Hwajin Bae (hwajin@wrs.com)
Wind River Systems
1351 Ocean Ave.  Emeryville, CA 94608 USA
Tel: 415/428-2623       Fax: 415/428-0540

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 89 19:00:11 GMT
From:      viktor@MATH.PRINCETON.EDU (Viktor Dukhovni)
To:        comp.protocols.tcp-ip
Subject:   SubSubNets ???


	Consider following topology:

			.... The universe
			|
			|
 G0
			|
			|
 ==Net 1===============================   Subnetted Class B net
			|			 with say 6 subnet bits
			|  
 G1
			|
			|
       ===Net 2==============================  Same Class B net with 9
	       |			|	       subnet bits ???
	       G2			G3
	       |			|
	=====Net 3=====		    =====Net 4====  Both have 9 subnet bits.
						    Still same class B net???


	Usually one would assign Class C addresses to
nets 3 & 4, not subsubnet,  and advertise routing information for both.

	Instead it is tempting to hide the interior topology from the rest of
the world,  by having different netmasks on the two interfaces of G1.

	This should cause no problem for G0 which should perceive
the network behind G1 as being flat,  also G2 & G3 are ok since they
can simply "route add default G1".

	All the potential trouble arises on G1,  which no longer has a clear
notion of the correct subnet mask for the class B net in question.

	And yet I think that there is a natural scheme for allowing this
new behaviour.

Rule:
-----
	Given an address X, whose standard network part (Y) matches
the standard network part of a non zero number of interfaces on a host,
consider the network part of that address to be:	

1)  X & IPNETMASK(i),  if  (X & IPNETMASK(i)) == (IPADDR(i) & IPNETMASK(i))
	for some interface i.
    That is, if X is an address of a host on the network connected to
    interface i [ Or we think is so anyway, this network could be further
    subsubnetted,  but what we don't know can't hurt us, right???
    After all we are tryin to play hide redundant information! ]

or
2)  X & Intersection(IPNETMASK(i))  if  none of the interfaces are directly
	  std(i)=Y
    connected to X.

	The motivation behind part 2, is that in a sub-subnet situation
addresses not on one of the "would be Class C" nets,  must be on the 
other side of G1,  and so should use the coarser netmask.

	The host part of the address should then be X & ~(IN_NETOF(X)).
	
	Such schemes are not supported by the current sys/netinet/in.c
code.  Here is a proposed change to  in_netof(),  that would implement part
of this policy.
	
	I would like to solicit comments on the folly/wisdom of
this analysis.  

-- 
	Viktor Dukhovni <viktor@math.princeton.edu>	: ARPA
		<...!uunet!princeton!math!viktor>	: UUCP
		+1-(609)-452-5792		 	: VOICE

------- in.c -------
*** /tmp/da2073	Fri Aug 18 02:26:12 1989
--- sys/netinet/in.c	Fri Aug 18 02:25:58 1989
***************
*** 78,83 ****
--- 78,84 ----
  {
  	register u_long i = ntohl(in.s_addr);
  	register u_long net;
+ 	register u_long mask = ~0L ;
  	register struct in_ifaddr *ia;
  
  	if (IN_CLASSA(i))
***************
*** 90,102 ****
  		return (0);
  
  	/*
! 	 * Check whether network is a subnet;
! 	 * if so, return subnet number.
  	 */
  	for (ia = in_ifaddr; ia; ia = ia->ia_next)
! 		if (net == ia->ia_net)
! 			return (i & ia->ia_subnetmask);
! 	return (net);
  }
  
  /*
--- 91,112 ----
  		return (0);
  
  	/*
! 	 * Check whether network is subnetted;
! 	 * Allow a subnet gateway to SUBSUBNET!
! 	 * This means that the subnet mask is
! 	 * The smallest is no interface matches,
! 	 * or the subnet mask for a particular interface 
! 	 * if that interface matches.
! 	 *  Note that this code reduces to the usual case
! 	 *  if all the netmasks are the same.
  	 */
  	for (ia = in_ifaddr; ia; ia = ia->ia_next)
! 		if ( net == ia->ia_net ) {
! 			if ( (i & ia->ia_subnetmask) == ia->ia_subnet )
! 				return(ia->ia_subnet) ;
! 			mask &= ia->ia_subnetmask ;
! 		}
! 	return (~mask ? mask&i : net);
  }
  
  /*

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 89 20:54:25 GMT
From:      haase@DSPO.GOV (Peter Haase)
To:        comp.protocols.tcp-ip
Subject:   Kinnetics Host Access

We currently are using Host Access on our MAC's. There is a problem
with using NRC Fusion on a VAX. I can use FTP to get files from the
VAX to the MAC but when I try to transfer them back to the VAX it
seems to get hung (The MAC) and you have to abort. When I look in 
the directory on the VAX it shows the file but it is empty. I have
tried the same test with another VAX running Berkley UNIX and also
on a SUN and everything works fine. Has anyone else experienced similar
problems using Host Access and NRC Fusion. If so has anyone found a fix
for the problem?

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 89 21:29:57 GMT
From:      perand@tds.kth.se (Per Andersson)
To:        comp.protocols.tcp-ip
Subject:   Re: Novell and TCP/IP

Hi,

At the site I have been connected to all servers have been converted to use the
8137 type field. They were apperently delievered using the bogus 802.3 header.
As I am a user and not an administrator of the novell system I have no deeper 
knowledge why this was so.

Per

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 89 21:58:31 GMT
From:      hubcap!ncrcae!secola!gli@gatech.edu  (George Li)
To:        tcp-ip@NIC.DDN.MIL
Subject:   pc tcp/ip in microsoft windows 386

	I have a PC TCP/IP application written in a Microsoft 386
windows environment.  So far, I haven't had too much luck getting this
program to communicate reliably with a NCR Tower based server. Has
anyone out there in netland had any luck writing PC TCP/IP applications
in a windows environment?  If so, were you able to multitask with
another windows application and what pc package did you use?

	I am using the FTP software native mode library; the socket
library definitely doesn't work (according to ftp support folks). 

Thanks!
-- 
George Li 	gli@Columbia.NCR.COM
		...gatech!ncrats!ncrcae!ncrsec!SCRM2!george
-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 89 06:13:51 GMT
From:      ggm@bunyip.cc.uq.OZ (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Naive questions about subnets & domains

From article <8908222057.AA06211@venera.isi.edu>, by pvm@ISI.EDU (Paul Mockapetris):
> 
> Sooner or later, there are problems creating one hierarchy that follows
> two different criteria.  The DNS doesn't show this problem much because
> the organizational criteria and tree-delegation criteria are virtually
> identical.  X.400 ORname allocation schemes are debated so much because
> the designers are trying to serve multiple masters.

Also, where the DNS (or any other naming scheme) is open to interpretation in 
multiple ways, it is possible for there to be problems within that naming
community. 

Also Also, where two or more initially disjoint (inter)nets join together,
naming conflict is to be expected. 

Actually, you can probably collapse them two also's into one. 

Question: 
	if the DNS authors had a second stab, would they 
	"put an "e" on the end of creat()" so to speak and make 
	the edu/org/gov domains lie within the CCITT preferred 
	naming model? 

	Would they be under "pressure" to do so?

	-George
ACSnet: ggm@brolga.cc.uq.oz                    Phone: +61 7 377 4079
Postal: George Michaelson, Prentice Computer Centre
          Queensland University, St Lucia, QLD 4067 

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 89 13:54:52 GMT
From:      story@can503.UUCP (Robert Story)
To:        comp.protocols.tcp-ip
Subject:   Reliability of TCP/IP


We are thinking of implementing TCP/IP and one my co-workers says that he
has heard that TCP/IP is not reliable for file transfers.  Comments?
Thanks!
-- 
[ Robert Story    ..{!utzoo!censor,!uunet!zardoz!avcoint}!avcocan!story     ]
[ SnailMail : AFS 201 Queens Avenue London Ontario Canada N6A 1J1           ]
[        or : AFS 3349 Michelson Drive Irvine California USA 92715-1606     ]
[ Voice     : +1 519 672-4220 xtn 233                                       ]

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 89 18:51:07 GMT
From:      naftoli@aecom.yu.edu (Robert N. Berlinger)
To:        comp.protocols.tcp-ip
Subject:   BOOTP RFC

Can someone please mail me a copy of RFC951 (BOOTP)?
Thank you!
-- 
Robert N. Berlinger		    |Domain: naftoli@aecom.yu.edu        
Supervisor of Systems Support	    |UUCP: {uunet}!aecom!naftoli
Scientific Computing Center	    |CompuServe: 73047,741 GEnie: R.Berlinger
Albert Einstein College of Medicine |Pan: berlinger  AppleLink: U0995

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 89 01:09:02 GMT
From:      don@edison.UUCP (Don Kossman)
To:        comp.databases,comp.protocols.tcp-ip
Subject:   PC-Oracle

perhaps someone has gone through this already:

we are considering adding some ibm pc's (AT clones and PS/2-80's)
to our tcp/ip network, which consists of several microvax-II's
and vaxstations running ultrix 3.0 and oracle 5.1.22.  we have
the oracle tcp/ip sqlnet stuff, and it all works just fine between
the various vaxen.  we're using thin-net ethernet and dec's
standard ethernet h/w and s/w.

we have "pc/nfs for dos" on order from sun, who gave us a list of
ethernet cards which are supported.  this list includes:

- 3com 3c501, 3c503, 3c505, 3c523 (mc)
- ungerman-bass NIC
- micom/interlan ni5010
- western digital wd8003e

we are considering ordering "runtime" oracle for the pc's (so that
we can run developed forms and sqlplus on the pc's) and have
gotten the following list of supported ethernet cards from
oracle.  this list includes:

- excelan 205T (AT bus)
- excelan 215T (microchannel)

so the obvious questions are:

a) are any of the cards in sun's list functionally identical to
any of the cards in oracle's list?
b) will pc/nfs conflict with pc-oracle/sqlconnect/tcp/ip?

if this has recently been discussed (i fade in and out of the news
and we have limited archives) please email to one the addresses below...

tia for any pointers, especially if you are using or tried to set up
a similar network (eg substitute any unix system for the vaxes).

don
-- 
------
don kossman, sei information technology, los angeles
...sun.com!suntzu!seila!don
...uunet!mahendo.jpl.nasa.gov!jplgodo!seila!don

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Aug 89 12:42:40 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   WD8003EBT



I have acquired an interesting Ethernet Card.  The number is WD8003EBT
and it only vaguely resembles my other WD8003E cards.  Anybody know what
the real differences are or if there is likely to be any problem making
it work?
The jumpers are all in different places but seem to follow the same
numbering scheme so I think I can probably configure it if I can findout
what all the other jumpers do.

Just fishing for info.

                                       bill gunshannon
                                    702wfg@scrvmsys.bitnet
-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 89 07:55:17 GMT
From:      miw@bunyip.cc.uq.OZ (Mark Williams)
To:        comp.protocols.tcp-ip,comp.unix.ultrix
Subject:   Proxy ARP on ULTRIX 3.0

Folks,
	I have decided to bite the bullet and set our Unix boxes up to
do Proxy ARP if we want them to, and set all the others to not do proxy
ARP.
	How does one tell if an ULTRIX machine is set up to do proxy
ARPs? 
	Once you know whether or not it is switched on or off, how do
you switch it from on to off, or from off to on?

	In fact, this info would be useful for other machines besides
ULTRIX machines. Can anyone help?

Thank you,

Mark Williams

miw@bunyip.cc.uq.oz (ACSnet)
bunyip.cc.uq.oz.au (Internet)

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 89 13:44:08 GMT
From:      peterV@ecn.uucp (Peter vd Voort)
To:        comp.protocols.tcp-ip,comp.sys.dec
Subject:   High performance Telnet implementation on VMS systems


Who can help me!!

On our site we use many network interface units (NIU's) from Ungermann Bass.
These units are connected on a broadband network and use TCP/IP and Telnet to
communicate with various systems. One of the systems is a VAX 11/785 wich we
want to replace with a VAX 6310. On the Vax 11/785 we use Exelan boards. These
boards implement TCP/IP.

What we like to have is a software implementation that is good enough to 
support approximately  a 100 users. I have used the CMU/TEK implementation
but the server process consumes a lot of CPU.

Who has any experience with this kind of situations.

--
P.J.G. van der Voort.               Please Email : Internet ecn!peterV@nluug.nl
Energy Research Foundation (E.C.N.)                UUCP     ..!hp4nl!ecn!peterV
Petten. The Netherlands.                           Bitnet   ESU0122@HPEENR51

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 89 14:39:29 GMT
From:      prc@erbe.se (Robert Claeson)
To:        comp.protocols.tcp-ip
Subject:   BOOTP and/or RARP wanted


	I'm looking for implementations of BOOTP and/or RARP. Any
	pointers are welcome. Please e-mail me.



-- 
          Robert Claeson      E-mail: rclaeson@erbe.se
	  ERBE DATA AB

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 89 16:17:40 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP and 8232 Token Ring

John,

I'm not sure what happened or what you did that resulted in such grief. After
my last repairs, the machine apparently has been running fine for some time.
Your CONTEL man may not be intimate with RT-11, but there are lots and lots
of ways to avoid massive volume transfers. Nevertheless, I left the machine
in such a way that even that violence would not wipe out crucial data. I
see that you apparently successfully rename bos10.wav and udp.sav. Why did
you do that in the first place?

If you could not reboot rt-11, I suspect the boot record on dl0 may be
corrupted. That is pretty hard to do and can't be done in the fuzzware.
the rt-11 command COPY/BOOT DL0:RT11FB.SYS DL0: should refresh the record
and can be done from a floppy-based system, assuming the *.SYS files are
okay.

You cannot format DSDD floppies using the rt-11 FORMAT utility. There should
be a special format program lurking on your disk or in the DSD (now Qualogy)
service manual that comes with the disk drive. However, the easiest way
to do that is to stop the machine, remove the drive front cover, switch
to FORMAT with the selector switch, insert disk and press the red button.
Reboot rt-11 when done and use the INIT DY0: command to initialize the
directory. It is possible to create floppy backups of the fuzzware itself,
which is found in the *.DSK files now on your hard disk. Use the rt-11
MOUNT command to mount these files as logical volumes and copy files as
needed. The easiest way to create a complete archive is to use the rt-11
command COPY/DEV FUZZ1.DSK/FILE DY0: and so forth.

If in fact your recent problem is a broken rt-11 bootstrap and in fact the
fuzzware had been running okay, please rename the BOS10 and UDP files and
reboot. The old versions cause some grief with companion time servers
elsewhere in the Internet. Otherwise, please tell me more details and I
will do what I can.

By the way, the easiest way to duplicate formatted floppies is using the
rt-11 copy command as above. Use the COPY/DEV DY0: x.DSK/FILE to create
a floppy image on the hard disk (for some unique name x), then use the
COPY/DEV x.DSK/FILE DY0: to copy the image on a fresh disk. Delete the file
x when done, as the temporary file is about a megabyte long.

Dave

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 89 17:42:40 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   WD8003EBT




I have acquired an interesting Ethernet Card.  The number is WD8003EBT
and it only vaguely resembles my other WD8003E cards.  Anybody know what
the real differences are or if there is likely to be any problem making
it work?
The jumpers are all in different places but seem to follow the same
numbering scheme so I think I can probably configure it if I can findout
what all the other jumpers do.

Just fishing for info.

                                       bill gunshannon
                                    702wfg@scrvmsys.bitnet

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 89 19:01:18 GMT
From:      randy@oetl.UUCP (Randy O'Meara)
To:        comp.protocols.tcp-ip
Subject:   will PCroute do this for me?


	Well, I've just exceeded the maximum cable length of my thinwire
	ethernet.  I picked up PCroute2.0 and PCbridge hoping that I would
	be able to simply extend my ethernet.  PCbridge worked a treat, but
	then I started thinking; ``what about future problems like this'',
	and I took a look at PCroute.  It looked like a simple, inexpensive
	answer that would fulfill my needs for some time to come.  It offered
	slip support which I will need real soon.

	Please bear with me as I am new to subnetting.

	I have only a class C IP address of 192.34.233.x, so I decided to
	grab 3 bits of the host address portion for subnetting.  This will
	allow 7 subnets of 29 hosts each.

	I've set up a test network that consists of the following:

	    Net A (192.34.233.[33..62]) encompasses the following hosts:
		ADDR	NODE	COMMENT
		...33	oetl1	HP series 300 (HP-UX 6.2)
		...34	oetl	HP series 200 (HP-UX 5.15)
		...38	snowyA	AT clone w/ PCroute (1st WD interface at 280h)
		...39	grumpy	AT clone running PC-NFS

	    NET G (192.34.233.[225..254]) encompasses the following hosts:
		ADDR	NODE	COMMENT
		...225	snowyG	AT clone w/ PCroute (2nd WD interface at 2a0h)
		...226	sneezy	VAX 11/750 (VMS 5.1) running CMU TCP/IP
	

	Question 1: How do I (or can I) configure PCroute to pass
		    packets to the different subnets transparently?
		    I would like this to look like a single network.
		    I'm not running routed on any of my machines.

	Question 2: Do I have to tell all of the hosts that they are
		    subnetting, or will PCroute deal with all of that?

	Question 3: Presuming that there is an answer to Question 1,
		    What should I expect when I `ping' snowyA from oetl1?
		    What should I expect when I `ping' snowyG from oetl1?

	Email or post as you see fit.  Thanks.

-- 
Randy O'Meara		randy@oetl.Scf.Lockheed.Com
(408) 425-6249		...{pyramid,leadsv,lstc}!oetl!randy

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 89 03:25:07 GMT
From:      VANCE@TGV.COM (L. Stuart Vance)
To:        comp.protocols.tcp-ip
Subject:   TTCP

Does anyone have a relatively virginal copy of ttcp that I could have?
The one I have has been hacked upon a bit, and I don't have a good feel
for what might have been altered.

Many thanks,
L. Stuart Vance
TGV, Incorporated
vance@tgv.com
(408) 353-3939
-------

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 89 16:25:40 GMT
From:      brian@natinst.com (Brian H. Powell)
To:        comp.sys.mac.programmer,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   sockets with MacTCP


     I've got MacTCP, and was disappointed to find out how incomplete it is
compared to CITI-MacIP.  It's basically just got the lower-level calls.
     Has anybody implemented a Berkeley socket interface for MacTCP?  Would it
be hard to change the CITI socket code to use MacTCP?
     Please respond by mail.  Thanks in advance.

Brian H. Powell					National Instruments Corp.
	brian@natinst.com			12109 Technology Blvd.
	uunet!cs.utexas.edu!natinst!brian	Austin, Texas 78727-6204
	AppleLink:NATINST			(512) 250-9119

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 89 19:13:48 GMT
From:      karl@asylum.SF.CA.US (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: Reliability of TCP/IP

In article <294@can503.UUCP> story@avcocan (Robert Story) writes:
>
>We are thinking of implementing TCP/IP and one my co-workers says that he
>has heard that TCP/IP is not reliable for file transfers.  Comments?

TCP *is* reliable.  The chances of bad data are extremely small.  (No
prototol can guarantee perfect reliability -- not SNA, not OSI.)

This brings to mind another bit of mis-information:  Seems that down
in Los Angeles some IBM-oriented MIS group was saying, in a knowing
authoritative voice, that Ethernet should not be used to carry
financial information because it has collisions and drops digits.  And
since token rings don't have collisions, they don't lose digits and
are thus much better for moving critical data!

			--karl--

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 89 22:59:44 GMT
From:      loc@tmsoft.UUCP (Leigh Clayton)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   x25 <--> tcp/ip gateways

I am paraphrasing a colleague's question:

"The questions I have for the net are about internet gateways. We're
interested in connecting ethernets thru ipsanet x25 pipelines.  We would like
to get a couple of IP ethernet-x25 gateways and need the names of suppliers
and information on the cost and performance of these products."

-------------------------------------------------------------------
- My employers have even less idea what I mean than I do; neither -
- they nor I should be held accountable for statements made here. -
-------------------------------------------------------------------
  Leigh Clayton,                        loc@tmsoft.UUCP

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 89 04:23:19 GMT
From:      karn@ka9q.bellcore.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Reliability of TCP/IP

In article <3582@asylum.SF.CA.US> karl@asylum.UUCP (Karl Auerbach) writes:

>This brings to mind another bit of mis-information:  Seems that down
>in Los Angeles some IBM-oriented MIS group was saying, in a knowing
>authoritative voice, that Ethernet should not be used to carry
>financial information because it has collisions and drops digits.  And
>since token rings don't have collisions, they don't lose digits and
>are thus much better for moving critical data!

Yes, token rings don't have collisions. But some DO occasionally duplicate
packets (examples on request). I'd sure like to see the faces of the MIS
financial types when they learn this little tidbit. Better yet, let me see
if I can get my employer to use a token ring when they transfer my pay into
my checking account. :-)

Phil

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 89 10:26:14 GMT
From:      skl@van-bc.UUCP (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: will PCroute do this for me?

In article <479@oetl1.oetl.UUCP>, randy@oetl.Scf.Lockheed.Com wrote:
>Question 1: How do I (or can I) configure PCroute to pass
>	     packets to the different subnets transparently?
>	     I would like this to look like a single network.
>	     I'm not running routed on any of my machines.

You can do that by enabling Proxy ARP on the Ethernet interface
of each of the PC routers.

>Question 2: Do I have to tell all of the hosts that they are
>	     subnetting, or will PCroute deal with all of that?

Proxy ARP would hide the subnetting details from all the hosts.

>Question 3: Presuming that there is an answer to Question 1,
>	     What should I expect when I `ping' snowyA from oetl1?
>	     What should I expect when I `ping' snowyG from oetl1?

Both ping's would work, and the ping which has to go over the SLIP
line will take a bit longer.

...Sam
-- 
Samuel Lam   <skl@van-bc.wimsey.bc.ca> or {uunet,ubc-cs}!van-bc.wimsey.bc.ca!skl

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Sun, 27 Aug 89 19:47:10 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        karn@ka9q.bellcore.com, mo@prisma.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliability of TCP/IP  and Token rings....
Mike,

Token ring technology does not necessarily permit two hosts to dominate.
The Irvine ring essentially guaranteed a round-robin allocation of
bandwidth, since each station could piggyback its packet on the end of
a chain.

Dave
-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Aug 89 07:17:48 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        deimos.cis.ksu.edu!ksuvax1.cis.ksu.edu!tar@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Re:  Using the 4.2 broadcast addr with 4.3 systems
Tim,

Let me try out a potential Universal Truth, and see if anyone objects:

If you have 4.2-based TCP implementations, then you MUST use
zero-based IP broadcasting, with zeroes in the host portion of the
IP address.

Dave
-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 89 00:27:56 GMT
From:      MURAKAMI@NTT-20.NTT.JP (ken-ichiro murakami)
To:        comp.protocols.tcp-ip
Subject:   Re: Proxy ARP on ULTRIX 3.0

Mark,

As far as I know, there are three ProxyARP implementations on SUN.
Especially, the source code written by Mr.Haavard Eidnes at Norwegian
Institute of Technology would greatly help you. You could contact him
at he@idt.unit.no 

Hope this helps.

-Ken

	Ken-ichiro Murakami
	NTT Software Laboratories
	Tokyo, Japan
-------

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 89 01:58:14 GMT
From:      mo@PRISMA.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Reliability of TCP/IP  and Token rings....

Better than collisions, token rings routinely convoy, causing hosts
A and C to get all the bandwidth between them they want while hosts
B and D starve. 

Nature abhors synchrony - randomizing is good for you!!!

	-Mike

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 89 02:47:10 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: Reliability of TCP/IP  and Token rings....

Mike,

Token ring technology does not necessarily permit two hosts to dominate.
The Irvine ring essentially guaranteed a round-robin allocation of
bandwidth, since each station could piggyback its packet on the end of
a chain.

Dave

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 89 05:21:09 GMT
From:      tar@ksuvax1.cis.ksu.edu (Tim Ramsey)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Using the 4.2 broadcast addr with 4.3 systems

Hello,

I have a LAN (Ethernet) with a mixture of systems on it.  Some of the
systems are running 4.2 based TCP/IP, others are running 4.3 based
TCP/IP.  I can't change the broadcast address (129.130.0.0) on the 4.2
systems.  The broadcast address on the 4.3 systems is 129.130.255.255.

This is really no problem, except that the 4.2 systems don't see
broadcast packets from the 4.3 systems (the 4.3 systems do see the
4.2 broadcast packets).

I'd like to change the 4.3 broadcast address to 129.130.0.0 so everyone
can see everyone.  But is this likely to break anything?

A brief list of my systems:

4.3-like networking:
  Sun 3s (SunOS 4.0)
  VAX 11/780 (More/bsd (4.3BSD + NFS))
  Harris HCX-9 (HX/UX 4.0 (4.3 sorta + NFS))
4.2-like networking:
  ATT 3B2s (SysV 3.0 + WIN/3B 1.1)
  ATT 3B15s (SysV 2.1 + WIN/3B 1.1)

Will changing the broadcast address break things like YP or NFS?

Thanks for any help.  Please email responses and I'll post a summary.

Tim
--
 - VAX it to me at -              Dept. of Computing and Information Sciences
BITNET:   tar@KSUVAX1                       Kansas State University
Internet: tar@ksuvax1.cis.ksu.edu             Manhattan, KS 66506
UUCP:  ...!{rutgers,texbell}!ksuvax1!tar        (913) 532-6350

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 89 07:30:09 GMT
From:      sl@van-bc.UUCP (Stuart Lynne)
To:        comp.protocols.tcp-ip,comp.dcom.modems
Subject:   v32 or PEP for SLIP

I'm looking for a pair of modems for a SLIP link. Should be 9600 or 19200
bps.

Anyone using Trailblazers in V32 mode with any success? Or in PEP mode? Is
Telebit working on anything that will make them the way to go?

Someone local suggested that Concord Data made a very good V32 modem at a
good price. Anyone have any hands on experience with these in a Unix SLIP
envivronment? Does anyone have a phone number for them?

-- 
Stuart.Lynne@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Aug 89 20:29:37 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        mogul@decwrl.dec.com, tcp-ip@nic.ddn.mil
Subject:   Re:  Using the 4.2 broadcast addr with 4.3 systems
The issue of the Host Requirements document's stance on zero- vs.
ones-based IP broadcast (now, is everyone clear that we are talking about
the bits that are in the destination field of the IP header, only, and not
the source, and definitely not any of the bits in the ethernet header?)
that Jeff Mogus raises is a sore point.  The HR committee wrestled with
it.

The bottom line is that if you want to configure for the use of zero-based,
then you can, and still be conformant with the HR doc.  The key point is that
under all circumstances, even when you configure for zero-based, you MUST STILL
be able to recognize ones-based.  (Yess, that means that a zero-based net
must have all of its hosts checking both for zeroes in the host field, as
well as all-ones.)

Dave
-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Aug 89 20:57:59 PDT
From:      cire|eric <cire@cisco.com>
To:        hpl-opus!hpspdra!jpeck@hplabs.hp.com (Joe Peck)
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Does anyone use IP options?
>> Date: 28 Aug 89 17:39:37 GMT
>> From: hpl-opus!hpspdra!jpeck@hplabs.hp.com  (Joe Peck)
>> Subject: Does anyone use IP options?
>> 
>> I have a few question about IP options.
>> 
>> 	How often are they used?  How common is it to see IP frames 
>> 	with options in the header?

It isn't very common.  There was a time when certain options in the packet
would cause certain hosts to crash.

>> 	What programs cause IP options to be used?  I know that there 
>> 	is a version of PING that supports the IP Record Route option.
>> 	What other programs invoke IP options?

It is entirely up to the OS implementation to allow access to that level.
Most do not.  SUNOS does provide the interfaces and there are a number of
administration tools that exist that take advantage (ie. traceroute).

cisco routers provide the functionality for ping via the extended commands.
Various things can be specified including Loose Source Route, Strict
Source Route, Record Route, and Time stamp.

>> 	Do most or all IP implementations support IP options?  I don't
>> 	want to start any finger pointing, I'm just interested in
>> 	whether the majority do or don't provide option support.
>> 

It depends on the implementation.  I haven't heard of a crash blamed on
options in quite a while so I suspect that most implementations coexist
peacefully.

>> 
>> Thanks,
>> 
>> Joe Peck


-c
cire|eric

Eric B. Decker
cisco Systems - engineering
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941
-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 89 14:17:48 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  Using the 4.2 broadcast addr with 4.3 systems

Tim,

Let me try out a potential Universal Truth, and see if anyone objects:

If you have 4.2-based TCP implementations, then you MUST use
zero-based IP broadcasting, with zeroes in the host portion of the
IP address.

Dave

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 1989 2126-PDT (Monday)
From:      Philip Almquist <almquist@jessica.Stanford.EDU>
To:        pacbell!rtech!wrs!hwajin@ames.arc.nasa.gov  (Hwajin Bae)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP close connection TIME_WAIT ?
Hwajin,
	Your message about how to shorten the amount of time a TCP
connection spends in TIME_WAIT state omitted what I think is a rather
crucial point: why shortening that time might be a very bad idea.

	For most users of the TCP protocol, one of its more important
properties is that it delivers data reliably.  Vint Cerf will correct
me if I'm wrong, but my impression is that TIME_WAIT state was not a
devious plot on the part of the protocol designers to tie up system
resources; rather, it was included in the protocol because it is
necessary to insure that delivery is indeed reliable.

						Philip
-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 89 15:49:46 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Reliability of TCP/IP

In article <3582@asylum.SF.CA.US> karl@asylum.UUCP (Karl Auerbach) writes:
> Seems that down in Los Angeles some IBM-oriented MIS group was saying,
> in a knowing authoritative voice, that Ethernet should not be used to carry
> financial information because it has collisions and drops digits.

	I remember reading (handwave: about 2 years ago, in RISKS-DIGEST)
about a hospital which was putting in a network.  They had pretty much
decided on ethernet, when some suit found out about collisions: "You mean
sometimes data is transmitted and network errors cause it to be lost!?  We
can't have any data get lost in a hospital!"  And so they decided that they
couldn't use ethernet.
-- 
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"

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 89 15:50:12 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Mail headers vs. privacy-enhanced email (rfc 1113)

A nit about RFC1113...

The RFC uses X- headers for the new encryption and authentication fields.
This is wrong.  The X- syntax for headers is specifically reserved for
users, since no standard header will ever have that syntax.  The header
lines in RFC1113 are "official", even though they're not in RFC 822 (or,
quite possibly, its successors).


		--Steve Bellovin
		smb@ulysses.att.com

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 89 15:53:38 GMT
From:      kasten@interlan.interlan.COM (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re:  Reliability of TCP/IP


TCP/IP as a suite IS reliable (or at least as reliable as the rest of the
network world:-). Where the confusion may have arisen is that IP, in and
of itself is NOT reliable. In a middle to large sized network, IP datagrams
can and ARE dropped, lost, duplicated, corrupted, misordered, etc, etc.
The TCP layer corrects for this. To quote from the TCP Spec (RFC 793):

	"This document focuses its attention primarily on ....
	computer communication requirements, especially robustness
	in the presence of communication unreliability and availability
	in the presence of congestion"

and
	"Very few assumptions are made as to the reliability of the
	communication protocols below the TCP layer. TCP assumes it can
	obtain a simple, potentially unreliable datagram service from the
	lower level protocols."

and finally, 

	"The TCP must recover from data that is damaged, lost, duplicated,
	or delivered out of order by the internet communication system."

TCP/IP is reliable. 

Cheers
Frank Kastenholz
Racal InterLan

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 89 17:39:37 GMT
From:      jpeck@hpspdra.HP.COM (Joe Peck)
To:        comp.protocols.tcp-ip
Subject:   Does anyone use IP options?


I have a few question about IP options.

	How often are they used?  How common is it to see IP frames 
	with options in the header?

	What programs cause IP options to be used?  I know that there 
	is a version of PING that supports the IP Record Route option.
	What other programs invoke IP options?

	Do most or all IP implementations support IP options?  I don't
	want to start any finger pointing, I'm just interested in
	whether the majority do or don't provide option support.


Thanks,

Joe Peck

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 89 18:45:00 GMT
From:      hs@RELAY.PROTEON.COM
To:        comp.protocols.tcp-ip
Subject:   Randomnicity and the Token Ring


          Hi All: Mike O'D is I'm sure relating back to a wonderful
          LBL paper in which one node was indeed locked out every
          time. This happened even though the ring is egalitarian and
          allowed one packet per customer.

          If the timing of trnsmit and receive are just right, then,
          when one guy gets his packet into the buffer, the second
          node gets its packet refused. By the time the second figures
          out that it should retransmit, the first node gets the
          buffer....But, there was no randomness claused by vagueries
          of OS, head seek times and what have you. Given a small
          amount of randomness this could not persist. Also, our newer
          products (and 802.5 and FDDI) have multiple buffers so it is
          very unlikely in these newer designs.

          But, the point is made that deterministic access does not
          imply deterministic delivery. I can bring the horse to water
          but I can't make it drink. Howard

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 89 21:09:19 GMT
From:      mogul@decwrl.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re:  Using the 4.2 broadcast addr with 4.3 systems

dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) writes:
    Let me try out a potential Universal Truth, and see if anyone objects:
    
    If you have 4.2-based TCP implementations, then you MUST use
    zero-based IP broadcasting, with zeroes in the host portion of the
    IP address.

Ok, I'll bite.  How about:
    If you have 4.2-based TCP implementations, then you MUST
    fix them, or stop trying to support broadcast applications.

Since there isn't much point to broadcasting in 4.2BSD except for
routed (install a default route to a neighboring gateway) and rwhod
(who needs it, anyway?), I wouldn't worry about it.  The latest
draft of the Host Requirements document is a little slippery ...
it says that hosts MUST recognize legally-addressed broacasts
(all-ones style) but then it mentions that a host MAY be allowed to
send all-zeros style broadcasts.  This seems contradictory, but it
probably reflects the most Universal Truth of all: do what you have
to do, if you can't do what's right.

-Jeff

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 89 21:59:59 GMT
From:      rwolski@lll-lcc.UUCP (Richard Wolsoi)
To:        comp.protocols.tcp-ip,comp.unix.wizards,comp.unix.ultrix,comp.unix.questions
Subject:   Nagle algo. in Unix-TCP


Greetings netlanders.
My question regards the Nagle algorithms for small-packet avoidance, which
have been implemented in the various flavors of UNIX now running around.  

A colleague of mine has written an RPC mechanism to run over TCP sockets
on UNIX systems and we are seeing some very strange performance numbers
for certain kinds of messaging.  An ethernet trace and several minutes with
the source code convinced us that TCP was delaying both data sends and
acknowledgements in an effort to avoid silly windows.  

Part of the$problem comes from the RPC implementation which makes two
send system calls for each request or reply (no flames please we are dealing 
with some serious history here) in that UNIX sends out the information in
two different packets.  The first goes out immediately (as the Nagle
algorithm prescribes) while the second is delayed until the first is acked.
Unfortunately, the ack is delayed as part of the receiver's half of the 
bargain and so we were seeing a whopping 10 packets per second.
Now for my question.  Is there any way to defeat the Nagle algorithms under
standard implementations?  I seem to recall that the Tahoe (or is it Tajo) 
release of 4.3 had such a defeat wlich was put in for X-11, but we don't 
have systems which are quite so modern.  Specifically, we are using SunOS
3.4, Ultrix 3.0 and UTS something-or-other with WIN-UTS.  

My boss's boss says that there are some vevsions of RPC which use TCP streams.
If they exist, what are they called?  Do they suffer this problem or do they
rely on the apparent fact that UNIX will attempt to put all of a send
system call in a single packet (which is not part of the spec to my knowledge)?
Thank you all in advance,

Rich
A tourist in Technical Disneyland

rwolski@lll-lcc.llnl.gov			Internet
(415)423-8594					Bell-net
Rich Wolski					Mail-net
President, Mark Boolootian ski-boat foundation (an inside joke)
P.O. Box$808, L-60
Livermore, CA.  94550

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 01:25:59 GMT
From:      db@helium.East.Sun.COM (David Brownell)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun RARP (Dynamic RARP)

In article <8908161254.AA03742@vax.ftp.com> dab@VAX.FTP.COM writes:

> It seems that BOOTP would have made a better base to do dynamic
> address assignment from than RARP.  Why the choice?
>
>						David Bridgham

Well, neither RFC 903 (for RARP) nor RFC 951 (BOOTP) describe dynamic
address assignment.  No other RFC does, either.  This meant either
a new protocol, or an extension to an existing one.  The RARP
implementation we provide remains compliant with RFC 903.

There are two key arguments I can give you as to why we extended RARP,
rather than extending BOOTP or defining yet another protocol.  It's
interesting that historically we proposed a new protocol, and went back
to modifying an existing one for reasons of compatibility:

    (1)	We were already using RARP.  There's a large installed base
	of PROMS complying to RFC 906 (RARP/TFTP) for diskless booting,
	and we needed solutions that wouldn't exclude those systems.

    (2)	RARP is actually a better base than BOOTP.  It's performing
	operations at the link/network level boundary using a protocol
	that runs at those levels.  RARP servers can often access and
	manipulate information that's hidden by an IP-level interface.

(1) is practical, (2) verges on religious.  You also have to ask whether
you're solving the dynamic address assignment problem, or the "how does a
host configure itself" problem; it seems to me that BOOTP handles the
latter better than the former.  The more information you're trying to
pack into that "configure yourself this way" response, the more you
need an extensible monolithic protocol.

Given (1) there wasn't a lot of need to discuss (2) outside of a debate on
what Internet standards should get created to do dynamic address
assignment and (separately) what standards should get created to allow
automatic system installation.  I can't comment authoritatively on those
two standards issues since I'm not engaged in the discussions any more, and
haven't actually gotten an update in a while.

    David Brownell			db@east.sun.com
    Sun Desktop Systems Software	sun!suneast!db
    Billerica, MA

    David Brownell			db@east.sun.com
    Sun Entry Systems Software		sun!suneast!db
    Billerica, MA

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Aug 89 01:29:39 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip,comp.dcom.modems
Subject:   Re: v32 or PEP for SLIP

In article <232@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes:
>I'm looking for a pair of modems for a SLIP link. Should be 9600 or 19200
>bps.
>
>Anyone using Trailblazers in V32 mode with any success? Or in PEP mode? Is
>Telebit working on anything that will make them the way to go?

Telebit is reported to be working on better SLIP support.  In any case,
the Telebit T2500s in V.32 mode worked just fine for the terminal room
at Baltimore Usenix.  (Admittedly they had a bit of help from Van Jacobson's
header-compression code.)  Not wonderful, but what do you expect from SLIP
at 9600 baud...

TB+'s running PEP worked, somewhat less well, at San Diego Usenix.
-- 
V7 /bin/mail source: 554 lines.|     Henry Spencer at U of Toronto Zoology
1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 02:05:23 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.dcom.modems
Subject:   Re: v32 or PEP for SLIP

In article <232@van-bc.UUCP>, sl@van-bc.UUCP (Stuart Lynne) writes:
>... Anyone using Trailblazers in V32 mode with any success? Or in PEP mode?
>...
>Stuart.Lynne@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)

PEP with TCP header compression works for us for interactive traffic, with
the familiar TB+ hiccups.  With PEP we get a little better than 1KByte/sec
for bulk data transfers.  It is hard to get TB2500's out here, .25 miles
from Telebit, so I have not measured SLIP over TB-V32.  However, with
Cypress (very similar to SLIP) over a 9600 FDX private line we get about
0.5KB/sec for bulk data.

(You say bulk data at 1KByte/sec is an oxymoron?  Well, it's all relative.)


Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 03:29:37 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  Using the 4.2 broadcast addr with 4.3 systems

The issue of the Host Requirements document's stance on zero- vs.
ones-based IP broadcast (now, is everyone clear that we are talking about
the bits that are in the destination field of the IP header, only, and not
the source, and definitely not any of the bits in the ethernet header?)
that Jeff Mogus raises is a sore point.  The HR committee wrestled with
it.

The bottom line is that if you want to configure for the use of zero-based,
then you can, and still be conformant with the HR doc.  The key point is that
under all circumstances, even when you configure for zero-based, you MUST STILL
be able to recognize ones-based.  (Yess, that means that a zero-based net
must have all of its hosts checking both for zeroes in the host field, as
well as all-ones.)

Dave

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 03:57:59 GMT
From:      cire@CISCO.COM (cire|eric)
To:        comp.protocols.tcp-ip
Subject:   Re: Does anyone use IP options?

>> Date: 28 Aug 89 17:39:37 GMT
>> From: hpl-opus!hpspdra!jpeck@hplabs.hp.com  (Joe Peck)
>> Subject: Does anyone use IP options?
>> 
>> I have a few question about IP options.
>> 
>> 	How often are they used?  How common is it to see IP frames 
>> 	with options in the header?

It isn't very common.  There was a time when certain options in the packet
would cause certain hosts to crash.

>> 	What programs cause IP options to be used?  I know that there 
>> 	is a version of PING that supports the IP Record Route option.
>> 	What other programs invoke IP options?

It is entirely up to the OS implementation to allow access to that level.
Most do not.  SUNOS does provide the interfaces and there are a number of
administration tools that exist that take advantage (ie. traceroute).

cisco routers provide the functionality for ping via the extended commands.
Various things can be specified including Loose Source Route, Strict
Source Route, Record Route, and Time stamp.

>> 	Do most or all IP implementations support IP options?  I don't
>> 	want to start any finger pointing, I'm just interested in
>> 	whether the majority do or don't provide option support.
>> 

It depends on the implementation.  I haven't heard of a crash blamed on
options in quite a while so I suspect that most implementations coexist
peacefully.

>> 
>> Thanks,
>> 
>> Joe Peck


-c
cire|eric

Eric B. Decker
cisco Systems - engineering
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 04:14:00 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.protocols.tcp-ip
Subject:   Randomnicity and the Token Ring (.5 and .4)

In article <8908282021.AA24495@monk.proteon.com> hs@RELAY.PROTEON.COM writes:
!
!          Hi All: Mike O'D is I'm sure relating back to a wonderful
!          LBL paper in which one node was indeed locked out every
!          time. This happened even though the ring is egalitarian and
!          allowed one packet per customer.
!
!          If the timing of trnsmit and receive are just right, then,
!          when one guy gets his packet into the buffer, the second
!          node gets its packet refused. By the time the second figures
!          out that it should retransmit, the first node gets the
!          buffer....But, there was no randomness claused by vagueries
!          of OS, head seek times and what have you. Given a small
!          amount of randomness this could not persist. Also, our newer
!          products (and 802.5 and FDDI) have multiple buffers so it is
!          very unlikely in these newer designs.
!
!          But, the point is made that deterministic access does not
!          imply deterministic delivery. I can bring the horse to water
!          but I can't make it drink. Howard

	do you think your horse would refuse to drink even if you 
	offered it some of that oh-so-popular 802.4 water?

	although deterministic access does not imply deterministic
	delivery, mightn't some particular state-machine imply same?  
	802.4???  naaaaaaaaaaaaah.  

-- 
 ... Steve Elias (eli@spdcc.com);6178906844;6178591389; {}
/* free email to fax gateway for destinations in metro Boston area. */
/* send email and the destination fax number... */

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 04:26:00 GMT
From:      almquist@JESSICA.STANFORD.EDU (Philip Almquist)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP close connection TIME_WAIT ?

Hwajin,
	Your message about how to shorten the amount of time a TCP
connection spends in TIME_WAIT state omitted what I think is a rather
crucial point: why shortening that time might be a very bad idea.

	For most users of the TCP protocol, one of its more important
properties is that it delivers data reliably.  Vint Cerf will correct
me if I'm wrong, but my impression is that TIME_WAIT state was not a
devious plot on the part of the protocol designers to tie up system
resources; rather, it was included in the protocol because it is
necessary to insure that delivery is indeed reliable.

						Philip

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Aug 89 08:33:07 EDT
From:      snorthc@relay.nswc.navy.mil
To:        tcp-ip@nic.ddn.mil
Subject:   high cost of routing
	The cost of routing?

senario:
	I am collecting data on network protocols and applications.
The experiments are conducted on a test subnet only (128.38.45)
and from the '45' subnet to another (128.38.48).  The '45' cable has
only 4 computers, a sun, a dec 3100, a lanalyser and a lan watch.
The 48 cable is a "living lab" various protocols are allowed to
exist on it: decnet, novell_ipx, apple_localtalk, osi etc.  It is
also pretty quiet, a 2% peak for 1 second is the max traffic observed
to date (I haven't broken out the LAN MDs yet).  The router is
currently a Network Systems Corporation EN-641.  In a few more weeks
it will be replaced by a cisco box and the tests will be rerun.

question:
	There is a repeatable difference in the number of packets
required to conduct an operation on the 45 cable alone or routed
from the 45 cable to the 48 cable for certain applications.
The difference is fairly high for xterm and telnet, it cannot be
detected for ftp.  Below are two fragments of the test results
form.  They are fairly representative, I have been running tests for
three weeks and have collected a fair quantity of data.  
examples:	45 CABLE		45 -> 48 CABLE
	Traffic required to initiate an xterm connection:
		60 packets		71 packets
	Traffic telnet requires to transmit a known string:
		37 packets		45 packets	

YES! arps are stripped out and maintained as a separate stat.
YES! the test has been run to/from similar hw/sw platforms *
NO! fragments have not been observed... in fact in the case of
xterm or telnet you tend to have small packets anyway.

* there is only one dec 3100, so an ultrix vax was used on the 48 cable,
however there is a sun 2 sunos 3.5 on both cables and results are
quite similar.

So I am confused.  What causes this overhead?  Is there an RFC I should
have read on this subject?  Could it be the router?  Any ideas?

		Thank You,

		Stephen Northcutt (snorthc@relay.nswc.navy.mil)
-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Aug 89 13:11:47 EDT
From:      snorthc@relay.nswc.navy.mil
To:        tcp-ip@nic.ddn.mil
Subject:   name that bridge type please
If the ethernet type field is:
0x9001	for	Bridge (3Com) bridge
0x9002	for	Bridge (3Com) terminal
what is
0x9003 		Bridge ???

The ethernet address is one from the Bridge series.  It is always
a 60 byte packet.  What does it do?

		Thank You,

		Stephen Northcutt (snorthc@relay.nswc.navy.mil)

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Aug 89 16:49 MDT
From:      <STGEORGE%UNMB.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   Dbridge and Multinet
Is anyone familiar enough with either of these two products, used to
transport Decnet over tcp/ip, to give an evaluation? Thanks in advance.
-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 12:33:07 GMT
From:      snorthc@RELAY.NSWC.NAVY.MIL
To:        comp.protocols.tcp-ip
Subject:   high cost of routing


	The cost of routing?

senario:
	I am collecting data on network protocols and applications.
The experiments are conducted on a test subnet only (128.38.45)
and from the '45' subnet to another (128.38.48).  The '45' cable has
only 4 computers, a sun, a dec 3100, a lanalyser and a lan watch.
The 48 cable is a "living lab" various protocols are allowed to
exist on it: decnet, novell_ipx, apple_localtalk, osi etc.  It is
also pretty quiet, a 2% peak for 1 second is the max traffic observed
to date (I haven't broken out the LAN MDs yet).  The router is
currently a Network Systems Corporation EN-641.  In a few more weeks
it will be replaced by a cisco box and the tests will be rerun.

question:
	There is a repeatable difference in the number of packets
required to conduct an operation on the 45 cable alone or routed
from the 45 cable to the 48 cable for certain applications.
The difference is fairly high for xterm and telnet, it cannot be
detected for ftp.  Below are two fragments of the test results
form.  They are fairly representative, I have been running tests for
three weeks and have collected a fair quantity of data.  
examples:	45 CABLE		45 -> 48 CABLE
	Traffic required to initiate an xterm connection:
		60 packets		71 packets
	Traffic telnet requires to transmit a known string:
		37 packets		45 packets	

YES! arps are stripped out and maintained as a separate stat.
YES! the test has been run to/from similar hw/sw platforms *
NO! fragments have not been observed... in fact in the case of
xterm or telnet you tend to have small packets anyway.

* there is only one dec 3100, so an ultrix vax was used on the 48 cable,
however there is a sun 2 sunos 3.5 on both cables and results are
quite similar.

So I am confused.  What causes this overhead?  Is there an RFC I should
have read on this subject?  Could it be the router?  Any ideas?

		Thank You,

		Stephen Northcutt (snorthc@relay.nswc.navy.mil)

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 13:42:30 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP close connection TIME_WAIT ?

In article <8908290927.AA26586@ucbvax.Berkeley.EDU>, almquist@JESSICA.STANFORD.EDU (Philip Almquist) writes:
> but my impression is that TIME_WAIT state was not a
> devious plot on the part of the protocol designers to tie up system
> resources; rather, it was included in the protocol because it is
> necessary to insure that delivery is indeed reliable.

Quite true.  The problem is that a host that has already closed its
direction of transmission must retain knowledge of the connection
until the other side has closed successfully.  I don't have a copy
of the RFC handy, so I won't mention the state names, but the
general scenario goes like this....

Recall, first, that each direction of transmission may be closed
independently.  Furthermore, everything must be ACKed, including
specifically close requests (known in the spec as FIN bits).  Suppose
that host A sends a FIN to host B, thereby ending its transmission.
B replies with an ACK, but continues sending data for an arbitrarily
long period.  Eventually, it too sends a FIN to host A; host A replies
with an ACK.

Let us consider now who knows what.  A has long-since finished transmitting;
it cannot send any more data.  Furthermore, it knows that B is done, too;
it's even acknowledged that.  Can A discard all knowledge of the connection?
No!  What if the ACK going to B gets lost?  B's transmitter will time out
and resend the the FIN; after all, B doesn't know which packet was
dropped.  If A has discarded knowledge of the connection, it would
have to send a reset (RST) in response to the repeated FIN.  This is
inappropriate.  Accordingly, A goes to TIMEWAIT state instead, thus
retaining the appropriate; if it sees a repeat FIN, it can simply repeat
the ACK.  TIMEWAIT persists for twice the maximum segment lifetime;
i.e., long enough to be sure that B has either seen the ACK or has
concluded that the connection is hopelessly broken.

Interestingly enough, B does not go into TIMEWAIT; the reasoning is left
as an exercise for the reader.  (N.B.  If both sides send simultaneous
FINs, both sides will end up in TIMEWAIT.)

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 14:11:49 GMT
From:      craig@bbn.com (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Re: high cost of routing

In article <8908291343.AA07813@ucbvax.Berkeley.EDU> snorthc@RELAY.NSWC.NAVY.MIL writes:
>	There is a repeatable difference in the number of packets
>required to conduct an operation on the 45 cable alone or routed
>from the 45 cable to the 48 cable for certain applications.
>The difference is fairly high for xterm and telnet, it cannot be
>detected for ftp.
> ...
>examples:	45 CABLE		45 -> 48 CABLE
>	Traffic required to initiate an xterm connection:
>		60 packets		71 packets
>	Traffic telnet requires to transmit a known string:
>		37 packets		45 packets	
>
>YES! arps are stripped out and maintained as a separate stat.
>YES! the test has been run to/from similar hw/sw platforms *
>NO! fragments have not been observed... in fact in the case of
>xterm or telnet you tend to have small packets anyway.

In general, it would be much easier to diagnose this problem with
a packet trace, but...

    - Have you stripped out duplicate SYNs segments?  Some TCP's retransmit
	SYNs pretty quickly at the start.  As a result, you are likely
	to see a few more SYNs/SYN-ACKs in each direction during connection
	setup.  This is simply the cost of getting the connection calibrated
	to the path.  [Although note you can retransmit SYNs in more or
	less intelligent ways].

    - Similarly, does this problem of extra packets persist during the
	entire connection, or only at startup?  If only at startup you
	may just being seeing effects of the retransmit timer calibrating
	itself to the slightly longer delay.

Speculating in the absence of enough data....

Craig

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 14:38:36 GMT
From:      jas@proteon.com (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   high cost of routing

Two possibilities:

1.  One of the host TCP implementations is hyper-sensitive to small
changes in the round trip time.  There will be an increase in
end-to-end delay passing through the router.  This could affect
various congestion control algorithms in the hosts (like the Nagle
algorithm). 

2.  Someone is dropping a packet.  It could be that the router is not
keeping up, or it could be that the router is sending faster than one
of the hosts can receive.  Many Ethernet interfaces have subtle "deaf
time" problems.

You might want to look at the TCP, IP, and device stats on the two
machines.  Unfortunately, until 4.3tahoe (?), the TCP stats were not
very detailed.

Alternately, you could use a Sniffer (or the like), and interpret the
TCP packets to see what's happening.

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 14:56:27 GMT
From:      lwilson@umabco.UUCP (Lowell G. Wilson)
To:        comp.protocols.tcp-ip
Subject:   BYU TCP/IP


I have been trying unsuccessfully to locate a copy of the BYU TCP/IP
software so that we can take a look at it here and see if it will work
in our environment.  Could someone lend a hand and tell me where I can
find the stuff?  Thanks in advance.
-- 
Lowell Wilson : Sinecure III        University of Maryland at Baltimore    
                                    Information Resources Mgt Division     
                                    UUCP: ...cvl!umabco!lwilson            
                                    Internet: umabco!lwilson@cvl.umd.edu

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 15:06:30 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  Does anyone use IP options?

Joe,

Los Alamos National Laboratory is requiring network source from
workstation vendors in order to incorporate the extended security
option in workstations which communicate with our Central Computing
Facility (CCF).  SunOS 4.x, VAX BSD4.3 and CRAY UNICOS kernels have
been modified so far.  The option must be copied on fragmentation and
is used in all packets which pass through the CCF router(s).
Consequently, we need a mechanism which allows us to set up this
feature during an initial authentication session for a user, as well as
incorporate the option in every IP packet no matter what the IP
based application (Telnet, NeWS, X-Windows, etc.).  Also, server(remote)
initiated applications (such as X or NeWS) require that the
option be incorporated for the duration of a session by the client(local)
applications peer.  Think full duplex.

None of the software we have looked at (maybe with the exception of
FTP, Inc.) allows for other options besides source routing.  Also,
it is more difficult to incorporate in UDP based applications, at least on 4.3BSD based systems.

Phil Wood,  cpw@lanl.gov

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 15:23:43 GMT
From:      jc@odin.ucsd.edu (John Cornelius)
To:        comp.protocols.tcp-ip,comp.dcom.modems
Subject:   Re: v32 or PEP for SLIP

In article <232@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes:
>	.
>Anyone using Trailblazers in V32 mode with any success? Or in PEP mode? Is
>Telebit working on anything that will make them the way to go?

Well, Telebit has done a lot of work with SLIP.  At Uniforum, for instance,
they hooked the show's ethernet to the internet via slip running on a Sun
of some sort.  I'm fairly certain they were using PEP mode.

John Cornelius
aka jc%andataco.uucp@ucsd.edu

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 15:30:30 GMT
From:      matthews@cbnewsm.ATT.COM (john.matthews)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   Net Backup/Restore for Sys5.3?


Does anyone know of a port of dump/restore for SysV.3 that is close
in functionality to the ones released by SUN?  Doing the backups
over the network would be preferable, but if you know of any such
product, please respond.  If you know of other easy-to-use backup
and restore products feel free to send me that info too.

				Thanks,
					John Matthews
					matthews@aloft.att.com

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 15:36:49 GMT
From:      JER@PSUVM.BITNET (Jeff Rich)
To:        comp.protocols.tcp-ip
Subject:   NCSA Telnet 2.2 PC LocalTalk Card

Has anyone successfully got NCSA's Telnet version 2.2 for the PC to work in
conjunction with Apple's LocalTalk Card for the PC.  To LocalTalk network has a
FastPath 4 acting as a gateway, and works beautifully for the Mac's.  I'm not
even sure this will work.  Any information would be appreciated.  Please
respond to me directly.  Thanks.

        // /////// /////// Jeffrey Rich, Microcomputer Systems Consultant
       // //      //   //  Penn State University
      // /////   ///////   12 Willard Building
 //  // //      //  //     University Park, Pa  16802 (814)8634356
 ///// /////// //    //    JER@PSUVM.bitnet U0623:AppleLink

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 15:39:50 GMT
From:      pprindev@wellfleet.com (Philip Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re:  Does anyone use IP options?

> How often are they used?  How common is it to see IP frames 
> with options in the header?

Perhaps some MERIT people can tell us if they have collected
any data using NNSTAT.

> ...
 
> Do most or all IP implementations support IP options?  I don't
> want to start any finger pointing, I'm just interested in
> whether the majority do or don't provide option support.

The implementation of options is mandatory (in RFC-790).  However,
some hosts don't implement it correctly (like 4.2 systems crash
on LSRR options or misinterpret the ordering of the LSRR field)
and several PC implementations don't include options (but then
what do you expect from a PC?).

There was an RFC-to-be circulating about a year (or so) ago
describing the interpretation of LSRR/SSRR.  It never came out,
which is a bit of a shame.  Perhaps Jon can resurrect it?

-Philip

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 15:57:01 GMT
From:      barns@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re:  high cost of routing

It could be many things, and the way to find out for sure is to look
at the packets.  However, here is an example of a possible candidate.
Telnet is an especially difficult protocol to analyze in terms of
theoretical packet behavior.  Neither end is exactly sure when it 
ought to send next, so there are implementation decisions involved.
The decisions found in BSD-flavored code (and many others) tend to
induce a dependency on round-trip time.  If the timing works out
favorably, you will have echoes and acknowledgements and window
updates traveling together.  If it works out less favorably, there
will be extra packets carrying "naked ACKs" and possibly also
window updates.  By going through a router, you increase the RTT by
some amount.  This may increase the chance that the TCP will feel
the need to send an ACK for an incoming segment before the echo or
other output is ready to go back.

Many other things affect packetization, such as Nagle algorithm,
need for retransmission, all the parameters that affect retransmission
(since they indirectly determine what will go in the packets),
context or task switching behavior of the OS, etc.  I've done a few 
limited paper vs. reality studies on what makes packets and find that 
there are so many (nonlinear) factors that even if you know quite a 
lot about the underlying factors, there are likely to be yet more 
factors that you didn't know about.  To summarize, real systems have
a lot of timing-related properties, and the TCP (and perhaps its higher
layer) both contribute to and are affected by them.  These influences 
show up more with irregular flows of small data chunks than with regular 
data flows of big data chunks.

I also feel that the Nagle algorithm is too blunt an instrument to
handle such flows nicely in certain sub-congested regimes, but I
don't think that is what is biting here.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 16:18:35 GMT
From:      nagle@well.UUCP (John Nagle)
To:        comp.protocols.tcp-ip
Subject:   Re: Nagle algo. in Unix-TCP


In article <2581@lll-lcc.UUCP> rwolski@lll-lcc.UUCP (Richard Wolsoi) writes:
>
>My question regards the Nagle algorithms for small-packet avoidance, which
>have been implemented in the various flavors of UNIX now running around.  
>
>A colleague of mine has written an RPC mechanism to run over TCP sockets
>on UNIX systems and we are seeing some very strange performance numbers
>for certain kinds of messaging.  An ethernet trace and several minutes with
>the source code convinced us that TCP was delaying both data sends and
>acknowledgements in an effort to avoid silly windows.  
>
>Part of the$problem comes from the RPC implementation which makes two
>send system calls for each request or reply (no flames please we are dealing 
>with some serious history here) in that UNIX sends out the information in
>two different packets.  The first goes out immediately (as the Nagle
>algorithm prescribes) while the second is delayed until the first is acked.
>Unfortunately, the ack is delayed as part of the receiver's half of the 
>bargain and so we were seeing a whopping 10 packets per second.
>Now for my question.  Is there any way to defeat the Nagle algorithms under
>standard implementations?  I seem to recall that the Tahoe (or is it Tajo) 
>release of 4.3 had such a defeat wlich was put in for X-11, but we don't 
>have systems which are quite so modern.  Specifically, we are using SunOS
>3.4, Ultrix 3.0 and UTS something-or-other with WIN-UTS.  

       What seems to have happened here is that several mechanisms in TCP
are interacting with a strange kind of application to produce poor performance.

       First, "silly window syndrome" is irrelevant here.  Silly window
syndrome occurs when the window is full most of the time, but here,
we have the tinygram problem, which occurs when the window is empty most
of the time.  It's a common misconception that the two problems are the
same.  They are not.  They are handled by separate code in the UNIX
implementation, incidentally.

       The problem here seems to be that tinygram elimination and
delayed ACKs, both performance improvements in TCP, are interacting
with this new RPC application.  Delayed ACKs
are something that first appeared in TOPS-20, which is a system that
runs TELNET in remote echo most of the time.  (So do most UNIX TELNET
implementations, not that they really need to.)  The idea there was
to make the bet that when a packet came in on a TCP connection, the
application would probably have something to reply with shortly.
Therefore, TCP was gimmicked to delay sending an ACK for about 100ms,
in hopes that the application layer would send something back and that
this would be piggybacked on the application layer's reply.  Note that
this is an assumption built into the transport layer about the behavior
of the application layer.  

        Delayed ACKs will cut traffic in half on slow TELNET operations,
and they don't bother FTP.  So they seemed like a big win at the time,
when there were few TCP applications beyond TELNET, FTP, and mail.

        TCP with delayed ACKs and tinygram elimination sending will support 
the following kinds of applications well.

	1) Big data pipes, like FTP.
	2) TELNET-type interaction.
	3) Request-reply type transaction protocols.

But here, we have someone who is trying something that has the property
that it does

	SEND
	SEND
	wait for reply.

This doesn't take turns the way a typical transaction protocol does, so
the guesses built into TCP are bad for this situation.  This, this sort of use
creates problems.  Of course, as the writer points out, doing multiple
tiny sends is a bad thing on general principles.  It's always better to
do one big send than lots of little ones, given that you're not waiting
anxiously for an answer.  Sending a 1-byte message takes 41 bytes across
the net, plus any overhead at the link layer.  It's that 40:1 expansion
that led to the need for tinygram elimination.  Presumably this RPC
package is sending a bit more data at a time, so the expansion factor
may be smaller, but it may still be significant.

One solution might be to make whatever RPC package he's using go through
the standard UNIX I/O library (stdio) and flush the output stream just
before reading from the input stream or before reading from another
source.  This would improve the buffering situation.  This is really a
buffering problem, after all.

TCP is trying to protect the network from dumb applications.  We fixed it
back in 1985 so that when the application is dumb, the application suffers, 
not the network.  We have here a dumb application layer.

					John Nagle
Newsgroups: poster
Subject: Re: Nagle algo. in Unix-TCP
Summary: 
Expires: 
References: <2581@lll-lcc.UUCP>
Sender: 
Reply-To: nagle@well.UUCP (John Nagle)
Followup-To: 
Distribution: 
Keywords: 

In article <2581@lll-lcc.UUCP> rwolski@lll-lcc.UUCP (Richard Wolsoi) writes:
>
>My question regards the Nagle algorithms for small-packet avoidance, which
>have been implemented in the various flavors of UNIX now running around.  
>
>A colleague of mine has written an RPC mechanism to run over TCP sockets
>on UNIX systems and we are seeing some very strange performance numbers
>for certain kinds of messaging.  An ethernet trace and several minutes with
>the source code convinced us that TCP was delaying both data sends and
>acknowledgements in an effort to avoid silly windows.  
>
>Part of the$problem comes from the RPC implementation which makes two
>send system calls for each request or reply (no flames please we are dealing 
>with some serious history here) in that UNIX sends out the information in
>two different packets.  The first goes out immediately (as the Nagle
>algorithm prescribes) while the second is delayed until the first is acked.
>Unfortunately, the ack is delayed as part of the receiver's half of the 
>bargain and so we were seeing a whopping 10 packets per second.
>Now for my question.  Is there any way to defeat the Nagle algorithms under
>standard implementations?  I seem to recall that the Tahoe (or is it Tajo) 
>release of 4.3 had such a defeat wlich was put in for X-11, but we don't 
>have systems which are quite so modern.  Specifically, we are using SunOS
>3.4, Ultrix 3.0 and UTS something-or-other with WIN-UTS.  

       What seems to have happened here is that several mechanisms in TCP
are interacting with a strange kind of application to produce poor performance.

       First, "silly window syndrome" is irrelevant here.  Silly window
syndrome occurs when the window is full most of the time, but here,
we have the tinygram problem, which occurs when the window is empty most
of the time.  It's a common misconception that the two problems are the
same.  They are not.  They are handled by separate code in the UNIX
implementation, incidentally.

       The problem here seems to be that tinygram elimination and
delayed ACKs, both performance improvements in TCP, are interacting
with this new RPC application.  Delayed ACKs
are something that first appeared in TOPS-20, which is a system that
runs TELNET in remote echo most of the time.  (So do most UNIX TELNET
implementations, not that they really need to.)  The idea there was
to make the bet that when a packet came in on a TCP connection, the
application would probably have something to reply with shortly.
Therefore, TCP was gimmicked to delay sending an ACK for about 100ms,
in hopes that the application layer would send something back and that
this would be piggybacked on the application layer's reply.  Note that
this is an assumption built into the transport layer about the behavior
of the application layer.  

        Delayed ACKs will cut traffic in half on slow TELNET operations,
and they don't bother FTP.  So they seemed like a big win at the time,
when there were few TCP applications beyond TELNET, FTP, and mail.

        TCP with delayed ACKs and tinygram elimination sending will support 
the following kinds of applications well.

	1) Big data pipes, like FTP.
	2) TELNET-type interaction.
	3) Request-reply type transaction protocols.

But here, we have someone who is trying something that has the property
that it does

	SEND
	SEND
	wait for reply.

This doesn't take turns the way a typical transaction protocol does, so
the guesses built into TCP are bad for this situation.  This, this sort of use
creates problems.  Of course, as the writer points out, doing multiple
tiny sends is a bad thing on general principles.  It's always better to
do one big send than lots of little ones, given that you're not waiting
anxiously for an answer.  Sending a 1-byte message takes 41 bytes across
the net, plus any overhead at the link layer.  It's that 40:1 expansion
that led to the need for tinygram elimination.  Presumably this RPC
package is sending a bit more data at a time, so the expansion factor
may be smaller, but it may still be significant.

One solution might be to make whatever RPC package he's using go through
the standard UNIX I/O library (stdio) and flush the output stream just
before reading from the input stream or before reading from another
source.  This would improve the buffering situation.  This is really a
buffering problem, after all.

TCP is trying to protect the network from dumb applications.  We fixed it
back in 1985 so that when the application is dumb, the application suffers, 
not the network.  We have here a dumb application layer.

					John Nagle

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 16:24:46 GMT
From:      QWYELX@HUMBER.BITNET (Erone Quek)
To:        comp.protocols.tcp-ip
Subject:   network problem

We have a problem in our local area network and any help will be more
than appreciated.

Background:
- physical installation
  - IEEE 802.3 over twisted pair/fiber optics, star configuration
  - Synoptics Lattisnet Model 1000 premise concentrators
  - fiber optics between concentrators
  - unshield twisted pair (UTP) (4-pair) from concentrator to
    user access RJ45 jack

- protocol & applications
  - tcp/ip only
  - telnet, ftp, smtp, sun-nfs, tn3270

- legend    ===         ---      ***            +++
               ||          |        *              +
               || fiber    | UTP    * AUI cable    + thin wire ethernet

            505s -- Synoptics AUI/UTP Transceiver (Xcvr)

- topology

  --------------------       --------------------
 |Lattisnet mod 1000  |     |Lattisnet mod 1000  |
 |central concentrator|     |local concentator 1 |
 |204 Retiming card   |     |405 UTP host modules|--------------------
 |201-ST Interconnect | ====|203-ST fiber termin.|                    |
  --------------------       --------------------                     |
              ||    ||                                                |
              ||    ||       PC 1, MS-DOS, PC/TCP v2.03, WD8003E-TP --|
              ||    ||                                                |
              ||    ||       SUN 1, SUN 3/280, SUN OS 4.2********505--|
              ||    ||                                                |
              ||    ||       IBM3090, MVS, ACC9315, ACCES/MVS****505--|
              ||    ||                                                |
              ||    ||       Bridge CS/1 term server*************505--|
              ||    ||
              ||    ||       --------------------
              ||    ||      |Lattisnet mod 1000  |
              ||    ||      |local concentator 2 |
              ||    ||      |405 UTP host modules|--------------------
              ||      ======|203-ST fiber termin.|                    |
              ||             ---------------------                    |
              ||                                                      |
              ||             ISI 1, ISI V24/68020, BSD 4.3*******505--|
              ||
              ||             --------------------
              ||            |Lattisnet mod 1000  |
              ||            |local concentator 3 |
              ||            |405 UTP host modules|--------------------
                ============|203-ST fiber termin.|                    |
                             ---------------------                    |
                                                                      |
                             SUN 2, SUN 3/280, SUN OS 4.2********505--|
                                                                      |
                                          ------------------          |
                                         |DEC DEMPR         |****505--|
    +++++++++++++++++++++++++++++++++++++|thin wire repeater|
    +                                     ------------------
    +
    +++++ ---------
         |DEC DESTA|*****ISI 2, ISI V24/68020, BSD 4.3
          ---------

-all cable/fiber lengths are within Synoptic's spec.

Okay, with this topology :

What works: - PC 1 can talk to every one
            - SUN 1 can talk to every one
            - IBM3090 can talk to every one
            - CS/1 can talk to every one EXCEPT ISI 2, can't connect to it
            - ISI 1 can talk to every one (identical hardware as ISI 2)
            - SUN 2 can talk to every one
            - ISI 2 can, with difficulty, talk to every one EXCEPT the CS/1
              - what difficulty ?
                - when I do a netstat -I ex0

Name  Mtu   Network     Address      Ipkts   Ierrs Opkts   Oerrs Collis
ex0   1500  xxx.yy      isi2         424082  0     325703  0     208550

            - although this works, it's not at all desirable. As you can
              see, I can, theoretically, plug the AUI cable from ISI 2
              into a 505 and straight to the Synoptics box, and that's
              what is NOT working. If I took the DEMPR out, as soon as
              I plug the 505 (which has ISI 2 on the other end) onto the
              Synoptics concentrator, I got a constant collision signal
              on the concentrator and the whole network was jammed.
              However, netstat -I ex0 on ISI 2 will NOT show any significant
              collisions !! I swapped 4 ethernet boards off ISI 2,
              same results.

My questions, finally: What's going on ? What did I do wrong ?
                       Incompatibilities at where ?

Erone Quek

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 16:30:05 GMT
From:      sandy@TOVE.UMD.EDU (Sandy Murphy)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP close connection TIME_WAIT ?

Please (please,please) correct me if I am wrong in this.

If Host A is in the TIME_WAIT state, then A has:
	sent a FIN,
	received a FIN,
	received an ACK (of its FIN)
	and sent an ACK (of Host B's FIN).
Therefore, Host B must have:
	sent a FIN,
	received A's FIN,
	and sent an ACK (of A's FIN).
Host B may not have yet received the ACK of its FIN.  So Host B is in state Closing
or LAST_ACK (if it hasn't received the ACK).  Host B has already passed
all of A's data up to the user.  But B doesn't know if A has sent all of B's
data to the user.  The TIME_WAIT state is to ensure that B can get an ACK
so it knows all the data was delivered (see page 22 of the specs).

	Actually, the TIME_WAIT state is not long enough to ENSURE this.  If 
A's ACK of B's FIN gets lost, B will retransmit its FIN (at least).  If this gets lost
as well, it is possible for the 2MSL timer to expire before B retransmits again and
the FIN arrives at A.  Chances are B will receive a RST in that case, because A
is CLOSED when the FIN arrives.

	Note also that both sides of the connection do not necessarily go 
through the TIME_WAIT state.  If Host A closes after it has received a FIN,
then it can send a FIN,ACK.  An ACK of this FIN means that Host B received
the ACK he needs, and A can go directly to CLOSED.

	In this sequence (ESTAB -> CLOSE_WAIT -> LAST_ACK -> CLOSED)
the specs don't say to send an ACK.  I'm just supposing that the FIN segment it
says to send should include an ACK.  Right?

--Sandy Murphy
  University of Maryland

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 16:34:41 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Re: high cost of routing




some people (us included), send smaller packets when sending traffic 
across networks. this is to avoid the routers fragmenting packets.


this is considered a good thing. the over head is more when you are
going through a fast router between fast networks, but you end up
winning more when you consider more networks and more heavily loaded 
routers.


stev knowles
ftp software
stev@ftp.com

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 17:11:47 GMT
From:      snorthc@RELAY.NSWC.NAVY.MIL
To:        comp.protocols.tcp-ip
Subject:   name that bridge type please

If the ethernet type field is:
0x9001	for	Bridge (3Com) bridge
0x9002	for	Bridge (3Com) terminal
what is
0x9003 		Bridge ???

The ethernet address is one from the Bridge series.  It is always
a 60 byte packet.  What does it do?

		Thank You,

		Stephen Northcutt (snorthc@relay.nswc.navy.mil)

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 17:43:50 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Does anyone use IP options?

In article <8908290825.AA23996@ucbvax.Berkeley.EDU>
 cire@CISCO.COM (cire|eric) writes:
>
>It depends on the implementation.  I haven't heard of a crash blamed on
>options in quite a while so I suspect that most implementations coexist
>peacefully.
>
	That's what I thought, too, until someone new to NEARnet went
out a couple of months ago and accidentally crashed an old jvncnet vax
router in our backyard named coventry.mit.edu, using record route or
source route, from one of our cisco routers.  Fortunately for me, I
had hesitated to explore much with these options based on the sage
advice of my colleagues here at BU.  :-)  At any rate, still somewhat
of a surprise, given that coventry was such a strategic resource.

	Fortunately, while coventry still lives, it no longer routes,
so if it continues to crash it has little effect.  Sorry, Dave, don't
know if it is available to run network time protocols.

	BTW, if I can interject a little operational comment in this
list, those of you experiencing severe difficulty in reaching us up
here is the Northeast (NEARnet country) should be finding things much
better these days, after some critical, chronic problems were
dispatched this week.  (I knew I shouldn't have said anything!  All my
snmpxmon displays just went dotted!     :-)  Thanks to those who took
the trouble to sent us reports from faraway.

	--Kent England, Boston U, etc

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 18:10:43 GMT
From:      hegarty@janus.Berkeley.EDU (Christopher Hegarty)
To:        comp.protocols.tcp-ip,comp.dcom.modems
Subject:   Re: v32 or PEP for SLIP


With all this discussion about SLIP, I was wondering if anyone has any
experience with using xterminals (NCD's for example) over a modem using
SLIP.  Can anyone comment on the performance?  I have a couple of
T2500's for evaluation, and they seem to work very reliably in PEP
mode (V.32 mode is another story entirely), but I don't have any
xterminals with prom servers so I can't test SLIP.

I'd appreciate any advice/experience people can offer with regard
to running X over SLIP with modems.

Chris Hegarty (hegarty@janus.uucp)

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 18:54:04 GMT
From:      jwabik@uc.msc.umn.edu (Jeff Wabik)
To:        comp.dcom.modems,comp.protocols.tcp-ip
Subject:   Good modem(s) for SL/IP?


Does anyone know if the Microcomm QX/V.32 modem is a good box to use to
implement a SL/IP connection?  Why/Why not?  If not, are there other
9600bps (or >) modems which are good?   If so, does any of the MNP
compression stuff actually work well in an IP environment?  What sorts
of througput might I expect?

Thanks.. 

	-Jeff

--
Jeff A. Wabik				E/Mail:	 jwabik@msc.umn.edu
Minnesota Supercomputer Center 		AT&T:    +1 612 626 0211
Minneapolis, MN  			FAX:     +1 612 624 6550

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 21:55:51 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re:  Does anyone use IP options?


	The current version of the NSC EN641 router code we have drops (not
ignores, DROPS) packets with IP Record Route.
	Just to point out that even if your hosts do options, you might have
troubles if your gateways (or someone else's) don't. Source route, record
route, security compartment, etc. aren't very useful unless everyone you
want to talk to and everyone in between honor them.
	We need a network death squad... "Youse gateway get outta line an'
we gonna hit ya. Guido, show him what ICMP can do..."
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 89 22:49:00 GMT
From:      STGEORGE@UNMB.BITNET
To:        comp.protocols.tcp-ip
Subject:   Dbridge and Multinet

Is anyone familiar enough with either of these two products, used to
transport Decnet over tcp/ip, to give an evaluation? Thanks in advance.

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Aug 89 06:42:22 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        STGEORGE%UNMB.BITNET@cunyvm.cuny.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  Dbridge and Multinet
DBridge sounds probably refers to one of the options that you can get with
the VMS TCP/IP from The Wollongong Group.  It permits IP to operate over
DECNet, rather than permitting DECNet to operate over IP; my last 
indication was that that their VMS product is not yet shipped with
the latter capability.

Multinet is the name of another VMS TCP/IP, developed at SRI International,
and I believe still distributed by them to some lucky folks, but perhaps
not, since it (also?) is sold by TGV, an SRI "spinoff".  I believe that
they, too, can do DECNet over TCP/IP but are not yet shipping IP or
DECNet.

No doubt the TWG and TGV folks will be quick to correct any errors in the
above.

Dave Crocker
Digital Equipment Corp.
-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 89 02:45:24 GMT
From:      sr16+@andrew.cmu.edu (Seth Benjamin Rothenberg)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for TI 990?


My department is hoping to migrate soon from a TI 990 to a
UNIX machine.  If we don't buy a TI, we will need either

      a. TCP/IP for the TI 990
or
      b. TI (proprietary?) file transfer for UNIX



Has anyone heard of either of these services?


Thanks
Seth Rothenberg
sr16@andrew.cmu.edu

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Aug 89 12:04:57 -0400
From:      Dave Swindell <dswindel@SH.CS.NET>
To:        all-csnet-liaisons: ;, tcp-ip@nic.ddn.mil, nencc@bbn.com, nencc-tech@bbn.com, njm@merit.edu, nsfnet-site-people@merit.edu, info-nets@think.com, tt@SH.CS.NET, ec-full@SH.CS.NET, nearnet-sc@bbn.com
Cc:        cic@SH.CS.NET
As of Monday, August 28, a connection between the NSFNet and CSNET
became operational.  The connection has been made possible through an
arrangement with NEARNet (the New England Academic Research Network)
whereby CSNET traffic passes through NEARNet to JVNCNet and from there
to the NSFNet backbone.  

CSNET, the Computer+Science network, which is based in Cambridge, MA,
provides electronic mail access to over 100 sites using Phonenet, and
IP services to another twenty sites.  CSNET also provides BIND-style
domain name service to over 100 institutions worldwide.  The new
connection gives NSFNet sites much better connectivity to CSNET, to
CSNET's member institutions, and to CSNET services, such as the CSNET
domain name servers, the CSNET Info-Server, and the CSNET User Name
Server (a directory service for finding users).  CSNET plans to obtain
another connection to NSFNet on the West Coast in the near future.

If you have any questions about CSNET, its members, its services, or
its NSFNet connection, please contact:

        Dave Swindell
        CSNET CIC
        10 Moulton Street, 
        Cambridge, MA 02138
        Email: dswindell@sh.cs.net or cic@sh.cs.net
        Telephone: (617) 873-2777

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 89 07:15:36 GMT
From:      wlm@archet.UUCP (William L. Moran Jr.)
To:        comp.protocols.tcp-ip,comp.dcom.modems
Subject:   Re: v32 or PEP for SLIP

In article <232@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes:
>I'm looking for a pair of modems for a SLIP link. Should be 9600 or 19200
>bps.
>
>Anyone using Trailblazers in V32 mode with any success? Or in PEP mode? Is
>Telebit working on anything that will make them the way to go?
>

Yes, I use a pair of t2500s for slip. They are used in v32 mode as
this is much faster for anything interactive (slower for ftp by a good
bit). If what you want is a good reliable v32 modem I would not
hesitate to advise the purchase of t2500s. If you are willing to put
up with a good deal of heartache in exchange for better performance,
get microcom QX/V.32c modems. At 38.4k they work really well with
slip. Unfortunately, my opinion is that they are poorly built, so they
are prone to infant mortality and unreliability.

				Bill
  


-- 
arpa: moran-william@cs.yale.edu or wlm@ibm.com
uucp: uunet!bywater!acheron!archet!wlm or decvax!yale!moran-william
-------------------------------------------------------------------------------
I'm going to find them and I'm going to gnaw on their skulls with my very
own teeth. Because it still hasn't gotten weird enough for me.
			Hunter S. Thompson

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Aug 89 13:29:10 EDT
From:      snorthc@relay.nswc.navy.mil
To:        tcp-ip@nic.ddn.mil
Subject:   unknown Bridge packet 0x9003
I want to thank Tom Dunigan and Bob Enger for their replies on
the Bridge ethernet typefield question (what is 0x9003?).

According to Bridge/3Com tech support these packets are used
for loopback detect.

	cheers,

	stephen (snorthc@relay.nswc.navy.mil)
-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 89 11:37:02 GMT
From:      QWYELX@HUMBER.BITNET (Erone Quek)
To:        comp.protocols.tcp-ip
Subject:   a network problem

We have a problem in our local area network and any help will be more
than appreciated.

Background:
- physical installation
  - IEEE 802.3 over twisted pair/fiber optics, star configuration
  - Synoptics Lattisnet Model 1000 premise concentrators
  - fiber optics between concentrators
  - unshield twisted pair (UTP) (4-pair) from concentrator to
    user access RJ45 jack

- protocol & applications
  - tcp/ip only
  - telnet, ftp, smtp, sun-nfs, tn3270

- legend    ===         ---      ***            +++
               ||          |        *              +
               || fiber    | UTP    * AUI cable    + thin wire ethernet

            505s -- Synoptics AUI/UTP Transceiver (Xcvr)

- topology

  --------------------       --------------------
 |Lattisnet mod 1000  |     |Lattisnet mod 1000  |
 |central concentrator|     |local concentator 1 |
 |204 Retiming card   |     |405 UTP host modules|--------------------
 |201-ST Interconnect | ====|203-ST fiber termin.|                    |
  --------------------       --------------------                     |
              ||    ||                                                |
              ||    ||       PC 1, MS-DOS, PC/TCP v2.03, WD8003E-TP --|
              ||    ||                                                |
              ||    ||       SUN 1, SUN 3/280, SUN OS 4.2********505--|
              ||    ||                                                |
              ||    ||       IBM3090, MVS, ACC9315, ACCES/MVS****505--|
              ||    ||                                                |
              ||    ||       Bridge CS/1 term server*************505--|
              ||    ||
              ||    ||       --------------------
              ||    ||      |Lattisnet mod 1000  |
              ||    ||      |local concentator 2 |
              ||    ||      |405 UTP host modules|--------------------
              ||      ======|203-ST fiber termin.|                    |
              ||             ---------------------                    |
              ||                                                      |
              ||             ISI 1, ISI V24/68020, BSD 4.3*******505--|
              ||
              ||             --------------------
              ||            |Lattisnet mod 1000  |
              ||            |local concentator 3 |
              ||            |405 UTP host modules|--------------------
                ============|203-ST fiber termin.|                    |
                             ---------------------                    |
                                                                      |
                             SUN 2, SUN 3/280, SUN OS 4.2********505--|
                                                                      |
                                          ------------------          |
                                         |DEC DEMPR         |****505--|
    +++++++++++++++++++++++++++++++++++++|thin wire repeater|
    +                                     ------------------
    +
    +++++ ---------
         |DEC DESTA|*****ISI 2, ISI V24/68020, BSD 4.3
          ---------

-all cable/fiber lengths are within Synoptic's spec.

Okay, with this topology :

What works: - PC 1 can talk to every one
            - SUN 1 can talk to every one
            - IBM3090 can talk to every one
            - CS/1 can talk to every one EXCEPT ISI 2, can't connect to it
            - ISI 1 can talk to every one (identical hardware as ISI 2)
            - SUN 2 can talk to every one
            - ISI 2 can, with difficulty, talk to every one EXCEPT the CS/1
              - what difficulty ?
                - when I do a netstat -I ex0

Name  Mtu   Network     Address      Ipkts   Ierrs Opkts   Oerrs Collis
ex0   1500  xxx.yy      isi2         424082  0     325703  0     208550

            - although this works, it's not at all desirable. As you can
              see, I can, theoretically, plug the AUI cable from ISI 2
              into a 505 and straight to the Synoptics box, and that's
              what is NOT working. If I took the DEMPR out, as soon as
              I plug the 505 (which has ISI 2 on the other end) onto the
              Synoptics concentrator, I got a constant collision signal
              on the concentrator and the whole network was jammed.
              However, netstat -I ex0 on ISI 2 will NOT show any significant
              collisions !! I swapped 4 ethernet boards off ISI 2,
              same results.

My questions, finally: What's going on ? What did I do wrong ?
                       Incompatibilities at where ?

Thanx in advance
Erone Quek

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 89 12:14:29 GMT
From:      gary@dvnspc1.Dev.Unisys.COM (Gary Barrett)
To:        comp.protocols.tcp-ip
Subject:   Domain Names

I am posting this for someone else, so if your response is "huh?",
it's probably because I misinterpreted that someone's request:

The question:  "Does anyone know where I could find information in the
public domain about host or domain names  - excluding RFC's?"

I will pass on your replies or postings.  

Thanks.  


Gary Barrett
Unisys 
Devon Engineering Facility
Wayne, PA 

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 89 13:42:22 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  Dbridge and Multinet

DBridge sounds probably refers to one of the options that you can get with
the VMS TCP/IP from The Wollongong Group.  It permits IP to operate over
DECNet, rather than permitting DECNet to operate over IP; my last 
indication was that that their VMS product is not yet shipped with
the latter capability.

Multinet is the name of another VMS TCP/IP, developed at SRI International,
and I believe still distributed by them to some lucky folks, but perhaps
not, since it (also?) is sold by TGV, an SRI "spinoff".  I believe that
they, too, can do DECNet over TCP/IP but are not yet shipping IP or
DECNet.

No doubt the TWG and TGV folks will be quick to correct any errors in the
above.

Dave Crocker
Digital Equipment Corp.

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 89 16:04:57 GMT
From:      dswindel@SH.CS.NET (Dave Swindell)
To:        comp.protocols.tcp-ip
Subject:   (none)

As of Monday, August 28, a connection between the NSFNet and CSNET
became operational.  The connection has been made possible through an
arrangement with NEARNet (the New England Academic Research Network)
whereby CSNET traffic passes through NEARNet to JVNCNet and from there
to the NSFNet backbone.  

CSNET, the Computer+Science network, which is based in Cambridge, MA,
provides electronic mail access to over 100 sites using Phonenet, and
IP services to another twenty sites.  CSNET also provides BIND-style
domain name service to over 100 institutions worldwide.  The new
connection gives NSFNet sites much better connectivity to CSNET, to
CSNET's member institutions, and to CSNET services, such as the CSNET
domain name servers, the CSNET Info-Server, and the CSNET User Name
Server (a directory service for finding users).  CSNET plans to obtain
another connection to NSFNet on the West Coast in the near future.

If you have any questions about CSNET, its members, its services, or
its NSFNet connection, please contact:

        Dave Swindell
        CSNET CIC
        10 Moulton Street, 
        Cambridge, MA 02138
        Email: dswindell@sh.cs.net or cic@sh.cs.net
        Telephone: (617) 873-2777

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 89 16:58:36 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   DDN protocol specs

Are the MILSTD versions of the TCP/IP specs available online anywhere?
I tried a quick look around SRI-NIC.ARPA (aka NIC.DDN.MIL), but didn't
find anything.  (I have the DDN Protocol Handbook; I'm interested in
machine-readable copies.)


		--Steve Bellovin
		smb@ulysses.att.com

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 89 17:25:00 GMT
From:      patterso@hardees.rutgers.edu (Ross Patterson)
To:        comp.protocols.tcp-ip
Subject:   Re:  Reliability of TCP/IP

Frank Kastenholz <kasten@interlan.interlan.COM> writes:
>TCP/IP as a suite IS reliable (or at least as reliable as the rest of the
>network world:-). Where the confusion may have arisen is that IP, in and
>of itself is NOT reliable. 

Reliable has  several  definitions.    Webster offers  "suitable or  fit to be
relied on" and "giving the same result on successive trials".   TCP as defined
in the RFCs meets both, but as  implemented in  many cases,  fails the latter.
In particular,  the  "keepalive  abomination"  causes  connections  that might
otherwise survive  brief  outages or  reconfigurations.   MIS departments (the
original message cited one) generally understand a  third definition, embodied
in the  IBMism  "RAS" (Reliability,  Availability and  Servicability):  "safe,
tested, designed to avoid problems".   Any system  that aborts  a 100MByte FTP
that's already 85% complete because an intervening gateway was rebooted flunks
this.  Proper use of exponential backoff and avoidance of keepalives put the R
back in RAS.  Just ask Phil ("I Hate KeepAlives") Karns, who  has reported FTP
sessions that succeeded after being  interrupted for  *days* in  the ham radio
world, where such things are done right.

Ross Patterson
Rutgers University

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 89 17:29:10 GMT
From:      snorthc@RELAY.NSWC.NAVY.MIL
To:        comp.protocols.tcp-ip
Subject:   unknown Bridge packet 0x9003

I want to thank Tom Dunigan and Bob Enger for their replies on
the Bridge ethernet typefield question (what is 0x9003?).

According to Bridge/3Com tech support these packets are used
for loopback detect.

	cheers,

	stephen (snorthc@relay.nswc.navy.mil)

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 89 18:07:02 GMT
From:      wbc@quimby.dartmouth.edu
To:        comp.protocols.tcp-ip
Subject:   Help Tracing Packet Route


Is there a way to trace the path of an ftp or telnet packet
as it goes from router to router on its way across the country?
Is there any software that does this which works on Suns?
I would like to find which hosts my sessions go through, so
that I can figure out why some are more responsive or reliable
than others.



	Wayne Cripps
	wbc@DARTMOUTH.EDU		wbc@sunapee.dartvax.uucp
	Bradley Hall, Dartmouth College, Hanover N.H. 03755 (603) 646-3198

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 89 19:21:21 GMT
From:      adelman@TGV.COM (Kenneth Adelman)
To:        comp.protocols.tcp-ip
Subject:   Re:  Dbridge and Multinet

> DBridge sounds probably refers to one of the options that you can get with
> the VMS TCP/IP from The Wollongong Group.  It permits IP to operate over
> DECNet, rather than permitting DECNet to operate over IP; my last
> indication was that that their VMS product is not yet shipped with
> the latter capability.

    One comment about DBRIDGE.	It is correctly credited to Van
Jacobson and Craig Leres of the Lawrence Berkeley Laboratory.  You can
FTP sources to it from FTP.EE.LBL.GOV in their anonymous directory.

    DBRIDGE is an excellent example of how a customer can add a
customer-specific transport to either MultiNet or WINS/TCP using the
'rp0' interface.

> Multinet is the name of another VMS TCP/IP, developed at SRI International,
> and I believe still distributed by them to some lucky folks, but perhaps
> not, since it (also?) is sold by TGV, an SRI "spinoff".  I believe that
> they, too, can do DECNet over TCP/IP but are not yet shipping IP or
> DECNet.

    MultiNet is distributed principally by TGV, SRI, and Excelan.
MultiNet implements DECnet over IP, and IP over DECnet in two
different ways:

    1) Using DBRIDGE to allow customers to make connections to
       WINS/TCP sites.	The disadvantage of using DBRIDGE is that
       there is a VMS process which must be brought into context once
       for each packet which comes or goes over the DECnet.

    2) Using the ALTSTART interface into the VMS NETDRIVER.  This
       allows us to pass the IP packets to DECnet without having a VMS
       process in the way.  Although the encapsulation is not
       compatible with DBRIDGE, the performance is much greater and
       the system overhead much less.

						Kenneth Adelman
						TGV, Incorporated

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 89 19:25:14 GMT
From:      medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: Dbridge and Multinet


Speaking as a site which used to run dbridge (a skeleton in my closet), I
can assure you that you don't want to do that unless it's really the only way.
The performance is not very good, and is much worse that DECNET over IP.
The reason is that in current software releases of VMS, you can't
get at the raw datagram layer of DECNET, so you have to set up a TCP
level DECNET connection and throw IP packets down that pipe.  In the other
case (DECNET over IP), the DECNET packets are wrapped up in UDP packets
and sent with very little overhead.  

I believe MultiNet is shipping production versions of both now.  I thought
TWG was as well (my experience with dbridge was years ago using TWG
software)...

						Thanks,
						   Milo

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 89 20:16:28 GMT
From:      ehrlich@cs.psu.edu (Daniel Ehrlich)
To:        comp.protocols.tcp-ip
Subject:   Re: At Wit's End

In article <8908230222.AA12884@multimax.encore.com> bzs@ENCORE.COM (Barry Shein) writes:

   This might not be the exact right forum but then again it might very
   well be.

   Apparently the country domain for Austria is .at, I recently received
   a request to add such an address to the INFO-FUTURES mailing list.

   Wanna guess what a lot of mailers do with foo.at? Like, change it to
   foo.@ (urgh.)

   Call it Internet black humor.

	   -Barry Shein

   Software Tool & Die, Purveyors to the Trade
   1330 Beacon Street, Brookline, MA 02146, (617) 739-0202

Are there not also three letter ISO codes for countries?  I was under
the impression that either the two letter or the three letter code
would work.  Maybe Austria should use the three letter code instead of
`at'.  Just a thought passing through a fogged mind.

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

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 89 20:21:10 GMT
From:      Dave_Katz@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Does anyone use IP options?

> > How often are they used?  How common is it to see IP frames
> > with options in the header?
 
> Perhaps some MERIT people can tell us if they have collected
> any data using NNSTAT.
 
Merit does indeed use NNStat to track interesting things in the NSFnet
backbone, but we do not currently gather statistics regarding the use
of IP options.

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 89 21:17:25 GMT
From:      karn@jupiter (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re:  Using the 4.2 broadcast addr with 4.3 systems


I've said it before, and I'll say it again... the proliferation of IP
broadcast formats, the confusion about which to use, and the broadcast
storms that result from all this, tells me that there is a fundamental
flaw in how broadcasting is presently handled in IP.

I believe that the determination of whether a packet is a broadcast
packet should NOT be made from the IP destination address field, but
rather from the link layer destination field. If a datagram comes
encapsulated in an Ethernet frame with a destination of all 1's, then IP
should treat it as a broadcast packet, regardless of what it says in the
IP destination field.

This requires an "out of band" flag (indicating whether the link level
destination field contained a broadcast or multicast address) to be
passed up along with the packet so that IP's behavior can be
appropriately influenced. For example, ICMP would use this bit to
suppress ICMP error messages. Broadcast forwarding storms can't happen
since a hardware broadcast address on an IP datagram implies an IP
broadcast, and IP would never try to forward such a packet.

If you also pass this flag up to the transport layer, then it's easy for
TCP to ignore people trying to telnet to the broadcast address. Other
protocols, e.g., UDP, would accept broadcast packets.

Phil

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 89 21:35:07 GMT
From:      karn@jupiter (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP close connection TIME_WAIT ?

>[Sandy Murphy's discussion of TCP connection closing]
>	Actually, the TIME_WAIT state is not long enough to ENSURE this.  If 
>A's ACK of B's FIN gets lost, B will retransmit its FIN (at least).  If this gets lost
>as well, it is possible for the 2MSL timer to expire before B retransmits again and
>the FIN arrives at A.  Chances are B will receive a RST in that case, because A
>is CLOSED when the FIN arrives.

You're quite right. In fact, whenever your network has a nonzero packet
loss probability, you can NEVER be absolutely sure that the connection
will close gracefully on both ends. This is not only true with TCP, it's
the case for ANY protocol. Check out the "two-army problem" on page 397
of Tanenbaum's "Computer Networks" text (second edition) for an
explanation.

Phil

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 89 22:07:20 GMT
From:      kima@WSU-ENG.ENG.WAYNE.EDU (Kim N. Anderson)
To:        comp.protocols.tcp-ip
Subject:   mail problems


I am hoping that you may have some insight into this problem...

About a week and a half ago everything was functioning properly with
our mail system; it was sending and receiving mail from the Internet
and BITNET.  One week ago our Multiflow Trace (7/200) OS was upgraded,
and we CEASED being able to receive mail from the Internet although we 
can still receive from another network called Merit whose center is 
located at U of M.

I believe the Merit network and the Internet have different classes.
Also, I know they differ in that Merit addresses always begin with
35.x.x.x.

Our system is a Multiflow Trace (7/200).  It is a 4.3 BSD Unix-based
system.  Our sendmail.cf file was not tampered with in any way.  I
am thinking that some other files, maybe that sendmail uses, were
affected -- I'm not sure what. Also, I know that the problem is not
our mail server because none our other machines were effected.

Please respond with ANY suggestions you may have.  You may send mail
to:

         kima@hub.eng.wayne.edu


Thanking you in advance,

Kim N. Anderson
Wayne State University
Engineering Computer Center

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 89 01:04:28 GMT
From:      pat@grebyn.com (Pat Bahn)
To:        comp.protocols.tcp-ip
Subject:   Interop Attendees only

Does
  any body want to split a hotel room out in San Jose for the Interop?
  I have mostly good social habits.
  Any suggestions on alternate cheap accomadtions appreciated.
pat

-- 
=============================================================================
Pat @ grebyn.com  | If the human mind was simple enough to understand,
301-948-8142      | We'd be too simple to understand it.   
=============================================================================

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 89 01:29:28 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re:  Using the 4.2 broadcast addr with 4.3 systems


	But but but...

	What about directed broadcasts? If you remove the idea of a broadcast
address from IP, you lose this. Maybe you see that as an advantage... :-)
	I'm not really sure what you mean by "making it a flag", though; I
presume you mean in the uppermost interface of IP, but perhaps you mean
something in the packet. (?) The latter wouldn't seem much different than
a broadcast address, since all but the "real" addressee would reject it,
unless it were some special address, anyway.
	I have to admit I can't think of any (honorable, anyway) uses of
directed broadcast, but it's not clear to me that there are none. With
things on the Internet becoming more numerous and harder to find, I expect
directed broadcast and multicast addressing will become more useful in the
coming years...
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 89 03:39:05 GMT
From:      karn@ka9q.bellcore.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re:  Using the 4.2 broadcast addr with 4.3 systems

>	What about directed broadcasts? If you remove the idea of a broadcast
>address from IP, you lose this. Maybe you see that as an advantage... :-)
>	I'm not really sure what you mean by "making it a flag", though; I
>presume you mean in the uppermost interface of IP, but perhaps you mean
>something in the packet. (?) The latter wouldn't seem much different than
>a broadcast address, since all but the "real" addressee would reject it,
>unless it were some special address, anyway.

By "flag", I mean that the subnetwork should pass an indication of whether
the packet was received on a hardware broadcast or multicast address up to
the IP layer along with the packet, e.g., as a second argument in a function
call.

My scheme doesn't really preclude multicasting. My main goal was to find a
reliable way to stop broadcast and ARP storms even when other hosts have
totally broken notions of the IP broadcast address.  As long as the hardware
multicast flag is available to IP, the IP layer can suppress the ICMP
messages and packet forwarding that cause broadcast storms; it can still
look at the IP destination address if it wants to see if the packet should
be accepted locally.

Phil

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 89 05:43:53 GMT
From:      tml@mimir.dmt.oz (Thomas Lam)
To:        comp.protocols.tcp-ip
Subject:   source code of ttcp.c

Could somebody tell me how to obtain a copy of ttcp.c source code?
Thank you!

Reach me by: tml@mimir.dmt.oz ( email )

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31 Aug 89 20:12:08 PDT
From:      crucible@fernwood.mpk.ca.us
To:        Distribution:;
Subject:   THE INTERNET CRUCIBLE - Volume 1, Issue 1
THE CRUCIBLE                                                  INTERNET EDITION
an eleemosynary publication of the                                August, 1989
Anterior Technology IN MODERATION NETWORK(tm)               Volume 1 : Issue 1

			     Geoff Goodfellow
				 Moderator

   In this issue:
	A Critical Analysis of the Internet Management Situation

   THE CRUCIBLE is an irregularly published, refereed periodical on the
   Internet.  The charter of the Anterior Technology IN MODERATION NETWORK 
   is to provide the Internet and Usenet community with useful, instructive
   and entertaining information which satisfies commonly accepted standards
   of good taste and principled discourse.  All contributions and editorial
   comments to THE CRUCIBLE are reviewed and published without attribution.
   Cogent, cohesive, objective, frank, polemic submissions are welcomed.

Mail contributions/editorial comments to:	crucible@fernwood.mpk.ca.us

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

	 A Critical Analysis of the Internet Management Situation:
		       The Internet Lacks Governance


				  ABSTRACT

At its July 1989 meeting, the Internet Activities Board made some
modifications in the management structure for the Internet.  An outline of
the new IAB structure was distributed to the Internet engineering community
by Dr. Robert Braden, Executive Director.  In part, the open letter stated:

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

In this first issue of THE INTERNET CRUCIBLE we will focus on the failures
and shortcomings in the Internet.  Failures contain the lessons one often
needs to achieve success.  Success rarely leads to a search for new
solutions.  Recommendations are made for short and long term improvements 
to the Internet.


			A Brief History of Networking

The Internet grew out of the early pioneering work on the ARPANET.  This
influence was more than technological, the Internet has also been
significantly influenced by the economic basis of the ARPANET.

The network resources of the ARPANET (and now Internet) are "free".  There
are no charges based on usage (unless your Internet connection is via an
X.25 Public Data Network (PDN) in which case you're well endowed, or better
be).  Whether a site's Internet connection transfers 1 packet/day or a 1M
packets/day, the "cost" is the same.  Obviously, someone pays for the
leased lines, router hardware, and the like, but this "someone" is, by and
large, not the same "someone" who is sending the packets.

In the context of the Research ARPANET, the "free use" paradigm was an
appropriate strategy, and it has paid handsome dividends in the form of
developing leading edge packet switching technologies.  Unfortunately,
there is a significant side-effect with both the management and technical
ramifications of the current Internet paradigm: there is no 
accountability, in the formal sense of the word.

In terms of management, it is difficult to determine who exactly is
responsible for a particular component of the Internet.  From a technical
side, responsible engineering and efficiency has been replaced by the
purchase of T1 links.

Without an economic basis, further development of short-term Internet
technology is has been skewed.  The most interesting innovations in
Internet engineering over the last five years have occurred in resource
poor, not resource rich, environments.

Some of the best known examples of innovative Internet efficiency
engineering are John Nagle's tiny-gram avoidance and ICMP source-quench
mechanisms documented in RFC896, Van Jacobsen's slow-start algorithms and
Phil Karn's retransmission timer method.

In the Nagle, Jacobsen and Karn environments, it was not possible or cost
effective to solve the performance and resource problems by simply adding
more bandwidth -- some innovative engineering had to be done.
Interestingly enough, their engineering had a dramatic impact on our
understanding of core Internet technology.

It should be noted that highly efficient networks are important when
dealing with technologies such as radio where there is a finite amount of
bandwidth/spectrum to be had.  As in the Nagle, Jacobsen and Karn cases,
there are many environments where adding another T1 link can not be used
to solve the problem.  Unless innovation continues in Internet
technology, our less than optimal protocols will perform poorly in
bandwidth or resource constrained environments.

Developing at roughly the same time as Internet technology have been the
"cost-sensitive" technologies and services, such as the various X.25-based
PDNs, the UUCP and CSNET dial-up networks.  These technologies are all
based on the notion that bandwidth costs money and the subscriber pays for
the resources used.  This has the notable effect of focusing innovation to
control costs and maximize efficiency of available resources and bandwidth.
Higher efficiency is achieved by concentrating on sending the most amount
of information through the pipe in the most efficient manner thereby making
the best use of available bandwidth/cost ratio.

For example, bandwidth conservation in the UUCP dial-up network has
multiplied by leaps and bounds in the modem market with the innovation of
Paul Baran's (the grandfather of packet switching technology) company,
Telebit, which manufactures a 19.2KB dial-up modem optimized especially for
UUCP and other well known protocol transfers.  For another example,
although strictly line-at-a-time terminal sessions are less "user friendly"
than character-oriented sessions, they make for highly efficient use of
X.25 PDN network resources with echoing and editing performed locally on
the PAD.

While few would argue the superiority of X.25 and dial-up CSNET and UUCP,
these technologies have proved themselves both to spur innovation and to be
accountable.  The subscribers to such services appreciate the cost of the
services they use, and such often costs form a well-known "line item" in
the subscriber's annual budget.

Nevertheless, the Internet suite of protocols are eminently successful,
based solely on the sheer size and rate of growth of both the Internet and
the numerous private internets, both domestically and internationally.  You
can purchase internet technology with a major credit card from a mail order
catalog.  Internet technology has achieved the promise of Open Systems,
probably a decade before OSI will be able to do so.


			   Failures of the Internet

The evolution and growth of Internet technology have provided the basis for
several failures.  We think it is important to examine failures in detail,
so as to learn from them.  History often tends to repeat itself.


Failure 1:- Network Nonmanagement

The question of responsibility in todays proliferated Internet is completely
open.  For the last three years, the Internet has been suffering from
non-management.  While few would argue that a centralized czar is necessary
(or possible) for the Internet, the fact remains there is little to be done
today besides finger-pointing when a problem arises.
 
In the NSFNET, MERIT is incharge of the backbone and each regional network
provider is responsible for its respective area.  However, trying to debug
a networking problem across lines of responsibility, such as intermittent
connectivity, is problematic at best.  Consider three all too true refrains
actually heard from NOC personal at the helm:

	"You can't ftp from x to y?  Try again tomorrow, it will
	 probably work then."

	"If you are not satisfied with the level of [network] 
         service you are receiving you may have it disconnected."

	"The routers for network x are out of table space for routes,
	 which is why hosts on that network can't reach your new
	 (three-month old) network.  We don't know when the routers will
	 be upgraded, but it probably won't be for another year." 

One might argue that the recent restructuring of the IAB may work towards
bringing the Internet under control and Dr. Vinton G. Cerf's recent
involvement is a step in the right direction.  Unfortunately, from a
historical perspective, the new IAB structure is not likely to be
successful in achieving a solution.  Now the IAB has two task forces, the
Internet Research Task Force (IRTF) and the Internet Engineering Task Force
(IETF).  The IRTF, responsible for long-term Internet research, is largely
composed of the various task forces which used to sit at the IAB level.
The IETF, responsible for the solution of short-term Internet problems, has
retained its composition.

The IETF is a voluntary organization and its members participate out of
self interest only.  The IETF has had past difficulties in solving some of
the Internet's problems (i.e., it has taken the IETF well over a year to
not yet produce RFCs for either a Point-To-Point Serial Line IP or Network
Management enhancements).  It is unlikely that the IETF has the resources
to mount a concerted attack against the problems of today's ever expanding
Internet.  As one IETF old-timer put it: "No one's paid to go do these
things, I don't see why they (the IETF management) think they can tell us
what to do" and "No one is paying me, why should I be thinking about the
these things?"
 
Even if the IETF had the technical resources, many of the Internet's
problems are also due to lack of "hands on" management.  The IETF

	o  Bites off more than it can chew;
	o  Sometimes fails to understand a problem before making a solution;
	o  Attempts to solve political/marketing problems with technical
	     solutions;
	o  Has very little actual power.

The IETF has repeatedly demonstrated the lack of focus necessary to
complete engineering tasks in a timely fashion.  Further, the IRTF is
chartered to look at problems on the five-year horizon, so they are out of
the line of responsibility.  Finally, the IAB, per se, is not situated to
resolve these problems as they are inherent to the current structure of
nonaccountability.

During this crisis of non-management, the Internet has evolved into a
patch quilt of interconnected networks that depend on lots of
seat-of-the-pants flying to keep interoperating.  It is not an unusual
occurrence for an entire partition of the Internet to remain disconnected
for a week because the person responsible for a key connection went on
vacation and no one else knew how to fix it.  This situation is but one
example of an endemic problem of the global Internet.


Failure 2:- Network Management

The current fury over network management protocols for TCP/IP is but a
microcosm of the greater Internet vs. OSI debate going on in the
marketplace.  While everyone in the market says they want OSI, anyone
planning on getting any work done today buys Internet technology.  So it
is with network management, the old IAB made the CMOT an Internet
standard despite the lack of a single implementation, while the only
non-proprietary network management protocol in use in the Internet is the
SNMP.  The dual network management standardization blessings will no
doubt have the effect of confusing end-users of Internet
technology--making it appear there are two choices for network
management, although only one choice, the SNMP has been implemented.  The
CMOT choice isn't implemented, doesn't work, or isn't interoperable.

To compound matters, after spending a year trying to achieve consensus on
the successor to the current Internet standard SMI/MIB, the MIB working
group was disbanded without ever producing anything: the political climate
prevented them from resolving the matter.  (Many congratulatory notes were
sent to the chair of the group thanking him for his time.  This is an
interesting new trend for the Internet--congratulating ourselves on our
failures.)

Since a common SMI/MIB could not be advanced, an attempt was made to
de-couple the SNMP and the CMOT (RFC1109).  The likely result of RFC1109
will be that the SNMP camp will continue to refine their experience
towards workable network management systems, whilst the CMOT camp will
continue the never-ending journey of tracking OSI while producing demo
systems for trade shows exhibitions.  Unfortunately the end-user will
remain ever confused because of the IAB's controversial (and technically
questionable) decision to elevate the CMOT prior to implementation.

While the network management problem is probably too large for the SNMP
camp to solve by themselves they seem to be the only people who are
making any forward progress.


Failure 3:- Bandwidth Waste

Both the national and regional backbone providers are fascinated with T1
(and now T3) as the solution towards resource problems.  T1/T3 seems to
have become the Internet panacea of the late 80's.  You never hear anything
from the backbone providers about work being done to get hosts to implement
the latest performance/congestion refinements to IP, TCP, or above.
Instead, you hear about additional T1 links and plans for T3 links.  While
T1 links certainly have more "sex and sizzle" than efficient technology
developments like slow-start, tiny gram avoidance and line mode telnet, the
majority of users on the Internet will probably get much more benefit from
properly behaving hosts running over a stable backbone than the current
situation of misbehaving and semi-behaved hosts over an intermittent catenet.


Failure 4:- Routing

The biggest problem with routing today is that we are still using phase I
(ARPANET) technology, namely EGP.  The EGP is playing the role of routing
glue in providing the coupling between the regional IGP and the backbone
routing information.  It was designed to only accommodate a single point of
attachment to the catenet (which was all DCA could afford with the PSNs).
However with lower line costs, one can build a reasonably inexpensive
network using redundant links.  However the EGP does not provide enough
information nor does the model it is based upon support multiple
connections between autonomous systems.  Work is progressing in the
Interconnectivity WG of the IETF to replace EGP.  They are in the process
of redefining the model to solve some of the current needs.  BGP or the
Border Gateway Protocol (RFC1105) is an attempt to codify some of the ideas
the group is working on.

Other problems with routing are caused by regionals wanting a backdoor
connection to another regional directly.  These connections require some
sort of interface between the two routing systems.  These interfaces are
built by hand to avoid routing loops.  Loops can be caused when information
sent into one regional network is sent back towards the source.  If the
source doesn't recognize the information as its own, packets can flow until
their time to live field expires.

Routing problems are caused by the interior routing protocol or IGP.  This
is the routing protocol which is used by the regionals to pass information
to and from its users.  The users themselves can use a different IGP than
the regional.  Depending on the number of connections a user has to the
regional network, routing loops can be an issue.  Some regionals pass
around information about all known networks in the entire catenet to their
users.  This information deluge is a problem with some IGPs.  Newer IGPs
such as the new OSPF from the IETF and IGRP from cisco attempt to provide
some information hiding by adding hierarchy.  OSPF is the internets first
attempt at using a Dykstra type algorithm as an IGP.  BBN uses it to route
between their packet switch nodes below the 1822 or X.25 layer.

Unstable routing is caused by hardware or hosts software.  Older BSD
software sets the TTL field in the IP header to a small number.  The
Internet today is growing and its diameter has exceed the software's
ability to reach the other side.  This problem is easily fixed by
knowledgeable systems people, but one must be aware of the problem before
they can fix it.

Routing problems are also perceived when in fact a serial line problem or
hardware problem is the real cause.  If a serial line is intermittent or
quickly cycles from the up state into the down state and back again,
routing information will not be supplied in a uniform or smooth manner.
Most current IGPs are Bellman-Ford based and employ some stabilizing
techniques to stem the flow of routing oscillations due to "flapping"
lines.  Often when a route to a network disappears, it may take several
seconds for it to reappear.  This can occur at the source router who waits
for the route to "decay" from the system.  This pause should be short
enough so that active connections persist but long enough that all routers
in the routing system "forget" about routes to that network.  Older host
software with over-active TCP retransmission timers will time out
connections instead of persevering in the face of this problem.  Also
routers, according to RFC1009, must be able to send ICMP unreachables when
a packet is sent to a route which is not present in its routing database.
Some host products on the market close down connections when a single ICMP
reachable is received.  This bug flies in the face of the Internet parable
"be generous in what you accept and rigorous in what you send".

Many of the perceived routing problems are really complex multiple
interactions of differing products.


			    Causes of the Failures

The Internet failures and shortcomings can be traced to several sources:
			
First and foremost, there is little or no incentive for efficiency and/or
economy in the current Internet.  As a direct result, the resources of the
Internet and its components are limited by factors other than economics.
When resources wear thin, congestion and poor performance result.  There is
little to no incentive to make things better, if 1 packet out of 10 gets
through things "sort of work".  It would appear that Internet technology
has found a loophole in the "Tragedy of The Commons" allegory--things get
progressively worse and worse, but eventually something does get through.

The research community is interested in technology and not economics,
efficiency or free-markets.  While this tack has produced the Internet
suite of protocols, the de facto International Standard for Open Systems,
it has also created an atmosphere of intense in-breeding which is overly
sensitive to criticism and quite hardened against outside influence.
Meanwhile, the outside world goes on about developing economically viable
and efficient networking technology without the benefit of direct
participation on the part of the Internet.

The research community also appears to be spending a lot of its time
trying to hang onto the diminishing number of research dollars available
to it (one problem of being a successful researcher is eventually your
sponsors want you to be successful in other things).  Despite this, the
research community actively shuns foreign technology (e.g., OSI), but,
inexplicably has not recently produced much innovation in new Internet
technology.  There is also a dearth of new and nifty innovative
applications on the Internet.  Business as usual on the Internet is mostly
FTP, SMTP and Telnet or Rlogin as it has been for many years.  The most
interesting example of a distributed application on the Internet today is
the Domain Name System, which is essentially an administrative facility,
not an end-user service.

The engineering community must receive equal blame in these matters.
While there have been some successes on the part of the engineering
community, such as those by Nagel, Jacobsen and Karn mentioned above, the
output of the IETF, namely RFCs and corresponding implementations, has
been surprisingly low over its lifetime.

Finally, the Internet has become increasingly dependent on vendors for
providing implementations of Internet technology.  While this is no doubt
beneficial in the long-term, the vendor community, rather than investing
"real" resources when building these products, do little more than
shrink-wrap code written primarily by research assistants at universities.
This has lead to cataclysmic consequences (e.g., the Internet worm
incident, where Sendmail with "debug" command and all was packaged and
delivered to customers without proper consideration).  Of course, when
problems are found and fixed (either by the vendor's customers or software
sources), the time to market with these fixes is commonly a year or longer.
Thus, while vendors are vital to the long-term success of Internet
technology, they certainly don't receive high marks in the short-term.


			       Recommendations

Short-term solutions (should happen by year's end):

In terms of hardware, the vendor community has advanced to the point where
the existing special-purpose technologies (Butterfly, NSSs) can be replaced
by off-the-shelf routers at far less cost and with superior throughput and
reliability.  Obvious candidates for upgrade are both the NSFNET and
ARPANET backbones.  Given the extended unreliability of the mailbridges,
the ARPA core is an immediate candidate (even though the days of net 10 are
numbered).

In terms of software, ALL devices in the Internet must be network
manageable.  This is becoming ever more critical when problems must be
resolved.  Since SNMP is the only open network management protocol
functioning in the Internet, all devices must support SNMP and the Internet
standard SMI and MIB.

Host implementations must be made to support the not-so-recent TCP
enhancements (e.g., those by Nagle, Jacobsen and Karn) and the more
recent linemode TELNET.

The national and regional providers must coordinate to share network
management information and tools so that user problems can be dealt with in
a predictable and timely fashion.  Network management tools are are a big
help, but without the proper personnel support above this, the benefits can
not be fully leveraged.

The Internet needs leadership and hands-on guidance.  No one is seemingly
in charge today, and the people who actually care about the net are pressed
into continually fighting the small, immediate problems.  

Long-term solutions:

To promote network efficiency and a free-market system for the delivery of
Internet services, it is proposed to switch the method by which the network
itself is supported.  Rather than a top-down approach where the money goes
from funding agencies to the national backbone or regional providers, it is
suggested the money go directly to end-users (campuses) who can then select
from among the network service providers which among them best satisfies
their needs and costs.

This is a strict economic model: by playing with the full set of the laws of
economics, a lot of the second-order problems of the Internet, both present
and on the horizon, can be brought to heel.  The Internet is no longer a
research vehicle, it is a vibrant production facility.  It is time to
acknowledge this by using a realistic economic model in the delivery of
Internet services to the community (member base).

When Internet sites can vote with their pocketbooks, some new regionals
will be formed; some, those which are non-performant or uncompetitive, will
go away; and, the existing successful ones will grow.  The existing
regionals will then be able to use their economic power, as any consumer
would, to ensure that the service providers (e.g., the national backbone
providers) offer responsive service at reasonable prices.  "The Market" is
a powerful forcing function: it will be in the best interests of the
national and regional providers to innovate, so as to be more competitive.
Further, such a scheme would also allow the traditional telecommunications
providers a means for becoming more involved in the Internet, thus allowing
cross-leverage of technologies and experience.

The transition from top-down to economic model must be handled carefully,
but this is exactly the kind of statesmanship that the Internet should
expect from its leadership.
-------
-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 89 14:00:46 GMT
From:      mckee@MITRE.MITRE.ORG (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: Using the 4.2 broadcast addr with 4.3 systems

A few months ago Phil Karn argued that any given host should one IP
address, not one per network interface.  I would appreciate some
tutorial words on the relative merits of single vs multiple IP
addresses.  "An enquiring mind"  - Craig

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 89 14:47:20 GMT
From:      samc@ntpdvp1.UUCP (Sam Christie)
To:        comp.protocols.tcp-ip
Subject:   Wollongong TCP on 386 Streams problems


We are using SysV/386 for a small (10 node) network.  The net
is based on RFS running over Wollongong TCP/IP for streams.
We have also written a network based multi-terminal access system
which permits us to use an existing arcnet network to connect into
SysV.  This software relies on streams and the ld0 (ldterm) module.
Unfortunately, when a user so connected attempts to use telnet or
FTP, the Wollongong software goes south.  It is apparently assuming 
that the incoming user is using its own sockets implementation.  It
seems that the software is confused because the user is comming in
through a streams device.

I am hoping that some change to our streams device would enable the TCP/IP
software to accept the user normally.

Also, if Wollongong is accessable via uunet, I would like a contact.

Thanks for your assistance via email to:

Sam Christie
Northern Telecom - DMS-10
Research Triangle Park, NC
EMAIL ...!uunet!mcnc!rti!ntpdvp1!samc
919/992-3917

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 89 15:56:52 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   better authentication methods

Is anyone working on better authentication methods for things like
SNMP and OSPFIGP?  The former today seems to rely on the "community
string", which in essence boils down to a clear-text password; the
latter, as of the July '89 draft, has only a 64-bit clear-text password
as a defined authentication type.  These strike me as insufficient.

In lieu of anything else, let me propose a strawman authentication
mechanism.  Use DES in CBC mode to generate a 32-bit MAC, as per
X9.9, on the text to be protected.  Emit a 32-bit key id, followed
by the MAC, as the 64 bits of authentication data.  In an environment
where all of the entities involved are under the same management,
and are (reasonably) physically secure, all of the gateways in
question can share the same DES key, and hence the same key id.
Alternatively, each gateway could have a separate key and key id;
only its neighbors would have to know that key.

In a large-scale network, this would all break down because I haven't
proposed any key management mechanism.  That's a separate issue,
though; small numbers of keys can be loaded manually, and a protocol
to do that (Kerberos?) can be layered on later.

There is also the export problem for U.S.-made gear.  I don't think
that's a serious obstacle here.  For one thing, *any* cryptographic
authentication scheme will have that problem.  For another, I am
suggesting use of DES solely for authentication and not secrecy;
recently-proposed relaxations of the export rules would allow that,
I believe.  Finally, I am suggesting the same mechanism used for
validating EFT transfers, another exception to the export rules;
while this isn't EFT, the technology (and hence the alleged "risk",
such as it is, to U.S. national security) is identical.

Comments?

		--Steve Bellovin
		smb@ulysses.att.com

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 89 17:57:08 GMT
From:      pat@grebyn.com (Pat Bahn)
To:        comp.protocols.tcp-ip
Subject:   re Interop Attendees only


 Sorry about the last posting, but I was in a rush before the system
was shutdown.  

  Michelle thibault reccomended that I put a little more detail into my
posting, so here it is.  I am a 26 year old grad student / netwrok
security engineer at GTE.  unfortunately I'll be lucky if I can get them
to pay for the conference ticket and I'll probably have to eat the
housing and travel.  Heck I'm not getting pay while i'm at the
conference even (Ow).  So I was hoping to find someone who wouldn't mind
sharing a room there on a 50/50 basis.  I'll reimburse cash to anyone
charging to the company acct.  that way I get a dry place to sleep, 
you whoever you are have some travel money.  I am a male which I didn't
mention before, I have pretty good social habits (shower daily etc)
and am pretty good company.  I'm mostly harmless and sandra thinks
i'm cute.  For more details e-mail me.
  thanks
 pat

-- 
=============================================================================
Pat @ grebyn.com  | If the human mind was simple enough to understand,
301-948-8142      | We'd be too simple to understand it.   
=============================================================================

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 89 19:17:33 GMT
From:      sl@van-bc.UUCP (Stuart Lynne)
To:        comp.protocols.tcp-ip
Subject:   Re: v32 or PEP for SLIP

In article <293@archet.UUCP> wlm@archet.UUCP (William L. Moran Jr.) writes:
}Yes, I use a pair of t2500s for slip. They are used in v32 mode as
}this is much faster for anything interactive (slower for ftp by a good
}bit). If what you want is a good reliable v32 modem I would not
}hesitate to advise the purchase of t2500s. If you are willing to put
}up with a good deal of heartache in exchange for better performance,
}get microcom QX/V.32c modems. At 38.4k they work really well with
}slip. Unfortunately, my opinion is that they are poorly built, so they
}are prone to infant mortality and unreliability.


Our traffic is composed of:
	
	1. news feed via nntp
	2. mail with smtp
	3. occasional ftp

Overall I would like nntp and smtp to be fast and efficent. Would they fit
the "interactive" or "ftp" model of usage?

-- 
Stuart.Lynne@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 89 19:27:30 GMT
From:      loverso@Xylogics.COM (John Robert LoVerso)
To:        comp.protocols.tcp-ip,comp.dcom.modems
Subject:   Re: v32 or PEP for SLIP

In article <6991@sdcsvax.UCSD.Edu> jc%andataco.uucp@ucsd.edu (John Cornelius) writes:
> Well, Telebit has done a lot of work with SLIP.  At Uniforum, for instance,
> they hooked the show's ethernet to the internet via slip running on a Sun
> of some sort.  I'm fairly certain they were using PEP mode.

Actually, the setup at Uniforum (the recent show here in Boston)
was the same as at the Baltimore USENIX terminal room.  The link
was over a pair of T2500s, using V.32 at 9600bps (i.e., not PEP).
Over this, Van Jacobson's TCP header compression SLIP was run btwn
a Sun3/60 at the show and an Annex-II terminal server at BB&N.
The only differences from Baltimore were that (1) the Annex was at
the remote end and (2) the whole network was advertised to the Internet,
not just a bunch of terminals.

-- 
John Robert LoVerso			Xylogics, Inc.  617/272-8140
loverso@Xylogics.COM			Annex Terminal Server Development Group

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 89 19:31:00 GMT
From:      loverso@Xylogics.COM (John Robert LoVerso)
To:        comp.protocols.tcp-ip,comp.dcom.modems
Subject:   Re: v32 or PEP for SLIP

In article <30979@ucbvax.BERKELEY.EDU> hegarty@janus.Berkeley.EDU.UUCP (Christopher Hegarty) writes:
> I'd appreciate any advice/experience people can offer with regard
> to running X over SLIP with modems.

Without Van Jacobson's TCP header compression for SLIP (or, rather, PPP),
its not very worthwhile to run a X terminal over a 9.6 or 19.2 SLIP link.
The results are very poor.  In this case, a GraphOn using their proprietary
serial protocol (with the X server actually running on a remote host) works
better at 9600bps then either NCD or Visual using SLIP at 19.2kpbs.

John

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 89 21:08:02 GMT
From:      davidf@colnago.wpd.sgi.com (David Fenstemaker)
To:        comp.protocols.tcp-ip
Subject:   Columbia Appletalk Package

Does anyone know how to get information about the Columbia Appletalk
package, and/or source code?

Thanks,

David Fenstemaker
davidf@sgi.com

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 1989 03:54-EDT
From:      CERF@A.ISI.EDU
To:        jupiter!karn@FLASH.BELLCORE.COM
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: TCP/IP close connection TIME_WAIT ?
Phil and Sandy have done a good job of explaining the mechanism
and rationale for TIME_WAIT. During the design phase of TCP,
tremendous effort was put into exploring, through case
analysis, various sequences of events in various orders. 

The "two armies" problem is also called the Byzantine
Generals problem in the literature on synchronization.
There are some wonderfully complicated variations in
which there are more than two generals and some of them lie.

In any case, no amount of waiting and acking will guarantee
anything - but the states are there to reduce the possibility
that a successful session is considered a failure for lack
of an ACK. Generally, though, such designs fail safe in that
a truly unsuccessful session is not accidently considered
successful though a successful one may be mislabelled a
failure.

Vint

END OF DOCUMENT