The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1991)
DOCUMENT: TCP-IP Distribution List for January 1991 (486 messages, 277165 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1991/01.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 Jan 91 05:00:12 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip,comp.protocols.nfs,comp.unix.msdos,comp.sys.ibm.pc.misc
Subject:   Re: NCSA Telnet with PC-NFS and Clarkson pktd.sys

You can't get there from here.

  1) Your telnet package is configured to write directly to the card.  That
     will confuse the packet driver mightily.

  2) Even if your telnet package was configured to go to the packet driver,
     you're already running a TCP/IP package, so telnet won't get the handles
     it wants.

You have three solutions: Run Sun's telnet, reboot (as you're doing now),
or run Clarkson's telnet for PC-NFS.  I don't know exactly how to get it,
but I'm sure it's on omnigate.clarkson.edu somewhere obvious...

--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  FAX 315-268-7600
It's better to get mugged than to live a life of fear -- Freeman Dyson
I joined the League for Programming Freedom, and I hope you'll join too.

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Jan 91 13:10:59 PST
From:      "Raj Jain, DEC, 550 King St. LKG 1-2/A19, Littleton, MA 01460  01-Jan-1991 1607" <jain@erlang.enet.dec.com>
To:        mail11:;@decpa.pa.dec.com@decpa.pa.dec.com (decwrl::"tcp-ip@sri-nic.arpa",decwrl::"ietf@venera.isi.edu",decwrl::"performance@vuse.vanderbilt.edu",@report)
Subject:   New Technical Report on Congestion Available (DEC-TR-724)
The  following  DEC  technical  report  is  now  available   for   external
distribution.

DEC-TR-724: Myths About Congestion Management in High-Speed Networks
            10 pages.

If you would like to receive a hard copy, please reply to this message with
your address in a form suitable for direct application as a mailing label.

Any other words or sentences in the reply will only delay the delivery.

The abstract of the report is as follows:


                                DEC-TR-724
         Myths About Congestion Management in High-Speed Networks
                                by Raj Jain

Weaknesses in several recently proposed ideas about congestion control  and
avoidance  in high-speed networks are identified.  Both sides of the debate
concerning prior-reservation of resources versus walk-in service, open-loop
control  versus  feedback  control, rate control versus window control, and
router-based  control  versus  source-based  control  are  presented.   The
circumstances  under  which  backpressure  is  useful  or  not  useful  are
discussed, and it  is  argued  that  a  single  congestion  scheme  is  not
sufficient,  but  that  a  combination  of  several schemes is required for
complete congestion management in a network.
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Jan 91 13:57:11 pst
From:      "Jay W. Melvin" <well!infopath@APPLE.COM>
To:        tcp-ip@NIC.DDN.MIL
Subject:   ICMP HOST_UNREACH Param: 1777
Greetings, and thanks in advance to anyone willing and able to address this 
question.

BACKGROUND:  I am implementing ICMP for the first time and need clarification
on the topic of Error_to_Source messages.

ISSUE:  MIL-STD 1777, Reassembling state decision table (pg. 1-119).
The test "Where_to?"  (pg. 1-126) tests the following to determine if the 
datagram is "destined for this site":
        1.  Datagram options for completion of source route address visits,
        2.  Datagram destination address for identity with this host's id.
If either test fails, the decision table specifies that the HOST_UNREACH 
parameter should be passed to the Error_to_Source routine (pg. 1-131).

PROBLEM 1:  The Error_to_Source routine does not accept the HOST_UNREACH
parameter.  Instead, it accepts the PROTOCOL_UNREACH parameter, which has
not been tested for by "Where_to?".

PROBLEM 2:  Consulting RFC 792 (pg. 5) deepens the apparent inconsistency 
by stating that the HOST_UNREACH parameter is generated by gateways, not hosts.

Additionally, D. P. Sidhu's execllent RFC 963 (pg. 16) reinforces the
PROTOCOL_UNREACH parameter by mentioning it in reference to another issue,
but does not cite it as a problem in itself.

QUESTIONS:
Is there really an inconsistency here, or have I missed something?
What information does the Internet Community expect the HOST_UNREACH ICMP 
  message to communicate?  
Is it actually acceptable for a host to issue the HOST_UNREACH message 
  under the conditions described above?  
Is there a discussion in the ICMP literature which would clarify the
  usage of the HOST_UNREACH parameter, since it appears to be the correct 
  parameter to expect from a failed "Where_to?" test in a host environment.


Many thanks,  

Linda Melvin 
Senior programmer 
infoPATH Communications Software Services, La Honda, CA
infopath@well.com.sf.ca.us

P.S.  This is also my first attempt to use the TCP-IP forum.  
Please advise if I've not done it correctly.



-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 91 16:05:49 GMT
From:      n8emr!vlink01!sfrazier@tut.cis.ohio-state.edu  (8780)
To:        tcp-ip@nic.ddn.mil
Subject:   mail and TCP/IP
I am new to the TCP/IP world.  I am trying to set up mail between two
machines on TCP/IP via SCO's mmdf.  I feel I have the fine documentation
provided by SCO's Chris Durham (thanks much, Chris, excellent work), but I
have just one other question.  When you set up an account for uucp, you
must do just that set up an account and password for that account for uucp, but
*do you* have to do that same for TCP/IP or it is handled some other way?

In other words, if I set up everthing to work on mmdf, do I have to actually
set up an account for 192.000.000.1 or whatever for them to pass mail to me?
I need a little help in understanding that part of it.  If someone would please
respond via email to me, I would greatly appreciate it.

Thanks in advance.


-- 
V-Link                                  | Steven E Frazier
1828 Darrow Drive                       |---------------------------------------
Powell OH   43065-9261                  | Local : sfrazier
614-365-3056                            | Remote: osu-cis!vlink01!sfrazier
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jan 91 01:43:07 PST
From:      earle@poseur.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support)
To:        aaron@ux.ACS.UMN.EDU, comp.protocols.tcp-ip
Cc:        tcp-ip@nic.DDN.MIL
Subject:   Re: Summary: PPP and/or SL/IP between SparcStations via v.42bis modems
In comp.protocols.tcp-ip article <9101011904.AA20885@ucbvax.Berkeley.EDU> you write:
>Well, I tried (on a Sun3/160 running SunOS 4.1) both the
>omnigate.clarkson.edu:pub/sun/ppp.tar.Z and the
>tut.cis.ohio-state.edu:pub/ppp/* (with the patches applied)
>but I consistently got
>
>        ppp: ioctl(I_PUSH, ppp_async): Invalid argument
>
>(then quited to system prompt) for nearly all invocations of ppp.

The "ppp.h" file needs to be included in /sys/sun/str_conf.c at the end of the
#include section (before the start of the "#if	NFOO > 0" section).  Step 3
of the instructions failed to mention this.

*** Readme.streams.orig	Sun May 20 10:15:31 1990
--- Readme.streams	Wed Jan  2 01:35:20 1991
***************
*** 70,73 ****
--- 70,77 ----
  	   top of the file, where similar lines are located:
  
+ 		#include "ppp.h"
+ 
+ 		...
+ 
  		#if     NPPP > 0
  		extern struct streamtab ppp_asyncinfo;


-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 91 19:03:58 GMT
From:      aaron@UX.ACS.UMN.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Summary: PPP and/or SL/IP between SparcStations via v.42bis modems


Well, I tried (on a Sun3/160 running SunOS 4.1) both the
omnigate.clarkson.edu:pub/sun/ppp.tar.Z and the
tut.cis.ohio-state.edu:pub/ppp/* (with the patches applied)
but I consistently got

        ppp: ioctl(I_PUSH, ppp_async): Invalid argument

(then quited to system prompt) for nearly all invocations of ppp.

I tripple-checked that the kernel has been modified as directed,
and the mod seemed successful (at least ppp0 thru ppp5 exist if
I pre-attach them in the config file).  I also changed the
_sys_types_h to __sys_types_h in <pixrect/pr_impl_util.h> as
Greg suggested. No luck and same error.

Any kind souls out there willing to give me some hints?

Thanks and cheers for the happy new year.
/aaron.cheung
aaron@ux.acs.umn.edu

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 91 22:55:20 GMT
From:      mcsun!ukc!stl!dww@uunet.uu.net  (David Wright)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: More routing question information
In the referenced article tneff@bfmny0.BFM.COM (Tom Neff) writes:
#In article <PCG.90Dec31145142@teachk.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
#>	[ ... kithrup has links to both SCO, a USENET site, and
#>	ucscc, which is an Internet site but has an UUCP link to
#>	kithrup, yet does not advertise itself as a USENET site or
#>	an Internet-USENET gateway ... ]
#
#Excuse me, but what in the world is an "Internet-USENET gateway"?
#
#I would not ordinarily object to casual misuse of the basic mail/news
#terminology, but when someone of Piercarlo's stature gets it wrong, and
#bases an entire long argument on it, I have to wonder what he really means.

I shouldn't worry about it - or anything else that Piercarlo posts.
It is his normal way to almost totally misunderstand a situation, build a
whole false edifice based on a small grain of truth, then post polemics
complaining that the situation he has imagined is wrong.

I used to argue with him - especially because of that grain of truth which
sometimes does need to be dealt with - but I have learned that it is a waste
of time.   And nobody should believe any of his statements about how the
various nets are organised unless they are corroborated by other, competent,
people.

I am sorry to so denigrate the views of another member of the net: it is
not my usual way.   But Piercarlo has confused so many arguements with his
distorted view of the world that I consider it necessary to warn others.

Regards,      David Wright       STL, London Road, Harlow, Essex  CM17 9NA, UK
dww@stl.stc.co.uk <or>  ...uunet!mcsun!ukc!stl!dww <or>  PSI%234237100122::DWW
Usenet works on the principle that 10,000 people know more about the answer to
any question than one does.  Unfortunately they know 10,000 different answers.
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 91 23:19:08 GMT
From:      sdd.hp.com!samsung!umich!sharkey!nstar!larry@ucsd.edu  (Larry Snyder)
To:        tcp-ip@nic.ddn.mil
Subject:   PC Interface (on the DOS machine)
I have PC Interface running here on ash.rn.com - 
and how do I remap the page up / page down keys
using the supplied emulator (em)?

-- 
       Larry Snyder, Northern Star Communications, Notre Dame, IN USA 
  {..!uunet!mailrus!iuvax!ndcheg!nstar!larry, larry%nstar@ndcheg.cheg.nd.edu}
                     backbone usenet newsfeeds available
         Public Access Unix Site (219) 289-0282 (5 high speed lines)
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jan 91 11:09:06 EST
From:      ccci!tcs@uunet.UU.NET (Terry Slattery)
To:        tcp-ip@nic.ddn.mil
Cc:        cisco@spot.colorado.edu
Subject:   Routing loop tools
Has anyone developed tools for diagnosing routing loops?  I'm thinking of
something that gets routing tables and configurations from multiple routers
in a 'snapshot' fashion while the routing loop exists.  Using SNMP would be
nice, but the MIB doesn't contain an entry identifying the source of the
routes (i.e. static, RIP derived, etc), making it more difficult to
determine the source of the problem.  [Should MIB-II incorporate such a
variable?]  I'm planning on building something to telnet to each router and
grab a copy of the routing table, perhaps using 'expect', but wanted to
check for existing tools first.  

Tools for analyzing the routing tables would be nice, but not critical.

Thanks,

	-tcs
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jan 91 15:35:56 -0500
From:      Bob Stewart <rlstewart@eng.xyplex.com>
To:        tcp-ip@nic.ddn.mil
Subject:   Unix Applications
Excuse me for misusing the mailing list, but of the resources I have, I figure
this group contains the smartest, most knowledgable, helpful, and public
spirited people I can get to.  :-)

I need a lead on UNIX-based applications for basic text editing and electronic
mail.  Xyplex is migrating slowly from VMS to Unix, and that means we're about
to inflict all its arcanity on people who should be better protected.  GNU
Emacs and such are (barely) acceptible for us computer freaks, but not for the
clerks, accountants, secretaries, and such that make up the rest of a company
and have other concerns.  We want everyone to have access to electronic mail
and simple text editing, but have no idea what applications are available or
suitable.  Somewhere out there must be a text editor and a mail interface that
are easy to learn and easy to use without a manual and an endless ability to
remember obscure commands and beat a computer into submission.

If you know of such applications, either free or commercial, please email me
directly.  Don't leave it to someone else, because I'm afraid what I'm looking
for is not well known, and you who know about it are rare.

Thanks,

	Bob

-----------
Bob Stewart (rlstewart@eng.xyplex.com)
Xyplex, Boxborough, Massachusetts
(508) 264-9900
-----------[000010][next][prev][last][first]----------------------------------------------------
From:      ljm@TWG.COM
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sockets, TLI, or what
>
>If you are concerned with portability (and the original poster was), you
>can't ignore TLI and streams.  It is the socket interface that will be
>going away (but not for a *long* time...).
>	

I usually find the most useful way to explain the relationship of TLI
and sockets is to consider TLI the 'native' transport interface for
UNIX and sockets is more of a cross-platform API.

Thus, the native interface for UNIX is TLI which is different from the
native interface for the Macintosh, MacTCP, which is different from the
native interface(s) for DOS, FTP Software's or our's or whatever, which
is different from the native interface on VMS, and so on.

The tradeoff is usually quite simple.  On all the platforms, the native
interface offers unique advantages to the developer of system specific
applications in terms of memory usage, performance, functionality or
perhaps
all three.  However, a sockets API is available on all of these platforms.

So, if you are absolutely sure that your application will only
run on one of them, or if your application absolutely requires the improved
functionallity only present in the native interface, then use it.

Otherwise, use the sockets API as it will ease the port of your application
to different platforms (or even same platform/different vendor in the DOS
and OS/2 cases).

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





-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jan 91 15:15:15 MST
From:      cpw%snow-white@LANL.GOV (C. Philip Wood)
To:        eru!hagbard!sunic!news.funet.fi!funic!santra!news@bloom-beacon.mit.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  TCP window size restriction

What if you were to send more than one packet at a time.  Like
1600 packets before requiring an ACK.  In other words bump the
window you can send into.

Phil
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jan 91 17:52:06 PST
From:      postel@venera.isi.edu
To:        shakti!shri@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Re:  What ever happened to IEN-193 ????
Hi.

IEN-193 is a reprint of a paper by Dick Watson published in the 
North-Holland journal "Computer Networks" vol-5, no-1 in Feb 1981.

--jon.


   From tcp-ip-RELAY@NIC.DDN.MIL Wed Jan  2 17:44:42 1991
   Date: 2 Jan 91 13:15:03 GMT
   From: shakti!shri@uunet.uu.net  (H.Shrikumar)
   Subject: What ever happened to IEN-193 ????
   Sender: tcp-ip-relay@nic.ddn.mil
   To: tcp-ip@nic.ddn.mil
   
   Hi everybody ... and wishing all a great new decade !
   
       Does anybody know what happened to IEN-193 ...
   
   }} ien-193	Timer-Based Mechanisms in Reliable Transport 
   }}                 Protocol Connection Management
   
       nic is missing this one, and (hence) so are all major caches !!
   
   The mechanism itself enjoys a section in Tennenbaum, so I dont suppose
   this one died a natural death. So what happened to the publication?
   
    Or does anybody know any other reference with this work (ftp, or journal)?
   
   Please E-mail ... all pointers appreciated!
   I need this info very urgently ... thanx in advance for all help!!
   
   -- shrikumar ( shri@ncst.in )
   

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jan 91 15:27:15 EST
From:      kasten@europa.InterLan.Com (Frank Kastenholz)
To:        ccci!tcs@uunet.UU.NET, tcp-ip@nic.ddn.mil
Cc:        cisco@spot.colorado.edu
Subject:   Re:  Routing loop tools
 > From tcp-ip-RELAY@NIC.DDN.MIL Wed Jan  2 14:08:22 1991
 > From: ccci!tcs@uunet.UU.NET (Terry Slattery)
 > To: tcp-ip@nic.ddn.mil
 > Cc: cisco@spot.colorado.edu
 > Subject:  Routing loop tools
 > 
 > Has anyone developed tools for diagnosing routing loops?  I'm thinking of
 > something that gets routing tables and configurations from multiple routers
 > in a 'snapshot' fashion while the routing loop exists.  Using SNMP would be
 > nice, but the MIB doesn't contain an entry identifying the source of the
 > routes (i.e. static, RIP derived, etc), making it more difficult to
Yes it does ... look at ipRouteProto

Frank Kastenholz
Racal Interlan
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jan 91 17:44:37 EST
From:      fab@md.interlink.com (Fred Bohle)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  TCP window size restriction
Window size expansion has already been covered by RFC 1072.  An option
code of 3 gives a shift amount for the 16-bit window field.  Note that
other parts of RFC 1072 have not been generally agreed to, but *this*
part of it is.  It is a simple matter to generate this option in the
open logic and look for it from the other end.  Then simply shift the
window the specified amount to use expanded windows.  Note also that
both ends must specify the option in order for either side to use it.
One side may specify a shift amount of zero, in order to indicate
support, but no expanded window.

Some brain-dead TCP implementations may hiccup at an unrecognized
option code, but they are non-compliant if they do.  RFC 1122 says
in 4.2.2.5 "A TCP MUST ignore without error any TCP option it does
not implement..."

So please explore using RFC 1072 for your needs.  I put it into our
product, SNSTCP/access, and it works fine.

Fred
------------------------------------------------------------------------
Fred Bohle			EMAIL: fab@leo.md.interlink.com
Interlink Computer Sciences	AT&T : 301-317-6600 
9145 Guilford Road, Suite 175
Columbia, MD 21046
------------------------------------------------------------------------

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 91 13:15:03 GMT
From:      shakti!shri@uunet.uu.net  (H.Shrikumar)
To:        tcp-ip@nic.ddn.mil
Subject:   What ever happened to IEN-193 ????
Hi everybody ... and wishing all a great new decade !

    Does anybody know what happened to IEN-193 ...

}} ien-193	Timer-Based Mechanisms in Reliable Transport 
}}                 Protocol Connection Management

    nic is missing this one, and (hence) so are all major caches !!

The mechanism itself enjoys a section in Tennenbaum, so I dont suppose
this one died a natural death. So what happened to the publication?

 Or does anybody know any other reference with this work (ftp, or journal)?

Please E-mail ... all pointers appreciated!
I need this info very urgently ... thanx in advance for all help!!

-- shrikumar ( shri@ncst.in )
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jan 91 19:10:39 EST
From:      ccci!tcs@uunet.UU.NET (Terry Slattery)
To:        tcp-ip@nic.ddn.mil, cisco@spot.colorado.edu
Subject:   ipRouteProto
Several people have pointed out the existance of the source of the routing
protocol which I missed in looking through MIB-I.  The tool I used to poll
some routers didn't show it and my quick look in the MIB document I used was
too quick.

Only one person so far claims to have a tool for troubleshooting routing
problems.  There must be a lot of smoothly runing nets out there ;-).

	-tcs
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 91 14:38:21 GMT
From:      Z00EJR01%AWIUNI11@PUCC.PRINCETON.EDU (Ewald Jenisch)
To:        comp.protocols.tcp-ip
Subject:   lpd for PC under MSDOS

Hi folks,

I'm looking for a LPD (not lpr|) implementation that runs on a PC
under MSDOS. If anybody out there knows of such a program (pd/shareware)
please drop me a line - you will save me from a lot of trouble.

Thanks very much in advance,

Ewald JENISCH
University Computer Center
University of Vienna, Austria

E-mail: Z00EJR01@AWIUNI11.BITNET                Snail-mail:
        Z00EJR01@helios.edvz.univie.ac.at       Universitaetsstrasse 7
Tel.:   (+43 222) 43-61-11/251                  A-1010 Vienna, Austria
Fax:    (+43 222) 43-61-11/170                  Europe

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Wed, 02 Jan 91 14:28:49 MEZ
From:      Ewald Jenisch <Z00EJR01%AWIUNI11@pucc.PRINCETON.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   lpd for PC under MSDOS
Hi folks,

I'm looking for a LPD (not lpr|) implementation that runs on a PC
under MSDOS. If anybody out there knows of such a program (pd/shareware)
please drop me a line - you will save me from a lot of trouble.

Thanks very much in advance,

Ewald JENISCH
University Computer Center
University of Vienna, Austria

E-mail: Z00EJR01@AWIUNI11.BITNET                Snail-mail:
        Z00EJR01@helios.edvz.univie.ac.at       Universitaetsstrasse 7
Tel.:   (+43 222) 43-61-11/251                  A-1010 Vienna, Austria
Fax:    (+43 222) 43-61-11/170                  Europe
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 91 15:55:32 GMT
From:      cs.utexas.edu!usc!wuarchive!swbatl!gandalf!uucigj@tut.cis.ohio-state.edu  (Gregg Jensen 5-3531)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP for 386 again...
Some time back someone made available the source for SLIP
for 386 unix.  Is there an ftp site that it can be retrieved
from (or is there a kind soul that could mail it)?  Also, has
work been done with it to incorporate PPP into it?  Has 
anyone compared this slip package with the ka9q that runs on
unix?  

      Gregg Jensen
---------------------------------------------------------------------- 
 These opinions are my own and do not necessarily reflect my companies.
      Southwestern Bell Telephone
---------------------------------------------------------------------- 
 
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 91 16:18:17 GMT
From:      cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uwm.edu!csd4.csd.uwm.edu!hardiman@tut.cis.ohio-state.edu  (Paul V Hardiman)
To:        tcp-ip@nic.ddn.mil
Subject:   NCR/Comten Info
My organization is looking into purchasing an NCR/Comten
frontend processor with TCP/IP capabilities.  This box would
replace an existing IBM 3720 and additionally connect to a
campus Ethernet.  It would connect to an IBM 3081 CPU.

Is there anyone who's had experience with this company's 
products and is willing to share it?

Please reply via email.

Thanks in advance for any information you can offer.
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 91 16:28:10 GMT
From:      eru!hagbard!sunic!news.funet.fi!funic!santra!news@bloom-beacon.mit.edu  (Antti Louko)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP window size restriction
This is a crazy idea I have been thinking of.

As we all know, the window field in the TCP protocol is 16-bit and can
thus represent only values 0 .. 65535. This limits the available
bandwidth of a single TCP connection to 65535/T octets/second. With 1
second round-trip-delay we can get at most 64 Kbytes/second.

The solution I have in mind is as follows:

TCPs at each end agree a new meaning for window sizes 65520 .. 65535.
65520 means window size 2^(65520-65504) = 2^16
65521 means window size 2^(65521-65504) = 2^17
etc.
65535 means window size 2^(65521-65504) = 2^31.

Please remember that this has to be agreed by both TCPs.

Please comment!

	Antti Louko (alo@hut.fi)
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 91 21:26:23 GMT
From:      att!emory!hubcap@ucbvax.Berkeley.EDU  (System Janitor)
To:        tcp-ip@nic.ddn.mil
Subject:   firewall
Hi... does anyone know how to make a unix host act as a firewall?

I have a DECstation that is acting as the router for a network of PCs.

I don't want anonyomous PC users to be able to telnet anywhere they
want on the Internet, but only to other hosts, specified by us, on our
class B network. In otherwords, I want it to be a firewall.

So far the only way I've been able to do what I want is by adding a static 
route to the DECstation gateway (this gets the PC's packets out) and a 
static route to the external host I want to be able to reach (this gets 
that host's packets back in). This is workable, but not
desireable from a management standpoint (if there were 100 hosts on campus
that the PCs might need to reach, that would mean 100 static routes would 
have to be added by hand to all 100 hosts).

I fooled around with gated some, in particular with the pointtopoint RIP 
option. I told gated to only do pointotpoint RIP and that the sourceripgateway
was one of the SUN servers on campus. I hoped that this would allow the
PCs to have connectivity with the SUN (and the subnet it serves) but 
the PCs ended up with full connectivity to everywhere via ICMP redirects 
through the SUN server.

Any ideas?

-Mike
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 91 21:56:09 GMT
From:      eru!hagbard!sunic!news.funet.fi!funic!santra!kampi.hut.fi!alo@bloom-beacon.mit.edu  (Antti Louko)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP window size restriction
In article <1991Jan2.162810.6356@santra.uucp> alo@kampi.hut.fi (Antti Louko) writes:
I said:
>This is a crazy idea I have been thinking of.
Idea itself is not so crazy, but there are problems and it needs
thinking.

I was kindly enlightened by mckenzie@bbn.com to look at RFCs 1110 and
1185 which indeed have things discussed quite thoroughly.

This restriction in TCP bandwidth came up in one seminar where some
OSI people were bashing Internet protocols. At that time, RFC1185
hasn't come out, and I didn't check again... (shame on me)

Anyway, now I can tell that TCP will have a solution before OSI :-)

	Antti Louko
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 91 22:33:37 GMT
From:      mcsun!ukc!dcl-cs!aber-cs!athene!pcg@uunet.uu.net  (Piercarlo Grandi)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: More routing question information
On 1 Jan 91 22:55:20 GMT, dww@stl.stc.co.uk (David Wright) said:

dww> In the referenced article tneff@bfmny0.BFM.COM (Tom Neff) writes:

pcg> In article <PCG.90Dec31145142@teachk.cs.aber.ac.uk>
pcg> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:

tneff> Excuse me, but what in the world is an "Internet-USENET gateway"?
tneff> I would not ordinarily object to casual misuse of the basic
tneff> mail/news terminology, but when someone of Piercarlo's stature
tneff> gets it wrong, and bases an entire long argument on it, I have to
tneff> wonder what he really means.

Please note the (gentle, and well accepted) irony: the paragraph above
can be read "Piercarlo's entire argument makes no sense whatever because
it is based entirely on totally inappropriate terminology". It can also
be read in many other ways. I like this style. I like less this style:

dww> I shouldn't worry about it - or anything else that Piercarlo posts.
dww> It is his normal way to almost totally misunderstand a situation,
dww> build a whole false edifice based on a small grain of truth, then
dww> post polemics complaining that the situation he has imagined is
dww> wrong. [ ... and worse ... ]

This is called humour-impairment, man. Cool your jets :->.

As to whether there is really something strange in the water in
Aberyswyth, let the readership beware. I am quite sure that they can
make up their own minds. Networks are a very political thing, and
everybody knows, or ought to know, that. Maybe not everybody knows that
I have no interest whatsoever in these politics except intellectual
curiosity and concern over an important aspect of the field which I have
chosen for my career. I am not selling anything here -- I am just a wary
customer. Others cannot say the same.

Rubbishing other people's reputation in the extravagant way you use
demonstrates little diplomatic sense. Or maybe you want to become a
celebrity -- maybe one day it will be possible to prove attribution, and
then you make history by being the first person to lose a million pounds
thanks to a posting. Keep trying :->.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 91 23:50:10 GMT
From:      ogicse!milton!Tomobiki-Cho!mrc@ucsd.edu  (Mark Crispin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: POP protocol
In article <E9633327E93FE1EE45@vaxsar.bitnet> BIWINE@VAXSAR.VASSAR.EDU (Bill Wine) writes:
>Our concern is that the POP architecture
>may not be sutiable for a large mail system.  It seems inefficient for
>the POP client to check for newmail every 5 or 10 minutes.
>It seems to me that a
>better idea would be for a client to log in once, and for the server
>to check for newmail periodically, then send it to the client.  

There is no way that I am aware of in either the POP2 or the POP3
protocol for a client to check for new mail; the only way is to close
the POP connection and open a new one.  There are some auxillary
protocols to "check for new mail", some of which I believe are UDP
based.

>Would anyone care to share their experiences with large Mac or PC
>e-mail systems (100+ concurrent users).  Is the POP architecture
>suitable for large systems?  Is there a better one?

An alternative to the POP protocols is the IMAP protocol (RFC-1176).
IMAP provides both an explicit "check for new mail" and server-
controlled new mail notification.

You can get a distribution package on FTPHOST.CAC.WASHINGTON.EDU (IP
address 128.95.112.1) as imap/imap.tar.Z via anonymous FTP.  Stanford
has written a Mac client.  I wrote a NeXT and generic Unix client; I'm
working on a PC client for IMAP now.  The IMAP distribution also
includes a POP2 and POP3 server so you can leverage on your existing
POP software without incompatibilities (the underlying mail access
library is the same in all cases); the POP servers can also be IMAP
clients so any POP clients can access IMAP servers.

Whether you choose IMAP or POP depends a lot upon what you are trying
to do.  They are often mistakenly thought of as competing protocols,
but really have different functionalities.  POP is for downloading an
RFC-822 format mailbox to a client, whereas IMAP is for a client to
manage and retrieve data on a remote mailbox maintained on a server.

 _____   | ____ ___|___   /__ Mark ("Gaijin") Crispin "Gaijin! Gaijin!"
 _|_|_  -|- ||   __|__   /  / R90/6 pilot, DoD #0105  "Gaijin ha doko?"
|_|_|_|  |\-++-  |===|  /  /  Atheist & Proud         "Niichan ha gaijin."
 --|--  /| ||||  |___|    /\  (206) 842-2385/543-5762 "Chigau. Omae ha gaijin."
  /|\    | |/\| _______  /  \ FAX: (206) 543-3909     "Iie, boku ha nihonjin."
 / | \   | |__|  /   \  /    \MRC@CAC.Washington.EDU  "Souka. Yappari gaijin!"
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 91 00:50:19 GMT
From:      kxb@mpccl.ksu.edu (Karl Buck)
To:        comp.protocols.tcp-ip,comp.protocols.nfs,comp.unix.msdos,comp.sys.ibm.pc.misc
Subject:   Re: NCSA Telnet with PC-NFS and Clarkson pktd.sys

kxb@einstein.mpccl.ksu.edu (Karl Buck) writes:

>Greetings. I am trying desperately to get NCSA Telnet, PC-NFS to work
>with the Clarkson packet drivers in our lab. Everything works great until:
 
>	1. You exit Telnet
>	2. You attempt to shell out (Alt-e)
>	3. You exit FTP
 
>In each instance the client machine locks up with the Network activity light
>staying on constantly. 
 
>After exiting telnet the following error comes up:
>"run-time error R6001
> - null pointer assignment"

First, let me thank everyone for all the patient replies. I ended up using
CUTE (Clarkson University Terminal Emulator) Ver. 2.2TN/NFS-A. It works
quite nicely since it was compiled using the PC-NFS Toolkit. It will be 
available via anonymous ftp (temporarily) in the directory pub/misc on
einstein.mpccl.ksu.edu. Check out the file README for more information.
(Happy New Year)
--
 Karl Buck
 Dept. of Mathematics              email: kxb@einstein.mpccl.ksu.edu    
 Kansas State University
 Manhattan, KS 66502               Phone: (913)532-6750

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Jan 91 12:54:45 PST
From:      rlg@desktalk.com (Richard L. Gralnik)
To:        tcp-ip@nic.ddn.mil
Good People!

I have received many requests for more information on Lotus' database of
information on private US citizens.  Here is everything I have received.

Many people have stated an interest in expressing their opinion of Lotus'
database and policies/attitudes about it.  As a community service, here 
is the email address of Jim Manzi, the CEO of Lotus, for those of you 
who have something to say to him on the subject.

Please address your message as follows:

	To:  jmanzi@lotus.com

If you have any problems with lotus.com mail please call Lotus at
(617)577-8500.
 
I realize that this isn't a TCP/IP topic, but I guess you could say 
(assuming you decide this is a problem), that TCP/IP, by providing an email
link to Lotus and so acting as a conduit for freedom of speech, is part
of the solution, and is helping in some small way to protect the privacy and
freedom of all Americans, networked or otherwise... (I was going to include
a digitized version of Battle Hymn of the Republic that would play in the
background as you read this, but I felt it would be an extravagant use of 
bandwidth, and a cheap trick.)

Richard

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

Folks,

I recently forwarded a message about a new Lotus product -- a database
on CDROM of 120M US residents with their estimated incomes and buying
profiles.  Someone questioned whether Lotus is really doing this, so
I checked by calling Lotus and speaking to someone in pre-sales service.

It really is true.  Lotus is still gearing up to sell their "Household
Marketplace" product, and it really does give information on individual
people, not just regional statistical summaries.  I learned the following
(and I asked for literature, so I'll soon know even more):

    1) Yes, it really *DOES* have names and addresses of individuals.

    2) They have divided up the database by regions, and you specify
       the region you are interested in when you buy the product.
       That explains how they could have 120M people in their database
       and still sell you just 1 CD (or a few) for your purchase price.

    3) They also have a "Business Marketplace" CD with data on 7 million
       US businesses.

I forebore yelling at the sales-type who handled my call, merely asking if
there was a place to write with comments about the service.  Apparently
the sales types haven't heard of the controversy the product is raising,
since she replied that several different reports can be generated by the
product, and some of them do have space for comments.

GREAT!  So not only do they have the audacity to print an estimate of your
income (which could be quite damaging if they get it wrong, and is an
intrusion into your privacy if they get it right), they also have space
on the disk for arbitrary comments about you -- and they'll be selling
this data in volume to mass marketing companies across the country!

In interviews, Lotus has said that individuals will NOT be able to correct
their own entries, or even see what they are.  I didn't try to confirm
this in my call to Lotus, but I did confirm that the person who reported
it -- Rich Salz of BBN -- has an excellent reputation on the internet.
Also, everything he said that I checked with Lotus is absolutely accurate.
Further, the Wall Street Journal has reported on it -- saying that the
database has ages, marital status, and other such personal data as well.

So I believe it, and you should to, since it is going to affect your life.
Remember -- a database of 120 million US residents comes to almost half
the people in the country.  Considering that the database is probably
biased toward those with higher incomes, the chances are *really good*
that anyone able to electronically read this message is in the database.

What can you do about it?  A couple of things.  Lotus has said that they'll
omit from their database anyone who asks.  Therefore, start by writing to
the address below.  Tell them that you don't want to be in the database,
and tell them exactly what you think of their database.  I've appended a
copy of my letter to Lotus for an example.

Second, pass this message along to anyone whom you think might care.  To
me, this is not just a matter of privacy.  Lotus is going to sell information
behind our backs -- we are not allowed to dispute their data or even know
what it is.  Worse, Lotus is going to sell rumors about our income.  Still
worse, they will do it on a scale never before achieved.  This should not
be tolerated.  Please help to stop Lotus.

     Thanks,
     Larry Seiler


Write to:
      Lotus Development Corp.
      Attn:  Market Name Referral Service
      55 Cambridge Parkway
      Cambridge, MA 02142


Here's my letter.  Also send copies of your letter to the president and the
CEO of Lotus, if you want to let those at the highest levels know that you
are displeased with their product.  I've also appended a net copy of the
Wall Street Journal artical about it.


                                                198 Linden Street
                                                Boylston, MA 01505
                                                December 6, 1990

     Lotus Development Corp.
     Attn:  Market Name Referral Service
     55 Cambridge Parkway
     Cambridge, MA 02142


     Dear Marketeers,

          I do not want my name included in your "Household Marketplace"
     CDROM database, nor that of anyone in my family, at any address I have
     ever lived at.  To be specific, please make sure that the following
     entries are **NOT** included in your database:

        any last name (especially Seiler, Schmidt, Poffenberger, or Zwerner)
        at 198 Linden Street, Boylston MA

        any Seiler family name
        at 53 Oak Street, Waltham MA

        any Seiler family name
        at 77 Reed Road, Hudson MA


          As you have it set up, I think your "Household Marketplace" CDROM
     database is an incredible intrusion and ought to be illegal.  I am a
     computer professional, so this opinion is not based on any native
     dislike of computers or databases.  The problems I have with your
     proposed service involve the way in which you plan to administer it,
     the way in which the data will almost certainly be used, the type of
     data you are including, and my conviction that you will vigorously
     seek to avoid responsibility for errors in your database.

          First, administration.  I have heard that you are not providing
     any means to correct errors in your database.  The potential for long
     term damage to individuals from use of your database is therefore
     enormous.  Even if an individual knows that your database is false,
     users of your database will almost certainly believe the CDROM data in
     spite of any disclaimers or evidence offered by the individual.

          Second, use of data.  Given the fact that law enforcement
     agencies are nearly powerless to shut down obviously illegal
     boiler-room businesses, it is absurd for you to claim that you will
     only provide the data to legitimate businesses.  You won't be able to
     prevent your product from being used to defraud individuals by huge
     numbers of illegal operations.  One way or another, essentially any
     business who wants your database will be able to get it -- and it will
     be of special value to illegal and borderline businesses.


                                                                Page 2


          Third, type of data.  I understand that you plan to publish
     "income estimates".  There is no legal way for you to verify income,
     unless an individual voluntarily provides that information.  (I never
     do, except when the data is legally required to be held in
     confidence.) It is absolutely unacceptable for you to publish what
     amount to rumors about people's income.  The possibilities for abuse
     are tremendous.

          Fourth, responsibility.  I understand that you will not permit
     individuals to find out what information you are spreading about them.
     The only likely reason for this is that you don't want anyone to find
     out that your information about them is false.  Therefore, while you
     will sell this product on the basis of providing reliable information,
     you aren't prepared to be responsible for the accuracy of your
     information, or for the damage that false information (or even true
     information) might cause.

          So as you see, my concerns about your product are not primarily
     about privacy, although privacy is involved.  If you were prepared to
     take responsibility for the accuracy of your information, then I would
     be willing to accept your service.  For example, you could send copies
     of the data entries to *each* individual in your database, with a
     request to write back if any of the data is incorrect or if they want
     to be removed from your listing.  If you did this, and *made* the
     requested corrections, then I would feel that you were providing a
     positive service, rather than making abusive use of unverified data.

          In conclusion, if you market this product, it is my sincere hope
     that you are sued by every person for whom your data is false, with
     the eventual result that your company goes bankrupt.  That would be a
     pity, since you make many fine products.  However, that is preferable
     to permitting you to spread rumors and encourage abusive business
     practices.  It would be better if your chief officers went to jail,
     but that will apparently require new laws to be passed.  If you
     persist in your plans to market this product, a lot of people will be
     pushing to make that happen.  I suggest that you abandon this project
     while there is time to do so.



                                                Yours most sincerely,




                                                Larry Seiler


 Lotus - New program spurs fears privacy could be undermined
 {The Wall Street Journal, 13-Nov-90, p. B1}
   Privacy advocates are raising the alarm about a new Lotus product that lists
 names, addresses, shopping habits and likely income levels for some 80 million
 U.S. households. Due for release early next year, Lotus Marketplace packs the
 data on palm-sized compact disks aimed at small and mid-sized businesses that
 want to do inexpensive, targeted direct-mail marketing. But critics say the
 product is just too good. "It's going to change the whole ball game," says
 Mary Culnan, an associate professor at Georgetown University's School of
 Business Administration. "This is a big step toward people completely losing
 control of how, and by whom, personal information is used." Janlori Goldman, a
 staff attorney with the American Civil Liberties Union, adds that the product
 raises "serious legal and ethical questions." Lotus' critics concede that the
 product offers little more than is already available from established
 mailing-list brokers. But they say it is a greater potential threat to personal
 privacy because of its low cost, ease of use and lack of effective safeguards
 over who ultimately has access to it and why. They also say that the way it is
 designed allows users to ask a series of increasingly specific questions about
 small subgroups of people - identifying, for example, unmarried, wealthy
 women over 65 in a neighborhood. "They've crossed the line," says Marc
 Rotenberg, Washington director for the nonprofit Computer Professionals for
 Social Responsibility. "It simply shouldn't be allowed on the market." Lotus
 counters that the product, still under development, has been tailored to
 address privacy concerns. No phone numbers will be included, it won't be
 available in retail stores and it will be sold only to "legitimate businesses"
 at verified addresses checked against a "fraud file," Lotus says. A contract
 will specifically limit its use and provide penalties for abuses. Owners will
 be be allowed unlimited use of the names and addresses they buy, at a cost of
 $695 initially for the program plus 5,0000 names and $400 for each additional
 5,000 names.

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 91 06:05:51 GMT
From:      kddlab!titcca!wnoc-tyo-news!hoffman!akira!tana@uunet.uu.net  (Yoshiyuki Tanaka)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Simulations (SUMMARY)

HAPPY NEW YEAR!

Thanks to all who e-mailed information concerning net simulations.
Here's what I've got:

	1) LANSF     menaik.cs.ualberta.ca [129.128.4.241]
			/pub/lansf.2.11c.tar.Z

	2) NEST      columbia.edu [128.59.16.1]
			/nest

	3) REAL      icsi-ftp.berkeley.edu [128.32.201.55]
			pub/tenet/REAL
	             ucbarpa.berkeley.edu   [128.32.130.11]
			pub/REAL/REAL.tar.Z  

	4) sim       allspice.lcs.mit.edu (18.26.0.115)
			pub/netsim
Thanks to:

steve@cs.UAlberta.CA (Steve Sutphen)
mleisher@nmsu.edu    (Mark Leisher)
hrp@pecan.cray.com (Hal Peterson)
lixia@parc.xerox.com  (Lixia Zhang)
miller@jeep.dsg.honeywell.com (Michaeljon Miller)

New information is still welcome.
------------------------------------------------------------------------
 Name:  Yoshiyuki "Yoshi" Tanaka            | Age: 24
 School:Sophia University, Tokyo Japan.     | Sex: Male
 Dept:  Electrical & Electronic Engineering | Workstation: Sparcstation1
 Lab:   Deiters  Laboratory.                | Project: NFS on a DAT
 Email: tana@bob.ee.sophia.ac.jp            | Hobbies:guitars,synth,ski
------------------------------------------------------------------------



--
                                            $B>eCRBg3X(J $BEE5$!&EE;R9)3X2J(J  
$B!I%/%j%9(J$B%^%9$O%[%F%k$8$c$J$/$F652q$G(J...$B!I(J   Robert Deiters $B8&5f<<(J    
                                            $B#M#2(J   $BEDCf4n9T(J            
                                            tana@bob.ee.sophia.ac.jp       
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Thu 3 Jan 91 16:43:26-PST
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        tcp-ip@nic.ddn.mil
Subject:   TCP Spoofing...
"spoofing" usually refers to "faking" an ACK locally, to avoid being
slowed down by long round-trip delays.  In general, this is only useful
in very delay-sensitive protocols (eg those that need an ACK for a packet
before they can send the next packet, like XMODEM, old KERMIT, Novell, etc).
Since TCP already includes sliding windows, it is NOT particularly
delay sensitive, and would not benefit very much from being spoofed.
Spoofing is also difficult since there are things other than the data
transfer that can effect the window/etc...

Header and/or data compression of the packets is a different matter, and
is very useful on slow links (especially when you can compress a 40 byte
TCP header down to 3 bytes or so, ala CSLIP).  For this to be benificial,
you have to do the compression before you go over a slow link (in the PC,
not in the MODEM.)  A modem that compresses TCP headers is not particularly
useful unless the link between the modem is as much faster as the compression
ratio times the comm speed. (90kbps, for CSLIP style compression!)

Even without compression or spoofing, data rates using SLIP are not so
bad.  We WOULD benefit from as little as packet recognition in modems
so that line turn-around type events don't occur until the actual end
of packets.  What SLIP users usually complain about is echo-response
(in telnet), as opposed to ACK-response.  If anyone thinks that a modem
can do an adequate job of spoofing actual data, I'd invite them to
apply their talents to gambling or market research... :-)

BillW
-------
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 91 12:10:57 GMT
From:      zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!news.cs.indiana.edu!noose.ecn.purdue.edu!mentor.cc.purdue.edu!dls@tut.cis.ohio-state.edu  (David L Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sockets, TLI, or what

	Oh, please!

	Please put "System V" or "AT&T" somewhere around that "UNIX". Let's
not forget that Berkeley UNIX, using the socket interface they invented, had
TCP/IP support while AT&T still proudly proclaimed that they had "networking"
support, meaning UUCP.
	For the only UNIX that's been a real player in internetworking for the
last, what, 8 years?, sockets are the "native" interface and TLI support is
something you add so you can deal with the latecomers.
	In a TCP/IP news group, which one has really earned the right to be
called "UNIX," unadorned? :-)
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 91 13:04:18 GMT
From:      virtech!scum@uunet.uu.net  (Steven C. Monroe)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sockets, TLI, or what
ljm@TWG.COM writes:

>>
>>If you are concerned with portability (and the original poster was), you
>>can't ignore TLI and streams.  It is the socket interface that will be
>>going away (but not for a *long* time...).
>>	

>I usually find the most useful way to explain the relationship of TLI
>and sockets is to consider TLI the 'native' transport interface for
>UNIX and sockets is more of a cross-platform API.

In my one rather feeble attempt to deal with TLI showed me some that there
are some deficiencies (IMHO) that need to be addressed. This project was
attempted because the vendor supplied more than one other vendors Ethernet
TCP/IP package.  The TLI provides NO support functions to map a system
target (UUCP?, Ethernet?, SLIP?) with an addressing facility (X.500 will
supply this?).  So I ended up having to know about what the "real"
bottom layer was in order to build the sockaddr structures to get the 
call made.

>So, if you are absolutely sure that your application will only
>run on one of them, or if your application absolutely requires the improved
>functionallity only present in the native interface, then use it.

>Otherwise, use the sockets API as it will ease the port of your application
>to different platforms (or even same platform/different vendor in the DOS
>and OS/2 cases).

As far as I'm concerned, I'll use sockets until all of the facilities that
I need are available.  I don't have the time or resources to build my own
version of X.500, especially when they exist is the socket library.

>enjoy,
>leo j mclaughlin iii
>The Wollongong Group
>ljm@twg.com
-- 
Steven C. Monroe           (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!scum                              46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 91 17:31:12 GMT
From:      van-bc!seac!wain@ucbvax.Berkeley.EDU  (Wain Dobson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: More routing question information
In article <3882@stl.stc.co.uk> dww@stl.stc.co.uk (David Wright) writes:
>In the referenced article tneff@bfmny0.BFM.COM (Tom Neff) writes:
>#In article <PCG.90Dec31145142@teachk.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>
>I am sorry to so denigrate the views of another member of the net: it is
>not my usual way.   But Piercarlo has confused so many arguements with his
>distorted view of the world that I consider it necessary to warn others.
>
Thanks David, think most readers saw through the polemics. I guess what
I'm wondering, is whether you ever won any of the arguments. :-)

-- 
Wain Dobson, Vancouver, B.C.
	...!{uunet,ubc-cs}!van-bc!seac!wain
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 91 20:12:42 GMT
From:      swrinde!elroy.jpl.nasa.gov!usc!ucselx!mccurdy@ucsd.edu  (mccurdy m)
To:        tcp-ip@nic.ddn.mil
Subject:   Cyber FTP problem ...

	A user here has a problem. In using the current version of
FTP on a cyber 830b, and connecting to either a VAX running Multinet
TCP/IP or a PC running NCSA TCP/IP, a situation arises when transferring
an ascii file - after 32000 bytes of a file are transferred, the sub-
sequent records in the file are bestowed with an extra blank character
in before each beginning character in the record. Anyone actually using
FTP on Cybers out there? Thank you in advance ...


-mike mccurdy

-- 
Mike McCurdy               *  mccurdy@ucselx.sdsu.edu *
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 91 20:36:57 GMT
From:      portal!cup.portal.com!cec@apple.com  (Cerafin E Castillo)
To:        tcp-ip@nic.ddn.mil
Subject:   TELEBIT  & Dial-up IP Spoofing...

The on-going discussion in regards to spoofing of dial-up IP protocols
such as SLIP/CSLIP/PPP seems to be missing a couple of points.

I agree that SOMETHING has to be done to improve the performance of
dial-up IP over modems.  V.32 with V.42/V.42bis offered some hope,
but I would like to see what V.32 extended (V.32bis ??) will have
to offer at 14.4 kbps.  The faster modulation will definitely be of
some help, but I believe that above high-speed modems and built-in
intelligence, such as spoofing, is user friendliness.

I have set-up numerous dial-up IP connections using standalone workstations,
PCs, MACs, terminal servers, etc., in combination with modems.  The proper
installation and configuration of the system and modem was never quite
'straight forward'.  When there wasn't problems with modifying the kernel
and compiling the executable in OS versions that had not been previously
tested with the Internet-available code; there was a disappointing 
performance pay-off (ie CSLIP over SunOS 4.0.X/4.1 STREAMS).
 
I am about to do my first 'customer' Telebit NetBlazer installation.
After having tested this product, while at Telebit, I am confident that it
will be one of the easiest products I will have installed with modems for
the use of dial-up IP.  One problem remains:  SLIP/CSLIP/PPP on the remote
user system.  My customer is dealing with UNIX systems that can only perform
SLIP at the moment, and not CSLIP.  DOS PCs are also to be used.  While some
'shrink wrapped' commercial SLIP/CSLIP and PPP applications available,
such products and UNIX systems support has been slow in coming from the
current user systems manufacturers.  This is were I am back to installing,
configuring, and documenting the use of cu/tip/ifconfig/slattach/route/netstat
and the myriad of configuration files that go with these commands, KA9Q
for SLIP/CSLIP/PPP, AND the use of the modems; for home users who want
nothing more than to get their work done.  These people can not count on their
Sys Admin to be at hand for any support problems they may encounter after
hours at home.  Software is still needed for easier installation and 
implementation of dial-up IP WAN solutions on UNIX and non-UNIX systems.

Rather than spoof dial-up IP protocols, I would agree with the idea of a
modem which can speak IP datagrams (packets).  Van Jacobson had once
spoken to me about such a product, while I was with Telebit.  I have to
agree that a device that would sit on a bus of some sort and do DMA to
feed-in IP Datagrams would provide a faster interface for dial-up IP.
A synchronous RS-232 interface to a packet modem would also work quite well.
But, once again, software would still be needed to allow this device to
not only work on a UNIX system, but also non-UNIX systems, terminals
servers, routers, etc..

Please add this to the current discussion's 'wish list'!

===============================================================================
Cerafin E. Castillo                       ||      //\\  ||\\  ||
Network Consultant                        ||     //__\\ || \\ ||  Los Altos
Los Altos Networks                        ||    // ---\\||  \\||  Networks
340 Second St. #6                         ||___//      \ |   \ |
Los Altos, CA  94022
(415) 941-8031      UUCP:     {apple,sun,uunet}!portal!cup.portal.com!cec
                INTERNET:     cec@cup.portal.com

                      "...No hay mal que por bien no venga..."
===============================================================================
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 91 21:06:00 GMT
From:      TAYBENGH@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   firewall?


Hi,
        Could somebody explain to me what actually the "firewall" means?
Please forgive me if abuse this net to ask this simple question.
        Thanks a lot.

- Beng Hang (email: taybengh@nusdiscs.bitnet)

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 91 22:12:58 GMT
From:      jrich@ucrmath.ucr.edu (john richardson)
To:        comp.sys.dec.micro,comp.protocols.tcp-ip
Subject:   TCP/IP driver for PDP-11

An acquaintance lacking Internet access is looking for
a TCP/IP driver for a PDP-11 running RSX-11M
for a EXOS 8030.  Is there such a beast?
You may reply to me (by email please, I don't normally read these
groups) or directly to Sam Hiller at (714) 682-6767
or (714) 736-5026.

Many Thanks.

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 91 22:57:57 GMT
From:      stjohns@umd5.umd.edu  (Mike St. Johns)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: ICMP HOST_UNREACH Param: 1777
Step 1:  Throw away the mil-std.

Step 2:  Get a copy of RFC1122

The mil-std is hopelessly out of date - there was a concious decision
by the PSSG (DCA's Protocol Standards Steering Group) not to update
the standard as bugs were found.  This was mainly due to wanting to
emphasize the use of GOSIP.

Mike
-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 91 23:40:57 GMT
From:      logicon.com!tots!tep@nosc.mil  (Tom Perrine)
To:        tcp-ip@nic.ddn.mil
Subject:   To Subnet or not to subnet?

I am in the process of migrating our local Ethernet and Appletalk
networks into a coherent whole. The nets are currently not connected
to each other or to the Internet. (We are looking at a CERFnet
connection within 18 months, however.)

A long time ago, these nets were set up by various departments who
all knew that they were the only network we would ever have, and in
many cases used the network numbers that were the defaults, or used in
setup examples. (YECH!)

My plan is to have a single "backbone" which runs through all of our
buildings, with each "local" net attached to the backbone via a router
or a host acting as a gateway. (I know that a host acting as a gateway
is not efficient, but this is the hardware I have today.)

I already have four "local" nets identified, this number will probably
grow to about eight in the next 2 years. The largest local net has 12
hosts. It and one other net could easily grow to 20+ in the next two
years.

I have a single class-C network number assigned from the NIC.

Should I:

	1. subnet my already-registered class-C net?

	2. ask the NIC for four more class-C nets (for the local nets)
	and use the registered net for the backbone? (And register new
	nets as I need them?)

How scarce a resource are class-C net numbers?

Trying to be a good net-neighbor,
Tom Perrine (tep)                       |Internet: tep@tots.Logicon.COM
Logicon                                 |UUCP: sun!suntan!tots!tep
Tactical and Training Systems Division  |
San Diego CA                            |GENIE: T.PERRINE
"Harried: with preschoolers"            |+1 619 455 1330
-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 91 00:41:03 GMT
From:      swrinde!cs.utexas.edu!ut-emx!emx.utexas.edu!mclay@ucsd.edu  (Robert McLay)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Summary: PPP and/or SL/IP between SparcStations via v.42bis modems
In article <9101011904.AA20885@ucbvax.Berkeley.EDU> aaron@UX.ACS.UMN.EDU writes:

   Path: ut-emx!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!UX.ACS.UMN.EDU!aaron
   From: aaron@UX.ACS.UMN.EDU
   Newsgroups: comp.protocols.tcp-ip
   Date: 1 Jan 91 19:03:58 GMT
   Sender: daemon@ucbvax.BERKELEY.EDU
   Lines: 21


   Well, I tried (on a Sun3/160 running SunOS 4.1) both the
   omnigate.clarkson.edu:pub/sun/ppp.tar.Z and the
   tut.cis.ohio-state.edu:pub/ppp/* (with the patches applied)
   but I consistently got

           ppp: ioctl(I_PUSH, ppp_async): Invalid argument

   (then quited to system prompt) for nearly all invocations of ppp.

   I tripple-checked that the kernel has been modified as directed,
   and the mod seemed successful (at least ppp0 thru ppp5 exist if
   I pre-attach them in the config file).  I also changed the
   _sys_types_h to __sys_types_h in <pixrect/pr_impl_util.h> as
   Greg suggested. No luck and same error.

   Any kind souls out there willing to give me some hints?

   Thanks and cheers for the happy new year.
   /aaron.cheung
   aaron@ux.acs.umn.edu


I know the solution to this problem.   The problem is that the
instruction fail to tell you that you need:

#include "ppp.h"

in /usr/sys/sun/str_conf.c

R. McLay
mclay@wilbur.ae.utexas.edu
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Jan 91 13:06 H
From:      <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   firewall?

Hi,
        Could somebody explain to me what actually the "firewall" means?
Please forgive me if abuse this net to ask this simple question.
        Thanks a lot.

- Beng Hang (email: taybengh@nusdiscs.bitnet)
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 91 02:39:55 GMT
From:      timbuk!cs.umn.edu!mermaid!lindner@uunet.uu.net  (Paul Lindner)
To:        tcp-ip@nic.ddn.mil
Subject:   Proposed spec for Standard Calendar Managers
As part of my job duties I recently wrote a specification for a
Calendar/Appointment Manager that uses the client-server model.  I
sent a note off to Jon Postel, and he referred me to rdhobby@ucdavis.
He read my specification and thought it was neat. 

He told me I should organize an IETF working group to flesh out the
protocol.  However he's probably quite busy, I haven't heard from him
in a few days, so.......... I've taken it upon myself to set up a
working group.  I don't have a charter or any other mumbo-jumbo, but I
have set up the following mail-aliases for discussions relating to the
topic, they are:

  chronos@boombox.micro.umn.edu         --General discussion
  chronos-request@boombox.micro.umn.edu --Add/Delete from the list (me)

If anyone is interested in standardizing calendar/appointment managers
please get in contact with me via the above list.  Basically the
intent of this protocol is to steer users at our university away from
PROFS systems.

If there is any interest I'll post the draft specification here. (It's
pretty long).
--
Paul Lindner, Univ. of MN   \ Microcomputer / Peace Sells...... But who's
IT Sun dude, & UofM ACM pres \ Workstation / buying? -- Megadeth.
lindner@boombox.micro.umn.edu \ Networks  / {...!rutgers!umn-cs!lindner}
     |   |  |  |  | | | | |||||\ Center  /||||| | | | |  |  |  |   |
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 91 03:47:33 GMT
From:      kddlab!titcca!wnoc-tyo-news!hoffman!akira!tana@uunet.uu.net  (Yoshiyuki Tanaka)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Simulations (SUMMARY)

First of all, I am very sorry if I messed up your terminal with a 
Japanese signature in my previous post. This is a repost.

Thanks to all who e-mailed information concerning net simulations.
Here's what I've got:

	1) LANSF     menaik.cs.ualberta.ca [129.128.4.241]
			/pub/lansf.2.11c.tar.Z

	2) NEST      columbia.edu [128.59.16.1]
			/nest

	3) REAL      icsi-ftp.berkeley.edu [128.32.201.55]
			pub/tenet/REAL
	             ucbarpa.berkeley.edu   [128.32.130.11]
			pub/REAL/REAL.tar.Z  

	4) sim       allspice.lcs.mit.edu (18.26.0.115)
			pub/netsim
Thanks to:

steve@cs.UAlberta.CA (Steve Sutphen)
mleisher@nmsu.edu    (Mark Leisher)
hrp@pecan.cray.com (Hal Peterson)
lixia@parc.xerox.com  (Lixia Zhang)
miller@jeep.dsg.honeywell.com (Michaeljon Miller)

New information is still welcome.
------------------------------------------------------------------------
 Name:  Yoshiyuki "Yoshi" Tanaka            | Age: 24
 School:Sophia University, Tokyo Japan.     | Sex: Male
 Dept:  Electrical & Electronic Engineering | Workstation: Sparcstation1
 Lab:   Deiters  Laboratory.                | Project: NFS on a DAT
 Email: tana@bob.ee.sophia.ac.jp            | Hobbies:guitars,synth,ski
------------------------------------------------------------------------
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 91 05:28:22 GMT
From:      sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: firewall?
In article <9101031150.AA08506@ucbvax.Berkeley.EDU>
TAYBENGH@NUSDISCS.BITNET writes:
+---------------
| Hi, Could somebody explain to me what actually the "firewall" means?
+---------------

In the architecture of buildings (and automobiles), a "firewall" is
a wall (or partition) which is specially constructed to resist the
spread of fire throughout the structure. This is especially helpful
in buildings which are divided into offices by rather flimsy partitions.
Properly located firewalls can reduce the overall damage to the building
during a conflagaration. For a firewall to be effective, and openings
in it (such as doorways or corridors) such be automatically sealed in
the case of fire (such closures are often called "fire doors").

In automobiles, the "firewall" is the partition between the passenger
compartment and the engine compartment, which in the case of a crash
(hopefully) separates the passengers from a possible subsequent fire.

In networking, a "firewall" is a boundary (gateway or host) between two
networks which has been specially constructed or configured to resist
the inadvertent leakage of undesired traffic from one network to another,
thus (hopefully) protecting less-robust systems which lie behind the
firewall.

A typical configuration is to have but a single host which is actually
"on the Internet". That host is also connected to your internal network,
but the networking software is configured to disallow logins *through*
the firewall host. Instead, internal users log onto the firewall, and
from there FTP (or whatever) out into the Internet, later copying the
results back into the internal network. No IP packets actually traverse
the firewall (i.e., "IP forwarding" is disabled.)

Other configurations are possible. Another popular one is to have a
gateway (router) with some form of "filtering" on IP packets, so that
connections are allowed through the firewall only to selected, (hopefully)
robust hosts, and then only to selected destination ports (services).

Like any other security procedure, a "firewall" is only as strong as its
weakest component. Nevertheless, many people feel more confident about
focussing their protection efforts in one place than in trying to protect
hundreds of different hosts of a variety of manufacturers (and with a
variety of configurations). As the saying goes, "Go ahead and put all
your eggs in one basket... THEN WATCH THAT BASKET!"


-Rob

-----
Rob Warnock, MS-9U/515		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Jan 1991 16:37:12 CST
From:      JAFFE@SSCVX1.SSC.GOV
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for Network Simulation Packages...

I am looking for information on network simulation software to model different
network designs ranging from Ethernet to FDDI to SONET.  Both "pay for" and
public domain packages are of interest and any related war stories would be
appreciated.

We are preparing to evaluate a product from AT&T and I would be interested in
hearing from anyone who has worked with their stuff.

Thanks in advance.

Mike Jaffe
Superconducting Super Collider Laboratory

jaffe@sscvx1.ssc.gov
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Fri 4 Jan 91 19:57:33-EST
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        BILLW@mathom.cisco.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Spoofing...
Since Reliability (sometimes known as Robustness) is at least a
and more likely THE design imperative of TCP, it's a quite severe
understatement merely to say that TCP wouldn't benefit from fake
(pre-fabricated relative to the destination) ACKs.

cheers, map

P.S.  The extreme undesirability of tampering with the end-to-end
acknowledgement of correctly received data is one of the major in-
principle objections to "translating/mapping gateways", b/t/w.
-------
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 91 16:58:04 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!usc!jarthur!nntp-server.caltech.edu!quotron.com!todd@ucsd.edu  (Todd_Booth)
To:        tcp-ip@nic.ddn.mil
Subject:   Programmer doc for BSD reno release
I've taken a quick look at the recent BSD reno tcp/ip source (wuarchive.wustl.edu, 128.252.135.4, /unix/4.3bsd-reno/...).  Is there any programmer doc that explains the directory structure, ...?

Thanks, --todd

todd@quotron.com 213 302-4368
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Jan 91 03:42:18 -0600
From:      tjs@msc.edu (Tim Salo)
To:        BILLW@mathom.cisco.com, padlipsky@a.is.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  TCP Spoofing...
"Spoofing", (generating an acknowledgement locally rather than allowing
the remote host to generate it), generally [i.e., probably universally]
implies an obligation for the local device to assume responsibility for
the reliable transmission of the data to the remote host.

This has several results:

o    The local device must understand more about the protocol(s) than if
     spoofing did not occur.  In the case of TCP/IP, the local device
     must understand TCP as well as IP.  (A TCP router?)

o    Various end cases don't work particularly well, (i.e., not at all).
     For example, if the local device acks some data and the line then
     goes down, the local device is unlikely to meet its implied obligation
     to reliably transport the acknowledged data to the remote host.
     Stated differently, don't use spoofing for ATM (the financial
     type) transations.

Tim Salo
Minnesota Supercomputer Center
tjs@msc.edu
(612) 626-0347

P.S. Spoofing is probably also useful when resources other than window 
space are important.  For instance, spoofing can minimize the local host's
need for buffer space devoted to unacknowledged transmitted data and the
receive host's buffer space devoted to reassembly queues.  

P.P.S Spoofing may also help on high-bandwidth, long-propagation-delay, 
links (e.g., statellite links) where the window may close prior to
filling the link. 

P.P.P.S This rather interesting topic quickly leads to a discussion of the
merits of connectionless protocols ("smart host, dumb network")
protocols versus connection-oriented protocols, ("dumb host, smart network" 
protocols).  ["Elements of Networking Style" not withstanding.]

> From: William "Chops" Westfield <BILLW@mathom.cisco.com>
> Subject: TCP Spoofing...
> 
> "spoofing" usually refers to "faking" an ACK locally, to avoid being
> slowed down by long round-trip delays.  In general, this is only useful
> in very delay-sensitive protocols (eg those that need an ACK for a packet
> before they can send the next packet, like XMODEM, old KERMIT, Novell, etc).
> Since TCP already includes sliding windows, it is NOT particularly
> delay sensitive, and would not benefit very much from being spoofed.
> Spoofing is also difficult since there are things other than the data
> transfer that can effect the window/etc...
> 	[...]

> From: Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
> Subject: Re: TCP Spoofing...
> 
> Since Reliability (sometimes known as Robustness) is at least a
> and more likely THE design imperative of TCP, it's a quite severe
> understatement merely to say that TCP wouldn't benefit from fake
> (pre-fabricated relative to the destination) ACKs.
> 
> cheers, map
> 
> P.S.  The extreme undesirability of tampering with the end-to-end
> acknowledgement of correctly received data is one of the major in-
> principle objections to "translating/mapping gateways", b/t/w.
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 91 17:59:52 GMT
From:      midway!midway!chas@handies.ucar.edu  (Charles Blair)
To:        tcp-ip@nic.ddn.mil
Subject:   Printing with ftp

To print data quickly from a remote unix host on a local PC printer, I
ftp to the PC, which is running an FTP server, then "put file prn."
The file then prints locally. (This method works fine ftp'ing among
PCs as well.) I've tried this the other way, ftp'ing to the remote
host, then "put file /dev/ttyb." I get illegible output, in ascii or
image mode.  lpr works fine, either from the remote host, or from the
PC to the remote printer, which has the remote host defined as the
print server.

The printer is an HP Lasjerjet 1. Here is the printcap entry:

|printer|localprinter:\
	:lp=/dev/ttyb:br#9600:\
	:ms=-parity:sd=/var/spool/lpd:\
	:lf=/var/adm/lpd-errs:

Where should I be looking for the source of the problem? Is it with
ftp, my printcap entry, the printer, or some interaction among them?

Thanks. (E-mail preferred.)
--
Bitnet:                 pmrcjdb@uchimvs1
Internet:       cjdb@midway.uchicago.edu
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 91 18:19:29 GMT
From:      timbuk!shamash!awm@uunet.uu.net  (Allan Magnuson)
To:        tcp-ip@nic.ddn.mil
Subject:   56Kbps International IP connection
We are trying to set up a 56K bps line from the US to Europe connecting a WAN of
SGI workstations (UNIX, tcp/ip).  It would be nice to have a little expert advice
from someone who has been there.  A mail on what hardware and software you would
recommended would really be nice.

Thanks,
Eric Swildens
awm@shamash.cdc.com (Still using Al's account :-) )
-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 91 19:40:58 GMT
From:      aaron@hkco.ahkcus.org (Aaron Y.T. Cheung)
To:        comp.protocols.tcp-ip
Subject:   T1 (1.544Mbps) International IP connection [poll]

Survey on International T1 International Connections
----------------------------------------------------

Just at the same momement I was trying to send off a poll on
international T1 (and similar) Internet connections (and was
wondering if this is the right newsgroup to send the poll to), I
saw Allan's article surveying 56K bps international connections!

So, I'd appreciate your dropping me a line about International T1
Internet connections you happened to know of and/or in charge of.
There is a few of them as far as I know. It'd be nice if you also
include the hardware (router/gateway types) and link level protocols
(cisco proprietary? ppp? etc.) used.

I'll summarize to comp.protocols.tcp-ip.

Btw, it was "rumored" that Hong Kong Telecom has verbally agreed to
donate (whatever it means) a free T1 Hongkong-Japan link (which at
today's satellite channel price-tag would cost some HK$400,000 or
US$50,000 per month, and that's only half circult) to Hong Kong
University of Science & Technology, to link up Hong Kong's academia
to the Internet.  Don't know if it's gonna materialize, but looks
like the "T1 Trend" is taking momemtum -- and I'm surprised that
HK Telecom (previously the British Cable & Wireless) can do
something bravo like that... :-)

cheers,
/aaron.

cc: soc.culture.hongkong; & for schk'ers: the data transfer rate of
    a T1 circuit is 1.544 megabits per second; the current HK-USA
    bitnet link is 2400 bits per second (!).

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 91 22:42:15 GMT
From:      usc!sdd.hp.com!uakari.primate.wisc.edu!aplcen!wb3ffv!fallst!tkevans@ucsd.edu  (Tim Evans)
To:        tcp-ip@nic.ddn.mil
Subject:   Getting 4.2BSD to Understand Subnetted Network
I'm adding 4 VAX 11/750's with *binary-only* 4.2BSD licenses
(previously running on an XNS network) to a TCP/IP
network.  The network is a Class B network, with a 255.255.255.0
netmask.  4.2BSD seems not to understand subnetting, so the
first such machine on the net sees only itself and a few
others (386's with an older TCP/IP) which also don't understand
subnetting.

What can be done with 4.2BSD to make things work?

PLEASE NOTE:  As indicated above, we do not have source for
4.2BSD.  (Long story, not appropriate here.)

Thank you.
-- 
UUCP:		{rutgers|ames|uunet}!mimsy!woodb!fallst!tkevans
INTERNET:	tkevans%fallst@wb3ffv.ampr.org
Tim Evans	2201 Brookhaven Ct, Fallston, MD 21047
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 91 22:44:03 GMT
From:      eru!hagbard!sunic!kth.se!perand@bloom-beacon.mit.edu  (Per Andersson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Question about mapping between Ethernet Address & Internet Address
In article <F50A697A19BF00372E@UDLAPVMS.PUE.UDLAP.MX> IGOR@UDLAPVMS.PUE.UDLAP.MX ("Igor Martinez ", GymKata) writes:
>I'm using NCSA telnet (PC Version), but I want that NCSA do something
>like a one-to-one mapping between Ethernet address and Internet address

Could you clarify this a bit please ?
To me it is not at all clear what you are trying to achieve.

-- 
Per Andersson (perand@admin.kth.se, perand@stacken.kth.se)
Trying a new job at Bofors Electronics,
still reading news at the Royal Institute of Technology
Time, got the time tick tick tickin' in my head - Joe Jackson
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 91 05:47:00 GMT
From:      timbuk!cs.umn.edu!lindner@uunet.uu.net  (Paul Lindner)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Proposed spec for Standard Calendar Managers
Whoa boy!  There has been quite a response.  So I've made the
draft specification available via anonymous ftp on the host
boombox.micro.umn.edu in the directory /pub/ietf.

Also, if you want to join the discussion of this protocol, send
mail to chronos-request@boombox.micro.umn.edu.

Thanks!
-- 
Paul Lindner, Univ. of MN   \ Microcomputer /  Pauls Law: You can't
IT Sun dude, & UofM ACM pres \ Workstation / fall off the floor.
lindner@boombox.micro.umn.edu \ Networks  / {...!rutgers!umn-cs!lindner}
     |   |  |  |  | | | | |||||\ Center  /||||| | | | |  |  |  |   |
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 91 16:45:16 GMT
From:      mstar!mstar.morningstar.com!bob@uunet.uu.net  (Bob Sutterfield)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Getting 4.2BSD to Understand Subnetted Network
In article <1873@fallst.UUCP> tkevans@fallst.UUCP (Tim Evans) writes:
   What can be done with 4.2BSD to make [subnets] work?

Euthanasia? :-)

Proxy ARP can fool old IP implementations into dealing with modern
networks.  Get tut.cis.ohio-state.edu:pub/proxyarp/proxyarpd.shar.Z
and run it on something nearby that already knows about subnetting.
-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Jan 91 00:54 GMT
From:      Bob Stine <0004219666@mcimail.com>
To:        Tim Evans <tkevans%fallst@wb3ffv.ampr.org>
Cc:        tcp-ip <tcp-ip@nic.ddn.mil>
Subject:   Re: Getting 4.2BSD to Understand Subnetted Network
>I'm adding 4 VAX 11/750's with *binary-only* 4.2BSD licenses
>(previously running on an XNS network) to a TCP/IP
>network.  The network is a Class B network, with a 255.255.255.0
>netmask.  4.2BSD seems not to understand subnetting, so the
>first such machine on the net sees only itself and a few
>others (386's with an older TCP/IP) which also don't understand
>subnetting.

>What can be done with 4.2BSD to make things work?

If your gateways can do proxy arp, then you could tell the 4.2 hosts that
they are attached to a net with mask 255.255.0.0.  Proxy arp (a.k.a. "the
arp hack," "promiscuous arp") is generally considered to be a kludge, however.

Otherwise, you could install host routes for all the hosts on remote subnets
with which the 4.2 needs to communicate.

Failing these workarounds, I think that you are wedged, although I will be
watching this space with interest.

- Bob Stine
  bstine@MCIMail.com

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Jan 1991 10:01:03 PST
From:      Ole J. Jacobsen <ole@csli.stanford.edu>
To:        ietf@venera.isi.edu, tcp-ip@sri-nic.arpa
Subject:   January ConneXions
The January issue of ConneXions--The Interoperability Report is now
available. This is a special issue on Inter-domain routing, and is
a companion to our August 1989 issue on Intra-domain routing. The
articles are all written by routing experts from the IETF, and 
include an overview of Policy routing, The Border Gateway Protocol,
Issues in Inter-domain routing, and Inter-domain routing in the Internet.

Also included is a summary of RFC 1174 (you know, the one about
"Sponsoring Agency" and "connected/ not connected" which seems to
have since been reversed, oh well...)  and a review of Comer's
second edition of "Internetworking with TCP/IP".

Ask me about subscribing.

Ole

Ole J Jacobsen, Editor & Publisher ConneXions--The Interoperability Report 
Interop, Inc., 480 San Antonio Road, Suite 100, Mountain View, CA 94040, USA
Phone: (415) 941-3399  FAX: (415) 949-1779  Email: ole@csli.stanford.edu
-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 91 04:11:43 GMT
From:      portal!cup.portal.com!thinman@apple.com  (Lance C Norskog)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: More routing question information
Mr. Grandi used an oddity of the English language called a 'synecdoche'.
This is a reference to an object by naming a part of that object, c.f.
a "field hand" or "deck hand".  UseNet refers to the bulletin board
system itself, he was talking about the larger UUCP/Internet web.

Other than that, he uses the words correctly and gets the legalities
correctly too.  Pay attention!  The Internet is being used as a "commons",
as in "The Tragedy of the Commons".  UUCP->Internet->UUCP is an abuse
if it's not government-sponsored research, or you're not designing bombs :-)

Synecdoche is your new word for the day.  Pronounce the 'ch' 'sh'.
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 91 07:01:45 GMT
From:      ogicse!milton!cpac.washington.edu!pjt@ucsd.edu  (Larry Setlow)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: More routing question information
In article <37629@cup.portal.com> thinman@cup.portal.com (Lance C Norskog) writes:
   Synecdoche is your new word for the day.  Pronounce the 'ch' 'sh'.

[email bounced.  Think of this as my inappropriate post for the month]

Better still, prounounce the 'ch' as 'k' and the 'e' as 'ee'.  Four
syllables, stress on the second.
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 91 19:55:07 GMT
From:      comp.vuw.ac.nz!cc-server4.massey.ac.nz!G.Eustace@uunet.uu.net  (Glen Eustace)
To:        tcp-ip@nic.ddn.mil
Subject:   Setting up BootP/TFTP servers and their clients ?
Hi,

We are about to venture into the unknown once again and I am hoping
that those that have already been their can help us steer clear of
the obvious pitfalls.

We have about 150 PCs that are currently running PC-NFS.  I have been
evaluating a bootrom ( ex. Germany ) which I am happy with.  The rom
code uses BOOTP to find a boot host and the appropriate download file
and the TFTP to actually retrieve it.

We currently have a Class B network with no routers.  The machines on
the net are servered by a Pyramid 9815 and 4 DECStation 3100s.  I
have one group of 50 PCs + DECStation in a lab situation.  This group
is on the other side of a bridge.

My questions are related to the boot process.

1.  Should all of the servers be setup to run Bootp and have copies
    of all the boot images?  Every client being defined in each
    bootptab file ?

2.  Should all servers be setup but each only know about a group of
    clients ?

3.  How about just using a single server to download all clients ?

The behaviour in the labs is such that most of the machines will
probably attempt a network boot on (or about) the hour.  I am hoping
to set things up such that the network load is minimised but the
probability of a successful boot is high.

Any suggestions would be much appreciated.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Glen Eustace, Software Manager, Computer Centre, Massey University,
Palmerston North, New Zealand.        EMail: G.Eustace@massey.ac.nz
Phone: +64 63 69099 x7440, Fax: +64 63 505 607,    Timezone: GMT-12
-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Jan 91 08:25:51 PST
From:      rlg@desktalk.com (Richard L. Gralnik)
To:        tcp-ip@nic.ddn.mil
Subject:   Elements of Network Style
Does anyone know where I can get a copy of "Elements of Network Style" (or is
that Networking ?).

Many people have heard of it, a lot have read it, all who know of it 
recommend it, but no one seems to know where to get it.  If it's out of 
print, and would not violate copyrights, would anyone be willing to get it
xeroxed? I will reimburse you. 

Thanks,

Richard Gralnik
(rlg@desktalk.com)
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 91 11:57:53 PST (Mon)
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        rlg@desktalk.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Elements of Network Style
It's an excellent book, and its author frequently reads this list. I
got my copy at Steacy's bookstore in Palo Alto (CA).
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	FAX: 415 594-1141
-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Mon, 07 Jan 91 16:41:24 PST
From:      jqj@duff.uoregon.edu
To:        TCP-IP@nic.ddn.mil
Subject:   Re: Elements of Network Style

Since Lee styles MAP's "Elements of Network Style" as "thoughtful and
witty", I'd like to reiterate the comments on made on this forum when it
first was published:  I found the book nearly impossible to read because
of the pompous and pretentious style.  Although I agreed in 1985 with MAP
on most technical issues, I was unable to recommend the book.

Anyone who titles a book "The Elements of ... Style" has, I believe, an
obligation to the shade of Will Strunk to omit needless words.  Had MAP
done so, his book would have been the length of a magazine article.
Vigorous writing is concise.  This isn't.

Conclusion:  MAP's preface would have led one to believe that his book was
substantively inflamatory or contentious.  Few readers of this list would
find it so, but many (certainly not all) would find the style unacceptable.
-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Mon, 07 Jan 91 15:00:37 EST
From:      "Lee C. Varian" <LVARIAN@pucc.PRINCETON.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Elements of Network Style
On Mon, 7 Jan 91 08:25:51 PST Richard L. Gralnik said:
>Does anyone know where I can get a copy of "Elements of Network Style" (or is
>that Networking ?).

Richard,  I am not positive that "The Elements of Networking Style" is still
in print, but I think so.  I bought my last (paperback) copy through our
campus bookstore about 2 years ago.  The details:

Padlipsky, M. A., "The Elements of Networking Style and other essays and
animadversions on the art of intercomputer networking", Prentice-Hall
(Englewood Cliffs, NJ), 1985, ISBN 0-13-268129-3, 0-13-268111-0 (paper).

A thoughtful and witty book, with chapter titles like "Slaying the 'TCP-on-
a-LAN' Woozle" and with most chapters starting with Prefatory Afterthoughts.
A classic defense of the ARPANET Reference Model against the onslaught of
the ISO Reference Model.
  Lee Varian, Princeton University, lvarian@pucc.princeton.edu
-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 91 10:28:13 GMT
From:      bfmny0!tneff@uunet.uu.net  (Tom Neff)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: More routing question information
In article <37629@cup.portal.com> thinman@cup.portal.com (Lance C Norskog) writes:
>Mr. Grandi used an oddity of the English language called a 'synecdoche'.

Even if he had, synecdoche has no proper place in a technical discussion
about which networks should interconnect.  The part cannot be casually
substituted for the whole, or vice versa, when the very meat of the
argument concerns inappropriate routing through parts and wholes.

>The Internet is being used as a "commons",
>as in "The Tragedy of the Commons".  UUCP->Internet->UUCP is an abuse
>if it's not government-sponsored research, or you're not designing bombs :-)

First of all, there is a distinction between simple misuse of an
apparently free resource, versus the specific economic paradox embodied
in the "Tragedy of the Commons."  In the latter (Commons) case, it was
explicitly in each user's interest to maximize his (quite permissible)
use of the resource, in order that he not suffer competitively with
other users; the end result being destruction of the resource for all.
But in the Internet case, (a) there is no underlying right to use it as
a third party mail carrier in the first place; (b) given the
availability of non-Internet ways for many sites to get mail delivered
(high speed modems make UUCP much more attractive, for instance), users
are not compelled to keep using the Internet resource forever even as
quality of service degrades with increased usage.  They can switch to
something else.  So the much-overused Commons model fits poorly.  What
we really have is a modified black market, where the Man could
theoretically lower the boom any day but doesn't, and where the door is
always open for someone to come in and offer better service for a
cheaper price -- but while the quasi-illicit resource is out there for
the taking and not yet overwhelmed, only a few (like UUNET and PSI)
will bother.

Finally, there is not much hard data available on the extent of Internet
misuse.  What misuse does occur is only partly intentional; some of it
is a by-product of inaccurate UUCP mapping, and could be corrected.

>Synecdoche is your new word for the day.  Pronounce the 'ch' 'sh'.

Did you know that the word 'gullible' is not in the dictionary?

(Synecdoche is, of course, pronounced sin-EK-duh-kee.  Pedantry is its
own reward :-) )
-- 
"I'm not sure I've even got the brains to   #:#   Tom Neff
 be President." -- Barry Goldwater, 1964    #:#   tneff@bfmny0.BFM.COM
-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 91 13:15:32 GMT
From:      pdn!tscs!tct!chip@uunet.uu.net  (Chip Salzenberg)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: More routing question information
According to thinman@cup.portal.com (Lance C Norskog):
>UUCP->Internet->UUCP is an abuse if it's not government-sponsored research,
>or you're not designing bombs :-)

If so, then why is the DNS so happy to register UUCP-only sites?  Not
that I'm complaining about the DNS, but it seems inconsistent.
-- 
Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
       "If Usenet exists, then what is its mailing address?"  -- me
             "c/o The Daily Planet, Metropolis."  -- Jeff Daiell
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jan 91 00:45:58 -0600
From:      tjs@msc.edu (Tim Salo)
To:        PADLIPSKY@A.ISI.EDU
Cc:        BILLW@mathom.cisco.com, tcp-ip@nic.ddn.mil
Subject:   Re:  TCP Spoofing...
> Date: Tue 8 Jan 91 00:27:13-EST
> From: Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
> Subject: Re:  TCP Spoofing...
> [...]
> In a strictly construed TCP context, intermediate systems CAN'T assume
> responsibility for correct delivery.  Indeed, some pushy purist once
> complained to me that even an "outboard" TCP protocol interpreter
> violated the spirit of end-to-endness inherent in the protocol.  I of
> course replied that a proper outboard TCP PI wouldn't send the
> ACK until it had been assured through its Host-Front End Protocol that
> the counterpart process had indeed received the data (and yes, the
> explicit or implicit link protocol of the H-FP IS expected to guarantee
> the correctness of the data between the PI and the process)....
> [...]

You are correct in identifying the issue, (in spite of my language), 
as the distribution of function between a host and front-end processor 
(or modem, etc.).

Some interesting commentary on putting applications in a host and TCP 
in a front-end processor is Dave Clark's discussion of "fate-sharing" 
in "The Design Philosophy of the DARPA Internet Protocols" at SIGCOMM '88.  
At the risk of over simplification, "fate-sharing" is an implementation 
strategy, (putting both functions on the same processor), which ensures 
that the application and the end-to-end acknowledgement of data (TCP) do 
not die independently.  This strategy obviates the need to develop 
algorithms to deal with TCP loosing its internal state while the application 
continues.  Many spoofing implementations ignore this case.

Note that some protocols allow the host to specify whether acknowledgements
have local or end-to-end significance, (c.f., the X.25 "D" bit).

I suspect that discussions of whether the customer should be allowed to 
determine the significance of TCP acknowledgements (allow spoofing) or
whether only protocol gurus can make this decision (disallow spoofing)
falls into the realm of religion.  (I vote to let the customer decide.)

Tim Salo
tjs@msc.edu
(612) 626-0347

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 91 17:35:54 GMT
From:      att!watmath!watserv1!utgpu!utzoo!henry@ucbvax.Berkeley.EDU  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: To Subnet or not to subnet?
In article <207@tots.UUCP> tep@tots.UUCP (Tom Perrine) writes:
>How scarce a resource are class-C net numbers?

Not very.  But routing-table slots to point to them are a bit more costly,
depending on who's doing your routing and how close they are to any fixed
limits in their software :-(.  In the long run, it would probably be best
for you to get a class-B network number -- sometimes easier said than done,
alas -- and subnet it.
-- 
If the Space Shuttle was the answer,   | Henry Spencer at U of Toronto Zoology
what was the question?                 |  henry@zoo.toronto.edu   utzoo!henry
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 91 18:06:34 GMT
From:      otter.hpl.hp.com!hpopd!ajp@hplabs.hpl.hp.com  (Andy Pearce)
To:        tcp-ip@nic.ddn.mil
Subject:   rfi: VMS network products
Hi,

I have microVAX 3200 running VMS v5.0 (to be updated) and I'd
like to connect it to our lan.  I believe our lan is IEEE 802.3
standard connecting HP clusters and peripherals.  I'm told I'll
need a TCP/IP implementation running on VMS - products suggested
so far:

   Wollongong
   TGV Multinet
   NCR Fusion
   Novell (Excelan) Lan Service & FTP for VMS

Anyone used these products for connecting VAX/VMS to UNIX or HPUX 
machines?  Any recommendations or otherwise would be much appreciated.

Eventually I'd like to be able to get programmatic control of VMS
processes driven from a unix box, so I'd be interested in knowing
about any limitations of the above products, or any other products
suggested.  I guess a complete implementation of ARPA/Berkeley
services would be ideal.

Please mail to ajp@hpsesuka.pwd.hp.com or respond here if you think its
of general interest.  Apologies if this has been asked a hundred times 
before!

Thanks
--ajp
-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 91 18:07:30 GMT
From:      rstevens@noao.edu  (Rich Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Elements of Network Style
Padlipsky, M. _The Elements of Networking Style_, Prentice Hall, 1985.

I don't see it in their current catalog; the P-H phone order number
used to be 201-767-5049.

	Rich Stevens
-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Tue 8 Jan 91 00:27:13-EST
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        tjs@msc.edu
Cc:        BILLW@mathom.cisco.com, tcp-ip@nic.ddn.mil
Subject:   Re:  TCP Spoofing...
Tim Salo--

Grateful though I am for the passing plug for The Book (gee, four in one
day!), and in agreement though I am with the body of your msg, I fear
I must take issue with the flavor of your postscripts:

In a strictly construed TCP context, intermediate systems CAN'T assume
responsibility for correct delivery.  Indeed, some pushy purist once
complained to me that even an "outboard" TCP protocol interpreter
violated the spirit of end-to-endness inherent in the protocol.  I of
course replied that a proper outboard TCP PI wouldn't send the
ACK until it had been assured through its Host-Front End Protocol that
the counterpart process had indeed received the data (and yes, the
explicit or implicit link protocol of the H-FP IS expected to guarantee
the correctness of the data between the PI and the process)....

So I would maintain that under NO circumstances should TCP ACKs be
"spoofed"--and must admit I'm somewhat surprised Vint Cerf hasn't
hurled any thunderbolts on the topic yet, since (1) it's really his
idea that Robustness is uber alles in TCP, and (2) we (he and I)
once had so strong a disagreement over my view that he was a bit too
fanatic on the topic that I can't imagine he'd expect me to spring to
its defense for him, even if 14.5 years of water have flowed over that
particular dam[n].  (Maybe he's taking a long Solstice break.)

(Almost inconceivable I've wound up to the Right of him on that of
all topics, but, I guess, a logical possibility.)

(Nah, must be on vacation.)

cheers, map
-------
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 91 20:00:37 GMT
From:      LVARIAN@PUCC.PRINCETON.EDU ("Lee C. Varian")
To:        comp.protocols.tcp-ip
Subject:   Re: Elements of Network Style

On Mon, 7 Jan 91 08:25:51 PST Richard L. Gralnik said:
>Does anyone know where I can get a copy of "Elements of Network Style" (or is
>that Networking ?).

Richard,  I am not positive that "The Elements of Networking Style" is still
in print, but I think so.  I bought my last (paperback) copy through our
campus bookstore about 2 years ago.  The details:

Padlipsky, M. A., "The Elements of Networking Style and other essays and
animadversions on the art of intercomputer networking", Prentice-Hall
(Englewood Cliffs, NJ), 1985, ISBN 0-13-268129-3, 0-13-268111-0 (paper).

A thoughtful and witty book, with chapter titles like "Slaying the 'TCP-on-
a-LAN' Woozle" and with most chapters starting with Prefatory Afterthoughts.
A classic defense of the ARPANET Reference Model against the onslaught of
the ISO Reference Model.
  Lee Varian, Princeton University, lvarian@pucc.princeton.edu

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Tue, 08 Jan 91 11:25:14 -0800
From:      lee@erg.sri.com
To:        tcp-ip@nic.ddn.mil
Cc:        lee@erg.sri.com
Subject:   NRC's TCP/IP
All,
I am looking for some information (implementation, performance, etc.) on
  NRC's TCP/IP software.  The software also goes by the name of FUSION.
Can anyone provide some help?
Please send responses directly to me.

Thanks,
Diane
-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jan 91 08:28:10 PST
From:      postel@venera.isi.edu
To:        fmrco!stowe!fxs@uunet.uu.net, tcp-ip@nic.ddn.mil
Cc:        stowe!bguest@uunet.uu.net
Subject:   Re:  sources for RFC on FTP


RFCs can be obtained via FTP from NIC.DDN.MIL, with the pathname
RFC:RFCnnnn.TXT (where "nnnn" refers to the number of the RFC).  Login
with FTP, username "anonymous" and password "guest".

The NIC also provides an automatic mail service for those sites which
cannot use FTP.  Address the request to SERVICE@NIC.DDN.MIL and in the
subject field of the message indicate the RFC number, as in "Subject:
RFC nnnn".

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 91 01:49:19 GMT
From:      logicon.com!tots!tep@nosc.mil  (Tom Perrine)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: To Subnet or not to subnet?
Several days ago I sent a question regarding what to do about a
network number for our growing network. The options I listed were to
	1) subnet my existing class-C
	2) get additional class-C nets

The overwhelming response was choice 3! Of 10 responses, 8 suggested
that I what I really wanted was a class-B net, and most recommended
subnetting the thing as pseudo-class-C nets.

Thanks to all of the network wizards who replied:

dsinc.dsi.com!syd@ucsd.edu (Syd Weinstein)
barns@gateway.mitre.org (Bill Barns)
jnford@handlebar.weeg.uiowa.edu (Jay Ford)
uunet.UU.NET!delmarva!scoggin (John Scoggin)
brian@ucsd.EDU (Brian Kantor)
tecnet1.jcte.jcs.mil!kate
eng.xyplex.com!rlstewart (Bob Stewart)
jstewart@ccs.carleton.ca (John Stewart)
uunet.UU.NET!ccci!tcs (Terry Slattery)
henry@zoo.toronto.edu (Henry Spencer)

Tom Perrine (tep)                       |Internet: tep@tots.Logicon.COM
Logicon                                 |UUCP: sun!suntan!tots!tep
Tactical and Training Systems Division  |
San Diego CA                            |GENIE: T.PERRINE
"Harried: with preschoolers"            |+1 619 455 1330
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jan 91 10:01:49 PST
From:      rlg@desktalk.com (Richard L. Gralnik)
To:        tcp-ip@nic.ddn.mil
Subject:   Elements of Networking Style
Well, in for a penny, in for a pound.  

Many thanks to all who responded to my RFI on Michael Padlipsky's book 
(including Mr. Padlipsky).  The book received decidedly mixed reviews. 
Nevertheless, I am curious to check it out for myself if only out of 
historical/cultural interest. 

The story from Prentice-Hall - (800) 223-2336, don't be fooled when they 
answer the phone "Simon & Schuster" -  is that the book costs $31.50.  
It is currently on back order, and has been since April 1990.  

I will probably call UCLA's used bookstore (note to MAP if you see this - 
my company is located in Torrance and is connected via ISI. Howdy neighbor!)
to see if they have a copy available.

Thanks again,

Richard Gralnik
(rlg@desktalk.com)
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jan 91 12:06:31 -0600
From:      Eliezer Dekel <dekel@utdallas.edu>
To:        TCP-IP%NIC.DDN.MIL@vm.utdallas.edu
Subject:   Re:  papers on computer networking courses
A friend from another university asked me what
he needs to do in order to join the distribution
list of TheoryNet. Can you send me the instructions?
Thanks
Eliezer.
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jan 91 11:03:30 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: can ONE single sendto() send all 8K data in Sun UDP-based RPC?
On 4bsd Unix, if you write 8K to a UDP socket (through RPC or otherwise), you
will generate an 8K + 8 byte UDP datagram.  This will in turn generate an
8K + 28 byte IP datagram, which will get carved up into N IP fragments because
the MAC layer won't be able to send it intact.  4bsd doesn't treat this as
an error.  Some other UDP implementations do.

Many people (myself included) would suggest that, if you need to move large
amounts of data using RPC, you use TCP as the transport layer instead of
UDP.  At one stroke, you get retransmission with backoff, end-to-end data
integrity checking, congestion avoidance, and little or no IP fragmentation.
This will make you many friends if your application runs over WANs (e.g.
the Internet).

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

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jan 91 08:40:29 EST
From:      fmrco!stowe!fxs@uunet.UU.NET (Fran Sullivan)
To:        tcp-ip@nic.ddn.mil
Cc:        stowe!bguest@uunet.UU.NET
Subject:   sources for RFC on FTP

One of our programmers is looking for some rfc on FTP.
We connect through UUNET, and usually they have most of
what we need. (but not the following) :

> 1)    rfc765
> 2)    rfc697
> 3)    rfc691
> 4)    rfc640
> 5)    rfc542
> 
Does anybnody have any idea where these RFCs live ?

Thanks for your time.

                                               |\/\/\/|
* Fran Sullivan                                |      |
* fmrco!fxs@uunet.uu.net                       |      |
* Unix Tech Support                            | (o) (o)
* Fidelity Information Systems                 C      _)   ...Hey Dude!
* Boston, MA    02109                           |  `__|     
* ( 617 ) 570-2762                              |   /   
                                               /    \
                                              / ---- \ 
-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 91 06:12:02 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!lavaca.uh.edu!davison@ucsd.edu  (Dan Davison)
To:        tcp-ip@nic.ddn.mil
Subject:   What happened to the IETF "NOCTOOLS" report?
I just went looking on nnsc.nsf.net and nic.ddn.mil for the IETF draft
report on network tools, formerly known as draft-ietf-noctools-
debugging.X, where X was a variety of things (-05.ps, for example).

It's not there!  If you know where it is, have a copy that I could
FTP, or clues as to where to look, I would appreciate it very much if
you would drop me a line.

Thanks very much,

dan davison
--
dr. dan davison/dept. of biochemical and biophysical sciences/univ. of
Houston/4800 Calhoun/Houston,TX 77054-5500/davison@uh.edu/DAVISON@UHOU
Disclaimer: As always, I speak only for myself, and, usually, only to
myself.
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jan 91 13:32:20 EST
From:      fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca
To:        tcp-ip@nic.ddn.mil
Subject:   LPR for Macintosh
I would like to know if there is a public-domain or commercial version
of the LPR client which runs in the Macintosh Multifinder environment
(using MacTCP).

Thanks!
________________________
Bob Fillmore, Systems Software & Communications     BITNET:  FILLMORE@EMRCAN
  Computer Services Centre,                         BIX:     bfillmore
  Energy, Mines, & Resources Canada                 Voice:   (613) 992-2832
  588 Booth St., Ottawa, Ontario, Canada  K1A 0E4   FAX:     (613) 996-2953
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jan 91 18:20:11 EST
From:      enger@seka.scc.com (Robert M. Enger)
To:        sdd.hp.com!zaphod.mps.ohio-state.edu!lavaca.uh.edu!davison@ucsd.edu, tcp-ip@nic.ddn.mil
Cc:        davison@uh.edu
Subject:   Re:  What happened to the IETF "NOCTOOLS" report?


The NOCtools catalog graduated to being RFC 1147.

The catalog is being maintained by Robert Stine (bstine@mcimail.com).

Best wishes,
Bob Enger
-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Tue 8 Jan 91 20:36:51-EST
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        tjs@msc.edu
Cc:        BILLW@mathom.cisco.com, tcp-ip@nic.ddn.mil
Subject:   Re:  TCP Spoofing...
In religious terms, letting "the customer decide" where ACKs come from
IN THE TCP CONTEXT is tantamount to letting the parishoner decide whether
the "nots" belong in the Commandments.  Unlike Ekstwennifie's "D" bit,
the meaning of the TCP ACK is not defined to be voluntary ... and IS
defined to have end-to-end/process-to-process significance.

Much as I hate to find myself cast in the role of a strict constructionist
--especially while enjoying a pseudosabbatical--I just don't buy the
notion that defining characteristics of protocols are subject to re-
construction by non-designers.  It's not customers vs. gurus that's at
issue, it's denotation vs. solecism.

cheers, map
-------
-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 91 15:43:58 GMT
From:      cscnj!paul@rutgers.edu  (Paul Moody)
To:        tcp-ip@nic.ddn.mil
Subject:   PPP on STREAMS

Does anyone know of an implementation of PPP or SLIP for STREAMS?
Preferably for ATT 386. Even more preferably with source.

Thanks in advance

Paul Moody
-- 
Paul Moody			UUCP: rutgers!cscnj!paul 
Computer Sciences Corporation	PHONE: (908)562-6529
# the opinions expressed are entirely imaginary			#
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 91 16:14:59 GMT
From:      sdd.hp.com!mips!batman!robishaw@ucsd.edu  (Gary Robishaw - Loral Rolm Mil-Spec)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: sources for RFC on FTP
For copies of RFCs, all you need to do is send mail (with a null body) to:

service@sri-nic.arpa

put the RFC number in the subject line e.g. 

subject:RFC951

Good luck,

Gary
-- 
Gary Robishaw          "Every man takes the limits of his own field of vision 
robishaw@mips.com       for the limits of the world." 
408/432-5960                             Arthur Schopenhauer
Usnail -- 3151 Zanker Rd. San Jose, Ca. 95134-1928
-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Tue 8 Jan 91 21:20:09-EST
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        jqj@duff.uoregon.edu
Cc:        TCP-IP@nic.ddn.mil
Subject:   Re: Elements of Network Style
jqj--

You are, of course, entitled to dislike my prose style.  As They say,
"There's no accounting for lack of taste."  However, your appeal to
the late Professor Strunk is doubly a non sequitur.  In the first place,
I was playing on _The Elements of Programming Style_, and turn out to
be eminently entitled to do so, for reasons Brian might explain to you if
you ask him nicely.  In the more significant place, though:

The whole duty of a writer is to please and satisfy himself, and the
true writer always plays to an audience of one. [_The Elements of Style_,
p. 85--which is, as it happens, the last page, if memory serves]

But, then, perhaps that sentiment was engrafted by Mr. White....

natheless, cheers,
     map
-------
-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 91 16:21:34 GMT
From:      usc!zaphod.mps.ohio-state.edu!mips!batman!robishaw@ucsd.edu  (Gary Robishaw - Loral Rolm Mil-Spec)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: sources for RFC on FTP
Sorry about the re-post, but I forgot to mention that mail to 
service@sri-nic.arpa with a valid RFC number in the subject line
will result in return mail the following day. You will be sent the
RFCs you requested.

Whew!

Gary
-- 
Gary Robishaw          "Every man takes the limits of his own field of vision 
robishaw@mips.com       for the limits of the world." 
408/432-5960                             Arthur Schopenhauer
Usnail -- 3151 Zanker Rd. San Jose, Ca. 95134-1928
-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 91 16:43:48 GMT
From:      usc!wuarchive!rex!samsung!interlan.InterLan.COM!interlan.interlan.com!scanlon@ucsd.edu  (Mike Scanlon)
To:        tcp-ip@nic.ddn.mil
Subject:   new Spanning Tree
If there's another more appropriate place for this please let me know, but:

Has anyone tried updating a MAC layer bridge's spanning tree code to the 
current rev (p802.1d/D9 July 14,1989).  Apparently this rev and the
previous rev are not compatible.  We are currently running the previous
rev on our product and I'm trying to plan for the upgrade, but I'm not sure
what the scope of the effort will be at this point.  

If anyone has performed this operation and has any insight I would be most
grateful.
			Thanks in advance,

			Mike Scanlon
			scanlon@interlan.com
-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 91 17:31:04 GMT
From:      visix!news@uunet.uu.net  (Amanda Walker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: More routing question information
In article <27887475.65E6@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes:
> If so, then why is the DNS so happy to register UUCP-only sites?  Not
> that I'm complaining about the DNS, but it seems inconsistent.

DNS visibility has nothing to do with Internet connectivity as such.
In fact, the DNS and IP network number applications make it quite
clear that actual Internet connectivity is a separate issue that must
be approved by the appropriate agencies.

--
Amanda Walker
Visix Software Inc.
-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 91 18:06:31 GMT
From:      dekel@UTDALLAS.EDU (Eliezer Dekel)
To:        comp.protocols.tcp-ip
Subject:   Re:  papers on computer networking courses

A friend from another university asked me what
he needs to do in order to join the distribution
list of TheoryNet. Can you send me the instructions?
Thanks
Eliezer.

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 91 18:12:42 GMT
From:      sdd.hp.com!think.com!barmar@ucsd.edu  (Barry Margolin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  TCP Spoofing...
In article <9101080645.AA05302@uh.msc.umn.edu> tjs@MSC.EDU (Tim Salo) writes:
>You are correct in identifying the issue, (in spite of my language), 
>as the distribution of function between a host and front-end processor 
>(or modem, etc.).

Actually, I think spoofing and network front-end issues are only slightly
related.  If acknowledgements are sent by a TCP front-end, this would
presumably be the *receiving* host's front-end.  The receiving host and its
front-end are pretty intimate with each other, so it's almost reasonable to
think of the front-end as a component of the host, in which case such
behavior might be excused.

Spoofing, however, might be done by a device at any link in the route, and
presumably by a *sending* modem (spoofing is normally done by a device that
is sending across a slow medium).  There's no strong connection between the
spoofer and the final receiving host, so it's very difficult to conceive of
a way in which they might conspire to guarantee that all data acked by the
spoofer will eventually be delivered.

As has been mentioned before, the successful spoofing algorithms take
advantage of the knowledge that the protocols above certain transport
protocols are constrained, and that these upper-layer protocols incorporate
their own acknowledgements.  For instance, UUCP g protocol is used only by
UUCP, and it has file-level acknowledgements.  The set of protocols that
use TCP as a transport are virtually unlimited, and many of them take
advantage of TCP's guarantee of correct delivery.

A TCP spoofer *might* be able to get away with it if it peeked at the TCP
ports as well, and determined that the packet is part of a protocol with a
higher-level acknowledgement.  For instance, it might not be too bad to
spoof FTP data connection acks, since the end of the file is indicated by a
FIN handshake (the hard part of spoofing FTP data connections is
recognizing them, as this requires peeking at the FTP control connection to
see the PORT command).

So, there might be some limited cases where TCP could be spoofed.  However,
I think the effort required to identify them and implement a reasonably
reliable spoofer would be better spent elsewhere.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 91 18:12:52 GMT
From:      msieweke@hayes.uucp
To:        comp.os.vms,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   need: lpr daemon for Wollongong TCP/IP

We are running Wollongong TCP/IP on our VAXes and we need to print from
our Suns onto our VAX printers.  Does anyone know of an lpr daemon for
Wollongong?  This seems like it would be a common request.  Public domain
or commercial is OK.

Please post or e-mail and I will summarize.  Thanks in advance.
-- 
Mike Sieweke                            ...!uunet!hayes!msieweke
Hayes Microcomputer Products            msieweke@hayes.uucp
Norcross, Georgia                       hayes!msieweke@uunet.uu.net

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Jan 91 04:20:56 -0600
From:      mni@techops.cray.com (Michael Nittmann)
To:        eru!hagbard!sunic!news.funet.fi!funic!santra!news@bloom-beacon.mit.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  TCP window size restriction
Happy someone pointed out here that tcp/ip is limited to
64kB/sec  transfer speed! I always doubted my numbers here for
xfer speeds. Thanks a lot for the enlightment, Antti!

Michael





--------------------------
This NEEDS a disclaimer: this is my PRIVATE, own opinion!
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 91 21:23:08 GMT
From:      nmrdc1!rdc30med@mimsy.umd.edu  (LCDR Michael E. Dobson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: More routing question information
In article <27887475.65E6@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>According to thinman@cup.portal.com (Lance C Norskog):
>>UUCP->Internet->UUCP is an abuse if it's not government-sponsored research,
>>or you're not designing bombs :-)
>
>If so, then why is the DNS so happy to register UUCP-only sites?  Not
>that I'm complaining about the DNS, but it seems inconsistent.

Perhaps to allow Internet sites to send mail to them by only having to
specify user@site.dom.ain ?  It sure makes life easier for me and my users.
I can use the UUCP maps for one of my MUAs (ELM), but not the one used by
the majority of my users, and not for the MTAs.  So having MX records for
UUCP sites served by an Internet site is A Good Thing(tm).

I believe most dual sites (I am one) only advertise their UUCP links in the
maps.  I connect to some Internet sites via both SMTP and UUCP, but I only
show the UUCP links.  That way, the maps will only generate a UUCP path
even though I could use the Internet for that hop (by could use I mean in
the technology sense, not the legal sense).
-- 
Mike Dobson, Sys Admin for      | Internet: rdc30med@nmrdc1.nmrdc.nnmc.navy.mil
nmrdc1.nmrdc.nnmc.navy.mil      | UUCP:   ...uunet!mimsy!nmrdc1!rdc30med
AT&T 3B2/600G Sys V R 3.2.2     | BITNET:   dobson@usuhsb or nrd0mxd@vmnmdsc
WIN/TCP for 3B2                 | MCI-Mail: 377-2719 or 0003772719@mcimail.com
-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 91 23:04:14 GMT
From:      usc!zaphod.mps.ohio-state.edu!mips!smsc.sony.com!tin@ucsd.edu  (Tin Le)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PPP on STREAMS
In article <1991Jan8.154358.32@cscnj> paul@cscnj (Paul Moody) writes:
>
>Does anyone know of an implementation of PPP or SLIP for STREAMS?
>Preferably for ATT 386. Even more preferably with source.

  Yes, I have one I found (I think) on ftp.ee.lbl.gov.

$ ls -l ppp*
-rw-r-----   1 tin      eng        98223 Oct 23 23:14 ppp-streams.tar.Z

  You can try getting it yourself if you have ftp.  If not, I can mail
  it to you.  I haven't had time to try it out yet (I am working on SVR4).

-- Tin

-- 
.----------------------------------------------------------------------
. Tin Le                    Work Internet: tin@smsc.Sony.COM
. Sony Microsystems              UUCP: {uunet,mips}!sonyusa!tin
. Work: (408) 944-4157      Home Internet: tin@szebra.uu.net
-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 91 00:57:18 GMT
From:      wang!fitz@uunet.uu.net  (Tom Fitzgerald)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: To Subnet or not to subnet?
henry@zoo.toronto.edu (Henry Spencer) writes:
> In the long run, it would probably be best
> for you to get a class-B network number -- sometimes easier said than done,
> alas -- and subnet it.

Why easier said than done?  Are class B addresses being rationed?

---
Tom Fitzgerald   Wang Labs        fitz@wang.com
1-508-967-5278   Lowell MA, USA   ...!uunet!wang!fitz
-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 91 01:04:42 GMT
From:      uswat!crohrer@boulder.colorado.edu  ( Chris Rohrer #330 x1513 )
To:        tcp-ip@nic.ddn.mil
Subject:   Multiple server contention resolution
I know this is a problem that has been solved many times, many ways, but I
was hoping for some guidance.  The setup is that I have a client machine 
that needs services from any of a number of physically redundant servers
on a CSMA/CD type of LAN; the exact service or services are irrelevant to
the discussion (I think...) except that once a server responds, a session
on that 'connection' will transpire.  The goal is to share usage across
the servers even allowing a server to be taken out of service (or at least
quiesced) transparently to a client base.

I'm looking for a possibly already existing reference to a protocol or 
mechanism that will govern the resolution of multiple responses to a given
request for service that has been broadcast to the multiple servers. 


My questions can be distilled down to something like these:

1) Is a broadcast mechanism a useful way of soliciting a server response?

2) Would a more deterministic method of server selection be better?

3) Are these things available off the shelf?

4) Would I have to give tons more specs to elicit a meaningful netnews
response?

Any help would be greatly appreciated, even advice as to which news groups
would be more appropriate for this type of question.

Thanks,


Chris Rohrer
crohrer@uswest.com
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 91 01:41:00 GMT
From:      TAYBENGH@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   can ONE single sendto() send all 8K data in Sun UDP-based RPC?

Hi netlander,
        I am always puzzled about 8K limitation imposed by Sun UDP-based RPC
implementation. After reading the source code, I realized that the 8K
is actually imposed by RPC itself when creating buffer for XDR_MEM.
However, I wondered is it possible to send all 8K data in ONE single socket
sendto() as shown in Sun RPC source code? As most of the people pointed out,
sendto() NORMALLY can only send 1-2K (implementation dependent) of data.
What if the sendto() can NOT send all 8K data in one single UDP message, will
there be errors like RPC_CANTSEND ?

If I modified the library such that large data is sent using several sendto()
call, will several UDP message generated for each sendto() call? If so,
will the various messages splited from of ONE UDP-RPC call mix with other
UDP-RPC call message (I think it is likely, am I rite?)?

Could anybody please shed some light on me, please? I am deperate to know!
Thanks a lot.

p/s: I corssed post it to some other lists, if u see it more than once,
     please forgive me.

Regards.

- Beng Hang Tay (email: taybengh@nusdiscs.bitnet)

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Jan 91 08:06 EDT
From:      Bill Wine <BIWINE@vaxsar.vassar.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Mac mail systems
Last month I asked the net if the POP3 protocol was appropriate for a
large Mac/PC mail system.  I received some replies to that question,
but I received even more requests such as "if you get some good answers,
please let me know, since we are looking for a mail system, too".  For
that reason, I thought it might be useful to present some basic information
that I have gathered over the last 2 months about public domain Mac-based 
mail systems.  I do not claim to be an expert on this topic.

First, I am aware of 3 pd mail management protocols for which client-server
software is available.  These are POP2, POP3, and IMAP2.  The protocol 
descriptions are available via anonymous ftp from nic.ddn.mil.  
cd to RFC:, first.  POP2 is described in RFC937 (dated 2/85), POP3 in 
RFC1081 (11/88), and IMAP2 in RFC1176 (8/90).

For information on what software is available and where to obtain it, I
suggest an excellent article by Mike Liveright which can be
found in the info-mac digest.  Ftp to sumex-aim.stanford.edu, and get
info-mac/digest/infomacv8-145.txt.  

The following is a summary of the pd mail systems I reviewed:

1. MacMS is an IMAP2 client.  The mail is stored on the host.  This means that
you can read all of your mail no matter where you are.  You could use a  Mac
client, a PC, Unix workstation or terminal.  Also, the backup is done on the
host, so the user is less likely to lose mail.  The client remains logged into
the host (1 host process per client).  A check for newmail is done at a
user-defined time interval.  There is an excellent message selection feature -
search on RFC header (from, subject, date, etc.) and/or body text.  Also, an
easy to use mail reader (close current message and open next).  You can move
selected messages from the current mailbox to another, but only 1 mailbox may
be open at a time.  I did not see a feature to append a file to a mail message. 
User preferences are set in a startup document.  A PC client is available or
will be soon.

2. TechMail is a POP3 client.  Mail is transferred from the inbox on the host
to the client, and deleted on the host (no option to save mail on host). You
can have multiple mailboxes on the client, and transfer mail among them.  More
than 1 mailbox may be open at the same time.  User preferences are easily set
in the program.  There is a built-in finger and directory. The client does not
remain connected to the host.  The client connects to the server, gets newmail,
and disconnects.  The main drawback to this product is that there is no
automatic notification of newmail.  The user must initiate this.  I understand
that newmail notification or automatic check  will be provided in the next
release.  There is a discussion list with an  archive.  Text files may be sent
with mail.  No PC client.

3. Eudora is also a POP3 client, and it is similar in function to TechMail. One
important difference is that Eudora checks for newmail by connecting to the
host at a user-defined time interval.  Setting the time to zero turns off the
check.  Also, Eudora gives the option of saving mail on the host after it is
transferred to the client.  This can be an important backup feature if the
server is modified to move mail to an archive folder, or distinguish between
old mail and new mail.  Eudora supports enclosures of any file type (automatic
binhex conversion).  Supports multiple mailboxes on the client and can sort 
messages based on sender, subject or date.  It also sends commands to a 
nameserver and gets back the results.  No PC client.

4. HyperMail is a POP3 client.  Unlike the 2 POP3 clients described above, it
remains connected to the server, and mail remains on the host.  It sees  only
the inbox folder on the host.  Messages may be saved as individual files on the
client.

5. MacPOP is a POP2 client which requires an enhanced POP2 server.  I did not
check out the difference, but it did not work with a regular POP2 server. The
client remains connected to the host, and the mail remains on the host.  Only
the inbox on the host can be seen.  The POP2 protocol does  provide a folder
command to select a different mailbox on the host, but this product does not
seem to use that feature.  One message at a time can be saved to an individual
text file on the client.  The interesting thing about MacPOP is that it uses an
auxilliary program, POPAlert to provide notification of newmail.  POPAlert is
an init/cdev which listens on a DDP port.  The package includes a modified
comsat program that sends a DDP packet to the client Mac when newmail arrives. 
MacPOP polls a driver to discover the  arrival of the DDP packet, and then
automatically downloads the newmail from the host.  The comsat program looks
for a file in the login directory which contains the zone(s) in which the
user's Mac is likely to be found. This works in a fairly static environment. 
There is also a PC version  which works in a similar way (sends a UDP packet),
but I did not try it.

I have seen suggestions in the Techmail interest group mailing list that
POPAlert and the modified comsat program could be used to provide
asynchronous newmail notification for Techmail until the next release.
This would notify the user with an alert, and the user could then opt to
get the newmail from the host.

Others may argue that it is too difficult (or not worth the trouble)
to provide reliable asynchronous newmail notification in a non-static 
mixed client environment.  The cost (in terms of cpu time) for a POP3
client to connect to a host and check for newmail is very low (with
a fast server, less than 1 second of cpu time).  On the other hand,
the commercial mail systems do provide pop-up notification.

6. POPMail is a POP2 client Hypercard implementation.  It does not remain
connected to the server, and uses an auxiliary program (Nag) to notify the
client when newmail arrives.  Nag polls the host at a pre-determined interval. 
It does not support multiple mailboxes. Messages can be saved on the client as
individual files, or in a  stack archive.

I did not spend a lot of time looking at the 2 Hypercard implementations.

7. MacPost uses a proprietary protocol, and is the only pd system I looked at
that does not require MacTCP on the client.  It's architecture seems closer to
the commercial mail systems, such as QuickMail.  The client Mac communicates
with a dedicated server Mac, which communicates with an SMTP host.  Newmail
notification is provided.  Multiple mailboxes are not supported.  Text file
enclosures only.  Client must be registered with the server.  There is an
interest group mailing list.

The most important step in choosing a Mac-based mail system is deciding 
on the underlying architecture.  Do you want the mail to remain on the
server, or should it be transferred to the client?  Other questions:
Do you need to support PC's as well as Macs?  Will you support MacTCP or 
PC/IP on each client?  Does the implementation support multiple mailboxes 
and enclosures?  Is it generally easy to use?  Is your server well matched
to the number of clients?  

One feature that I did not see in any client is automatic filing of
messages into mailboxes based on user-defined rules (as in some Unix
systems).  This would be nice on systems that transfer mail to the
client.

I hope that this article has been useful to readers looking for a Mac-
based mail system.  I have generally avoided references to ftp sites.
See the info-mac digest article noted above for that information.
The information presented here is based on my use of the software, and
it is not guaranteed to be correct.

Bill Wine
biwine@vassar.edu
-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jan 91 17:41 H
From:      <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   can ONE single sendto() send all 8K data in Sun UDP-based RPC?
Hi netlander,
        I am always puzzled about 8K limitation imposed by Sun UDP-based RPC
implementation. After reading the source code, I realized that the 8K
is actually imposed by RPC itself when creating buffer for XDR_MEM.
However, I wondered is it possible to send all 8K data in ONE single socket
sendto() as shown in Sun RPC source code? As most of the people pointed out,
sendto() NORMALLY can only send 1-2K (implementation dependent) of data.
What if the sendto() can NOT send all 8K data in one single UDP message, will
there be errors like RPC_CANTSEND ?

If I modified the library such that large data is sent using several sendto()
call, will several UDP message generated for each sendto() call? If so,
will the various messages splited from of ONE UDP-RPC call mix with other
UDP-RPC call message (I think it is likely, am I rite?)?

Could anybody please shed some light on me, please? I am deperate to know!
Thanks a lot.

p/s: I corssed post it to some other lists, if u see it more than once,
     please forgive me.

Regards.

- Beng Hang Tay (email: taybengh@nusdiscs.bitnet)


-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 91 07:47:27 GMT
From:      agate!bionet!uwm.edu!mrsvr.UUCP!shaw%gemed.ge.com@ucbvax.Berkeley.EDU  (Tom Shaw ct58 Ex 5084)
To:        tcp-ip@nic.ddn.mil
Subject:   Tcp Slip & PPP
I'm looking for any documentation about TCP SL/Ip and
PPP.  We would be running these over dial-up lines using
Telebit modems from a Sun 4.x OS to a Sun 3.5 OS.  Any 
advice, hints or suggestions on how to do this would be 
appreciated.  Also names of any good books would be a plus
also.

Thanks.

Tom
--
---------------------------------------------------------------------------
Thomas A. Shaw                  | Roman rule:
G.E. Medical Systems            |   The one who says it cannot be done 
16800 West Ryerson Rd NB-920    |   should never interrupt the one who 
New Berlin, WI 53151            |   is doing it.
---------------------------------------------------------------------------
uucp:		{uunet!crdgw1|sun!sunbird}!gemed!shaw
internet:	shawta@gemed.ge.com
internet:       shawta@comet.med.ge.com
---------------------------------------------------------------------------
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 91 10:31:35 GMT
From:      k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
To:        comp.os.vms,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: need: lpr daemon for Wollongong TCP/IP

msieweke@hayes.uucp writes:

>We are running Wollongong TCP/IP on our VAXes and we need to print from
>our Suns onto our VAX printers.  Does anyone know of an lpr daemon for
>Wollongong?  This seems like it would be a common request.  Public domain
>or commercial is OK.

Look into the anonymous ftp-area at ecf.ncsl.nist.gov

The author of the software is Daniel Allen, allen@ecf.ncsl.nist.gov

Sincerely,
Klaus Steinberger

--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende
FAX:   (+49 89)3209 4280        D-8046 Garching, Germany
BITNET: K2@DGABLG5P             Internet: k2@bl.physik.tu-muenchen.de

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Jan 91 18:48:55 PST
From:      rlg@desktalk.com (Richard L. Gralnik)
To:        tcp-ip@nic.ddn.mil
Subject:   An INTERESTING problem
Hi everyone,  

We are trying to make efficient use of a Class B address in a situation where
the standard procedure wastes roughly half the available addresses.  Any
thoughts on our proposed solution(s) or others of your own devising would be
greatly appreciated.

Here is the scenario:

We have a network which resembles a wheel with spokes - central hub of main
processors on a common ethernet, with remote offices scattered around the
area.  The remote offices are to be linked to the central site over serial
lines using routers.

The standard wisdom/procedure is to assign a subnet number to each remote
office, another subnet number to each serial line, and another (or many)
to the central site net.  We want to use an 8-bit subnet mask for the 
obvious reasons, but the cost of this is that the serial lines become 2-node 
subnets, thereby wasting 251 addresses (including 0 and 255) each.  Since 
there are 20 remote sites, and the user wants redundant serial lines because 
the network is mission-critical, we eat up 60+ subnet numbers right off the
bat.  

This is the pilot for a nation-wide company, so the other subnet numbers are
expected to be needed before too long. Also, this operation is growing and
will likely need additional remote offices added later.

We have thought of 3 solutions -

	1.  Use more than 8 bits for the subnet mask.  We don't like the
		administrative problems this creates, plus there is a 
		good chance that later additions to the net will have
		many hosts per subnet, so the additional mask bits will
		not leave enough host address space.

	2.  Use different size subnet masks for the serial lines than for
		the office subnets.  We don't think the routers will like
		this very much.

	3.  Use our Class B network number for the central net and for the 
		remote office nets with the 8-bit subnet mask, and use
		subnetted Class C addresses for the serial lines.  We think
		this will work since all the Class B subnets have the same 
		net number and subnet mask, and since RIP only sends 
		(sub)net numbers and next hop addresses, the updates should
		be accurate.
		
		We think this is very clever, and believe it will work.  
		However, we haven't actually tried it yet...  Also, we
		aren't knowledgeable enough about OSPF, IGRP, etc. to know
		if it will confuse/trash them.  There is also the 
		consideration that a network address space is assumed to be
		physically contiguous, but in this case, the Class B is 
		fragmented, and the Class C is not directly reachable from
		outside the Class B.  On the other hand, since the only 
		nodes using the Class C addresses are the serial interfaces
		of the routers, maybe none of this matters.

What do you think?

Thanks in advance for any input.   I will summarize for the net if we get
some good responses.


Richard Gralnik
(rlg@desktalk.com)
-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 91 13:51:28 GMT
From:      fciva!dag@uunet.uu.net  (Daniel A. Graifer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PPP on STREAMS
In article <1991Jan8.154358.32@cscnj> paul@cscnj (Paul Moody) writes:
>Does anyone know of an implementation of PPP or SLIP for STREAMS?
>Preferably for ATT 386. Even more preferably with source.

If you are talking about paying for a commercial product, I believe Spider
TCP/IP (A British company, I don't have a contact for them because our copy
came bundled w/ our OS & hardware) is STREAMS based, and supports data-link
over X-25 and SLIP, as well as ethernet, and is STREAMS based.

They exhibited at InterOp (great show!), but I think I trashed my exhibitors
list.

Does Wollengong TCP/IP support other data-link layers besides ethernet as
a standard part of the package?

Good luck,
Dan
---
Daniel A. Graifer			Coastal Capital Funding Corp.
Sr. Vice President, Financial Systems	7900 Westpark Dr. Suite A-130
(703)821-3244				McLean, VA  22102
uunet!fciva!dag				fciva.FRANKCAP.COM!dag@uunet.uu.net
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 91 14:29:12 GMT
From:      mstar!mstar.morningstar.com!bob@uunet.uu.net  (Bob Sutterfield)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Spoofing...
In article <9101080645.AA05302@uh.msc.umn.edu> tjs@MSC.EDU (Tim Salo) writes:
   I suspect that discussions of whether the customer should be
   allowed to determine the significance of TCP acknowledgements
   (allow spoofing) or whether only protocol gurus can make this
   decision (disallow spoofing) falls into the realm of religion.  (I
   vote to let the customer decide.)

The customer is welcome to do whatever {s}he likes, and may indeed
invent a very pleasant and workable reliable datastream protocol.
Such a protocol may turn out to be widely liked by the worldwide
networking community, and its inventor lauded as a sage with manifest
vision and wisdom.  It may turn out to be a commercial success,
enabling the inventor to retire in comfort to whatever palm
tree-covered tropical island paradise {s}he might care to purchase.
(Note that this latter seems to be the goal of many religion
inventors.)

But if it can be spoofed (read: doesn't depend upon the sanctity of
end-to-end ACKs), then it's not RFC793 TCP.
-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 91 15:04:58 GMT
From:      albers@ka3ovk.irs.GOV (Jon Albers)
To:        rec.hamradio.packet,comp.protocols.tcpip,comp.sources.wanted,comp.unix.sysv386
Subject:   NOS of SCO UNIX V 3.2

Newsgroups: rec.ham-radio.packet, comp.unix.sysv386, comp.protocols.tcp-ip, comp.sources.wanted
Subject: KA9Q or NOS for SCO UNIX V wanted

I am looking for source code to NOS for SCO UNIX sys V 3.2.  Does anyone have
working source which will compile under this version of SCO UNIX?  I would
prefer it be avaailable via uucp, as I do not have easy ftp access.

								Jon
| Jon Albers, IRS, Information Systems Management, Support and Installation.  |
| Office Symbols: ISM:S:S:SI   voice: (202/FTS)535-3729  Packet: KA3OVK@N4QQ  |
| UUCP:(media|teemc|tcsc3b2|ki4pv)!ka3ovk!albers ARPA: JALBERS@SIMTEL20       |
-- 
| Jon Albers, IRS, Information Systems Management, Support and Installation.  |
| Office Symbols: ISM:S:S:SI   voice: (202/FTS)535-3729  Packet: KA3OVK@N4QQ  |
| UUCP:(media|teemc|tcsc3b2|ki4pv)!ka3ovk!albers ARPA: JALBERS@SIMTEL20       |

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 91 15:38:06 GMT
From:      netcom!jbreeden@apple.com  (John Breeden)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PPP on STREAMS
In article <1991Jan8.154358.32@cscnj> paul@cscnj (Paul Moody) writes:
>
>Does anyone know of an implementation of PPP or SLIP for STREAMS?
>Preferably for ATT 386. Even more preferably with source.
>

AT&T SysV/386 R4's Win/TCP R4 has a SLIP driver (and other goodies).

-- 
 John Robert Breeden, 
 netcom!jbreeden@apple.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden
 -------------------------------------------------------------------
 "The nice thing about standards is that you have so many to choose 
  from. If you don't like any of them, you just wait for next year's 
  model."
-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 91 15:48:32 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!rpi!bu.edu!bu-it.bu.edu!kwe@ucsd.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Subsuming SNA on a connectionless net

	(Please note that this enquiry is posted to three largish
groups.  I suggest we follow-up on only one group, comp.dcom.lans, and
I apologize if you think my posting is too broad.)
--------------------------------------------------------------------

	I understand a couple of major multiprotocol router vendors
will be announcing an ability to operate SNA networks on
connectionless internets in the near future.  I have a morbid
curiousity about how something like this would work, but I understand
little regarding SNA networks.

	I understand that it should be straightforward, after
installing a standard sync line in a multiprotocol router, to create a
tunnel using your favorite internet protocol, and overlay an SNA or
other synchronous network on top of your multiprotocol network.  Lots
of economies of scale there to make router vendors' accountants and
stock analysts everywhere engage in instant Pavlovian responses.

	However, many moons ago I had a distasteful brush with BSC
when I tried out a similar product from a then major (and then
independent) vendor of LAN systems that was supposed to run BSC over a
broadband datagram network.  The product was a spectacular failure,
because they did not spoof enough of the BSC protocol features to
allow BSC to work reliably over an unreliable network.

	It seems to me that it could be quite difficult in practice to
sufficiently spoof, for the purposes of an unreliable datagram net,
BSC or SNA or any other point-to-point protocol that assumes nothing
more than a live wire underneath.  Does anyone know enough about SNA
to know what the pitfalls would be in making it run over a virtual
circuit on a connectionless network?

	[One could imagine all kinds of strange and wonderful things
a protocol designer could do if (s)he could safely assume nothing but
a wire to run it on.  Since we are talking about putting such
protocols on top of *virtual* circuits, my questions revolve around
what has been done in SNA of this nature that would not work well on a
datagram net, and what could an implementor do to satisfy (spoof) SNA
requirements for operating acceptably under these conditions.]

	For example, do SNA lines engage in incessant ENQ/ACK
behaviour?  Is that easy to spoof?  Does SNA assume very tight
response time when it sends data?  Is that easy to spoof?  Are SNA
networks designed and tuned so variously that one cannot assume much
about what one may successfully spoof?

	I would appreciate it if all the inevitable harumphing about
how awful SNA is could be saved for another day.  Thanks.

	--Kent
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 91 16:10:35 GMT
From:      meadows@cslvax.weeg.uiowa.edu
To:        comp.os.vms,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: need: lpr daemon for Wollongong TCP/IP

In article <3719.278a0ba5@hayes.uucp>, msieweke@hayes.uucp writes:
>We are running Wollongong TCP/IP on our VAXes and we need to print from
>our Suns onto our VAX printers.  Does anyone know of an lpr daemon for
>Wollongong?  This seems like it would be a common request.  Public domain
>or commercial is OK.
>
>Please post or e-mail and I will summarize.  Thanks in advance.
>-- 
>Mike Sieweke                            ...!uunet!hayes!msieweke
>Hayes Microcomputer Products            msieweke@hayes.uucp
>Norcross, Georgia                       hayes!msieweke@uunet.uu.net
>
    We are using Wollongong TCP/IP on one of our VAXes, and version 5.1 
of their software includes LPR/LPD functionality. I have not used it to
print to any SUNs, but have successfully printed to other UNIX boxes
such as NeXt and Encore. If you are paying for Wollongong support, they
should send you the 5.1 version update. Contact your TWG sales rep.


***************************************************************************
* Howard Meadows                 Internet : meadows@cslvax.weeg.uiowa.edu *
* Sr. Systems Programmer         BITnet   : meadowva@uiamvs.bitnet        *
* Weeg Computing Center          Phone    : 319-335-5519                  *
* University Of Iowa                                                      *
* Iowa City, Iowa 52242                                                   *
***************************************************************************

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 91 16:26:31 GMT
From:      princeton.edu!tengi@princeton.edu  (Christopher Tengi)
To:        tcp-ip@nic.ddn.mil
Subject:   Running SLIP on HP/Apollo Domain-OS 10.3?
A friend asked me if I had any ideas on how to set up SLIP on
Domain-OS.  I had no ideas, so I thought I would ask all you nice
folks out in net-land.  So, has anybody out there done this?  If so,
please send mail to carpe@deepthought.princeton.edu (or
princeton!deepthought!carpe).

				Thanks in Advance,
						/Chris

==========----------==========---------+---------==========----------==========

	UUCP:	  ...princeton!tengi		VOICEnet: 609-258-6799
	INTERNET: tengi@princeton.edu		FAX:      609-258-3943
	BITNET:	  TENGI@PUCC
-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 91 17:46:04 GMT
From:      usc!cs.utexas.edu!news-server.csri.toronto.edu!utzoo!henry@ucsd.edu  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: To Subnet or not to subnet?
In article <ayylbj.4d@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
>> In the long run, it would probably be best
>> for you to get a class-B network number -- sometimes easier said than done,
>> alas -- and subnet it.
>
>Why easier said than done?  Are class B addresses being rationed?

Not having tried it myself, I can't testify in detail, but my understanding
is that getting a class B can be a fair bit more difficult than getting a
handful of class Cs.
-- 
If the Space Shuttle was the answer,   | Henry Spencer at U of Toronto Zoology
what was the question?                 |  henry@zoo.toronto.edu   utzoo!henry
-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 91 18:01:45 GMT
From:      usc!cs.utexas.edu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!hydroesm!jtsv16!blister!patrick@ucsd.edu  (Patrick Bowman)
To:        tcp-ip@nic.ddn.mil
Subject:   Monitoring Ethernet traffic with a simple Ethernet card
I'm looking for an Ethernet line monitor program that runs on an IBM
PC and works through a standard Ethernet card (3Com, WD, etc.).  I
know that they exist  -  I've spoken to people who claim to have seen
them in operation.  I don't know how they can work, because I thought
all Ethernet cards had hardcoded E-net addresses.  (I have heard it
rumored that some cards can have their E-net address downloaded to
them, but I haven't seen examples of this).  Does anybody know
where I can find such a thing?

The application that I'm looking at is running TCP/IP over Ethernet,
and the ability to interpret TCP/IP packets would be a real
advantage.

Sorry about the cross-posting, I really don't know where this request
is most likely to get answered.
-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 91 19:54:20 GMT
From:      usc!zaphod.mps.ohio-state.edu!mips!smsc.sony.com!tin@ucsd.edu  (Tin "Man" Le)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PPP on STREAMS
>In article <1991Jan8.154358.32@cscnj> paul@cscnj (Paul Moody) writes:
>Does anyone know of an implementation of PPP or SLIP for STREAMS?
>Preferably for ATT 386. Even more preferably with source.

  Previously I mentioned something called ppp-streams.tar.Z that contain
  an implementation of PPP for streams (and BSD/socket).  I made a mistake
  when I said it was available on ftp.ee.lbl.gov (actually that was where
  I found cslip source code, not PPP).

  You can get ppp-streams from UC Davis, ucdavis.ucdavis.edu [128.120.2.1],
  in the directory /dist/ppp.

-- Tin

-- 
.----------------------------------------------------------------------
. Tin Le                    Work Internet: tin@smsc.Sony.COM
. Sony Microsystems              UUCP: {uunet,mips}!sonyusa!tin
. Work: (408) 944-4157      Home Internet: tin@szebra.uu.net
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 91 20:37:15 GMT
From:      usc!samsung!umich!sharkey!nstar!larry@ucsd.edu  (Larry Snyder)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PPP on STREAMS
jbreeden@netcom.UUCP (John Breeden) writes:

>AT&T SysV/386 R4's Win/TCP R4 has a SLIP driver (and other goodies).

how about PPP (compressed headers) SLIP?


-- 
   Larry Snyder, NSTAR Public Access Unix 219-289-0282 (HST/PEP/V.32/v.42bis)
                        regional UUCP mapping coordinator 
  {larry@nstar.rn.com, ..!uunet!nstar!larry, larry%nstar@iuvax.cs.indiana.edu}
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 91 20:51:43 GMT
From:      cis.ohio-state.edu!karl_kleinpaste@tut.cis.ohio-state.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: To Subnet or not to subnet?
henry@zoo.toronto.edu writes:
   Not having tried it myself, I can't testify in detail, but my understanding
   is that getting a class B can be a fair bit more difficult than getting a
   handful of class Cs.

From the NIC's NETINFO:INTERNET-NUMBER-TEMPLATE.TXT:

| 7) Unless a strong and convincing reason is presented, the network (if
| it qualifies at all) will be assigned a class C network number.  If a
| class C network number is not acceptable for your purposes state why.
| (Note: If there are plans for more than a few local networks, and more
| than 100 hosts, you are strongly urged to consider subnetting. [See RFC
| 950])

--karl
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 91 21:52:26 GMT
From:      mcsun!hp4nl!svin02!wzv!wzv.win.tue.nl@uunet.uu.net  (Wietse Venema)
To:        tcp-ip@nic.ddn.mil
Subject:   package to log tcp/ip connections
The following is taken from the blurb of a posting that recently
appeared in the comp.sources.misc newsgroup (volume nr. v16i062):

This package provides a couple of tiny programs that log all requests
to connection-oriented tcp/ip services (examples: FINGER, SYSTAT, FTP,
TELNET, RLOGIN, RSH, EXEC), with optional access control on the basis
of host (or domain) names and service names.

The programs are nothing but small front ends. By default, they just
log the remote host name and then invoke the real daemon. The programs
should not require any changes to existing software or configuration
files.

The optional access-control facility may be useful when, for whatever
reason, it is not possible to handle access control at a more suitable
level (such as an internet router).

	Wietse Venema,
	Eindhoven University of Technology,
	The Netherlands.
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 91 00:00:59 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!mips!smsc.sony.com!tin@ucsd.edu  (Tin "Man" Le)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PPP on STREAMS
In article <1991Jan9.195420.2011@smsc.sony.com> tin@smsc.sony.com (Tin "Man" Le) writes:
>>In article <1991Jan8.154358.32@cscnj> paul@cscnj (Paul Moody) writes:
>>Does anyone know of an implementation of PPP or SLIP for STREAMS?
>>Preferably for ATT 386. Even more preferably with source.
>
>  Previously I mentioned something called ppp-streams.tar.Z that contain
>  an implementation of PPP for streams (and BSD/socket).  I made a mistake
>  when I said it was available on ftp.ee.lbl.gov (actually that was where
>  I found cslip source code, not PPP).
>
>  You can get ppp-streams from UC Davis, ucdavis.ucdavis.edu [128.120.2.1],
>  in the directory /dist/ppp.

  I've been told that the ppp stuffs on ucdavis is for PC only, using
  KA9Q.  Sorry about that.

  One more update.  The response to my posting has been more than I have
  time to handle.  Thanks to Paul Vixie, ppp-streams.tar.Z is now on
  gatekeeper.dec.com (or should be soon).  I've mailed it off to him.
  Just keep checking on there, in /pub/net/ppp*

  One other place to check is tut.cis.ohio-state.edu, in /pub/ppp
  That contain ppp-streams, modified for SunOS 4.1.

-- Tin

-- 
.----------------------------------------------------------------------
. Tin Le                    Work Internet: tin@smsc.Sony.COM
. Sony Microsystems              UUCP: {uunet,mips}!sonyusa!tin
. Work: (408) 944-4157      Home Internet: tin@szebra.uu.net
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 91 04:28:28 GMT
From:      usc!samsung!munnari.oz.au!uniwa!johng@ucsd.edu  (John Gibbins)
To:        tcp-ip@nic.ddn.mil
Subject:   Installing PPP questions and problems
After reading the article by Bob Sutterfield (bob@MorningStar.Com) about
PPP I thought I would try it out as a potential alternative to my slip
lines.  I pulled off the release from tut.cis.ohio-state.edu and
proceeded to build.  

1) When building, the make depend failed because slcompress defines
BCOPY which has already been defined by machine/param.h (via
sys/param.h) because I am on a 3/260 running 4.1.  Greg Earle
(earle@poseur.JPL.NASA.GOV) said he had run it on a 3/260 also running
4.1.  (Did you have this problem Greg?)
The simple solution would seem to be to just #undef BCOPY before the
#define BCOPY in slcompress.c.  Does this seem reasonable?

2) Greg mentioned that the test for __sys_types_h in
<pixrect/pr_impl_util.h> is wrong.  I agree, but I haven't been able to
connect this with ppp.c.  From the name, "pixrect" sounds like it is
part of sunview.  If so, why should it have anything to do with data
comms (especially as I don't even have a graphics monitor!).

3) Are there any other things I should watch for during the installation
like adding #include "ppp.h" to str_conf.c (thanks to Robert McLay et al
for that warning)?

Thanks to Bob and Greg for their articles so far which have helped me
get this far.  Any extra info always appreciated.

John Gibbins
Western Australian Research Institute for Child Health
University of W.A.
johng@uniwa.uwa.oz.au
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 91 04:57:34 GMT
From:      aaron@hkco.ahkcus.org (Aaron Y.T. Cheung)
To:        comp.protocols.tcp-ip
Subject:   Re: Installing PPP questions and problems

In article <1991Jan10.042828.29389@uniwa.uwa.oz> johng@uniwa.uwa.oz (John
Gibbins) writes:

| 1) When building, the make depend failed because slcompress defines
| BCOPY ...

Same thing encountered here (on a 3/160 running 4.1) but not much of a problem.

| 2) Greg mentioned that the test for __sys_types_h in
| <pixrect/pr_impl_util.h> is wrong.  I agree, but I haven't been able to
| connect this with ppp.c.  From the name, "pixrect" sounds like it is
| part of sunview.  If so, why should it have anything to do with data
| comms (especially as I don't even have a graphics monitor!).

For those who didn't have /usr/include/pixrect installed,
then instead of patch2's suggestion of

        + #ifdef sun
        + /*
        +  *    Get definition of SUNOS
        +  */
        + #include <pixrect/pr_impl_util.h>
        + #endif
        +

you could replace the above lines by (assuming you're using SunOS 4.1):

	#define	SUNOS	41

(ie, put it before the line #include "magic.h" in ppp.c.)


/ac.

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 91 07:26:30 GMT
From:      eru!hagbard!sunic!lth.se!newsuser@bloom-beacon.mit.edu  (Ricard Wolf)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Monitoring Ethernet traffic with a simple Ethernet card
In article <1991Jan9.180145.2211@blister.Solbourne.COM> patrick@blister.Solbourne.COM (Patrick Bowman) writes:
>I'm looking for an Ethernet line monitor program that runs on an IBM
>PC and works through a standard Ethernet card (3Com, WD, etc.).  I
>know that they exist  -  I've spoken to people who claim to have seen
>them in operation.  I don't know how they can work, because I thought
(2)
>all Ethernet cards had hardcoded E-net addresses.  (I have heard it
>rumored that some cards can have their E-net address downloaded to
>them, but I haven't seen examples of this).  Does anybody know
>where I can find such a thing?
(1)
>

1) FTP software have a package called LanWatch, witch monitors and
   disassembles network traffic.
2) True, there is usually a TTL PROM on the E-net card containing the node
   address, but:
   a) This usually has to be downloaded to the Ethernet controller chip
      by the network software.
   b) Most E-net controllers can be set in so-called promiscuous mode, in
      which theyreceive all packets from the net, regardless of their
      address.
-- 
Ricard Wolf

+--------------------------+-------------------------------------+
| Ricard Wolf              | Lund Institute of Technology        |
| email: e85rw@efd.lth.se  | If you can't buy 'em - build 'em !! |
+--------------------------+-------------------------------------+
-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jan 91 13:35:33 EST
From:      Michael A. Patton <MAP@lcs.mit.edu>
To:        rlg@desktalk.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   An INTERESTING problem
You were almost clever enough...

   Date: Wed, 9 Jan 91 18:48:55 PST
   From: rlg@desktalk.com (Richard L. Gralnik)

   We have a network which resembles a wheel with spokes

Actually your later description sounds like spokes, but no wheel.
Given the critical nature you describe later you may want to consider
interconnecting the ends of the spokes to actually create a "wheel".
There are many cases where single failures can take out multiple lines
and at least having the ability to route all around the outside means
only one of the spokes into the hub needs to be operational for
connectivity to exist everywhere (of course, that one link will get
quite loaded).

   We have thought of 3 solutions -

But you missed a fourth that is probably the one you want...

	   1.  Use more than 8 bits for the subnet mask.

I agree with your reasons against this one.

	   2.  Use different size subnet masks

This is very iffy.  Exactly what you can accomplish with variable
subnets depends on what vendors equipment you are using.  There may be
restrictions that prevent use in this application.  It may be very
hard to get right if you want to allow for competitive sourcing of the
equipment you use.

	   3.  Use our Class B network number for the central net and for the 
		   remote office nets with the 8-bit subnet mask, and use
		   subnetted Class C addresses for the serial lines.

		   We think this is very clever

I agree it seems clever, but it doesn't work...  However there is
something that does (and is related).  This doesn't work because of
the contiguous network assumption.  You may find some vendors
implementation that happens to operate the way you want today, but
since the specs imply networks are contiguous, this may not continue
to be available.

However, most vendors of IP routers will let you run the serial line
between two routers as an unnumbered subnet.  Even if it's not
directly supported, this is easy to simulate (see below).  This
feature is intended to address problems just such as yours.  The main
disadvantage is that you cannot address these unnumbered ports
directly (say to ping them), but with SNMP you still get the
information so this may not be a problem at all.  This will eliminate
all the waste of addresses for these lines.

If your vendor doesn't support this (or for some reason you don't want
to rely on that support), there is a simple way to simulate it.  All
you do is allocate one subnet of your class B address and use it for
all the serial lines.  That's right, you just made a discontiguous
subnet.  The only reason a discontiguous subnet is a problem is
that you don't know how to route to it but, as described before, you
don't need to address the serial line side!  I have, in fact, tested
this configuration, by accident, and found it to work fine.  The way
to accidentally get this configuration is with a spine subnet that
partitions in such a way that the parts still work, and the two
partitions are interconnected through some back door.  In your case,
you could think of all the serial ports being on one super-subnet that
just happens to be broken into partitions of size 2.  There are some
minor complications if multiples of these "partitions" need to feed
into a single router, but a little thought can generally configure a
setup for this case.

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

Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 91 09:39:15 GMT
From:      eru!hagbard!sunic!sics.se!uplog.uppsala.telesoft.se!uplog.uppsala.telesoft.se!thomas@bloom-beacon.mit.edu  (Thomas Tornblom)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP window size restriction
In article <9101091020.AA08870@techops.cray.com> mni@techops.cray.com (Michael Nittmann) writes:


   Happy someone pointed out here that tcp/ip is limited to
   64kB/sec  transfer speed! I always doubted my numbers here for
   xfer speeds. Thanks a lot for the enlightment, Antti!

Say what??? This must be utterly wrong!
-- 
Real life:      Thomas Tornblom             Email:  thomas@uppsala.telesoft.se
Snail mail:     Telesoft Uppsala AB         Phone:  +46 18 189406
                Box 1218                    Fax:    +46 18 132039
                S - 751 42 Uppsala, Sweden
-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 91 11:41:59 GMT
From:      eru!hagbard!sunic!dkuug!resam!peter@bloom-beacon.mit.edu  (Peter Pedersen)
To:        tcp-ip@nic.ddn.mil
Subject:   bootp daemon source wanted (TCP/IP)

We are looking for the source to the server process "bootd" for booting
a diskless client using the bootp-protocol on a TCP/IP network.
The source should run on a UNIX system V preferable release 4 or 3.2, but other
version will also be appreciated.

Please answer directly by email, with the source or with any information 
regarding this matter.

Thank you in advance

Peter Pedersen

UUCP: peter@resam.dk, phone: +45 32 32 54 81
SAS, RESAM Project Office, CPHML-V, P.O.BOX 150, DK-2770 Kastrup, Denmark
-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 91 13:55:57 GMT
From:      terminus.umd.edu!dzoey@umd5.umd.edu  (Joe Herman)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Monitoring Ethernet traffic with a simple Ethernet card
In article <1991Jan9.180145.2211@blister.Solbourne.COM> patrick@blister.Solbourne.COM (Patrick Bowman) writes:
>I'm looking for an Ethernet line monitor program that runs on an IBM
>PC and works through a standard Ethernet card (3Com, WD, etc.).  I
>know that they exist  -  I've spoken to people who claim to have seen
>them in operation.

The old PCIP distribution (available from husc6.harvard.edu) contains
a simple ethernet monitor (netwatch) that displays the packets on an
ethernet in real time.  It lacks much that professional ethernet
monitors give you (performance, many many stats, traffic generation) but
has the advantage of being free and in the public domain.  I believe
that PCIP will now work with packet drivers.

I used this for a couple of years to debug some code I was writing and it
was invaluable.

				Joe Herman
				U. of Md.

dzoey@terminus.umd.edu

-- 
"Everything is wonderful until you know something about it."
-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 91 16:36:14 GMT
From:      att!watmath!watserv1!utgpu!utzoo!censor!geac!torsqnt!sickkids!mark@ucbvax.Berkeley.EDU  (Mark Bartelt)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for terminal server recommendations
[ None of the three newsgroups I'm posting this to seem exactly
  correct, but I can't think of anything else more appropriate,
  either ...  ]

We're soliciting suggestions for TCP/IP-based terminal servers,
preferably low-priced but capable of doing all the things that
we need to do.  Specifically ...

(1)  Handle hardwired lines.  (I.e. doesn't require that DTR be
asserted to the port on the server.)

(2)  Deal sensibly with dialin lines; when used with dialin modem,
should behave like a modem connected directly to one of the host's
RS232 ports:  Will sense loss of carrier and cause process(es) in
host to receive SIGHUP.  Last-close in host should cause server to
drop DTR to the modem, so that phone connection is broken.

(3)  Provide multi-speed support, and other useful functionality,
with dialout modems.  Ideally, ioctl() calls (such as TIOCSDTR and
TIOCCDTR for controlling DTR; TIOCSETP for changing the baud rate
used between the server and the modem) from the host should do what
you'd expect.

Unfortunately, the servers that we've found that do everything we
want are prohibitively priced.  And the low-cost ones lack one or
more of the features we want.  Here's hoping someone has a useful
suggestion.  Thanks in advance ...

Mark Bartelt                        INTERNET: mark@sickkids.toronto.edu
Hospital for Sick Children, Toronto           mark@sickkids.utoronto.ca
416/598-6442                        UUCP: {utzoo,decvax}!sickkids!mark
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 91 16:42:01 GMT
From:      sdd.hp.com!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!magnus.ircc.ohio-state.edu!tom@ucsd.edu  (Tom Easterday)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for inexpensive terminal server

I am looking to buy or, perhaps, build an inexpensive terminal server.

Does anyone know of a manufacturer making an 8 (or more) port terminal
server for under $1000?  If not, what is the cheapest anyone has seen
one go for?

Is there any public domain terminal server code for a pc? A KA9Q hack
or something like that?

		Tom
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 91 18:41:41 GMT
From:      usc!zaphod.mps.ohio-state.edu!mips!smsc.sony.com!tin@ucsd.edu  (Tin "Man" Le)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PPP on STREAMS
In article <1991Jan09.203715.2498@nstar.rn.com> larry@nstar.rn.com (Larry Snyder) writes:
>jbreeden@netcom.UUCP (John Breeden) writes:
>
>>AT&T SysV/386 R4's Win/TCP R4 has a SLIP driver (and other goodies).
>
>how about PPP (compressed headers) SLIP?
>

   PPP != SLIP

   They are two different things.

   SLIP = Serial Line IP

   PPP = Point to Point Protocol

   The original SLIP was a straight forward encapsulation type of
   IP onto serial line.  Van Jacobson later added header compression
   to SLIP (CSLIP, available at ftp.ee.lbl.gov).

   PPP is a newer protocol, designed to get around problems in SLIP.

-- Tin

-- 
.----------------------------------------------------------------------
. Tin Le                    Work Internet: tin@smsc.Sony.COM
. Sony Microsystems              UUCP: {uunet,mips}!sonyusa!tin
. Work: (408) 944-4157      Home Internet: tin@szebra.uu.net
-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 91 19:46:55 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!think.com!barmar@ucsd.edu  (Barry Margolin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: An INTERESTING problem
In article <9101100248.AA01030@desktalk.desktalk.com> rlg@desktalk.com (Richard L. Gralnik) writes:
>The standard wisdom/procedure is to assign a subnet number to each remote
>office, another subnet number to each serial line, and another (or many)
>to the central site net.  We want to use an 8-bit subnet mask for the 
>obvious reasons, but the cost of this is that the serial lines become 2-node 
>subnets, thereby wasting 251 addresses (including 0 and 255) each.  Since 
>there are 20 remote sites, and the user wants redundant serial lines because 
>the network is mission-critical, we eat up 60+ subnet numbers right off the
>bat.  

Some routers (e.g. cisco) support configurations where the ends of a
point-to-point link are not assigned unique addresses, so the serial lines
don't have to be assigned subnet numbers.  As far as all the other hosts
are concerned, the two routers connected by the serial line are a single
virtual host (the serial link would be a slow virtual bus).  The routers
themselves need to know the number of at least one subnet connected to the
router at the other end of the link.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jan 1991 10:36:46 -0800 (PST)
From:      MCMAHON@TGV.COM (John 'Fast-Eddie' McMahon)
To:        jtb1585%ccfvx3.draper.com@relay.cs.net, knauer@mars.lerc.nasa.gov
Cc:        service@TGV.COM, gray@TGV.COM, tcp-ip@nic.ddn.mil
Subject:   TCP/Connect II and MultiNet
The problem with MultiNet and TCP/Connect II FTP seems to be in the TCP/Connect
parser that reads the LIST FTP command back from the MultiNet server.  If you
switch the host type from "Automatic" to "Generic" when establishing the
connection it will work just fine.

John 'Fast-Eddie' McMahon    :    MCMAHON@TGV.COM    : TTTTTTTTTTTTTTTTTTTTTTTT
TGV, Incorporated            :                       :    T   GGGGGGG  V     V
603 Mission Street           : HAVK (abha) Gur bayl  :    T  G          V   V
Santa Cruz, California 95060 : bcrengvat flfgrz gb   :    T  G    GGGG   V V
408-427-4366 or 800-TGV-3440 : or qrfgeblrq ol znvy  :    T   GGGGGGG     V
-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 91 23:17:18 GMT
From:      sgi!cjohnson%somni.wpd.sgi.com@ucbvax.Berkeley.EDU  (Chris Johnson)
To:        tcp-ip@nic.ddn.mil
Subject:   IP Bandwidth limits (was Re: TCP window size restriction)

	Well, there is a data rate limit for TCP/IP,
	but it isn't window size dependent.  The
	sixteen bit IP id field and the 16 bit max
	packet length limit a particular connection
	to 4GB/255 seconds or about 16MB/sec.

					cj*
-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 01:01:04 GMT
From:      usc!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!simon@ucsd.edu  (Simon Hackett)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: An INTERESTING problem

You don't have to waste a subnet number on each sl/ip link. You can configure each end of the link using the primary IP address of each system as the addresses configured into the sl/ip interface at each end of the sl/ip link.

i.e. for a link thus:

   ----(ether)----[HOST A]--(sl/ip)--[HOST B]---(ether 2)---

If HOST A and HOST B have primary IP addresses for each of their respective ethernets, set up the sl/ip interface on HOST A so the ip address of the local side of the sl/ip link is the same as host A's ethernet address, and set the IP address of the remote end of the sl/ip link to the ethernet IP address of HOST B. Vice versa at the other end.

What happens under these conditions? Well, it might look illegal, but although it skates on the edge, it works: For routing out of HOST A to HOST B, all the matters is the remote sl/ip interface address - so packets get sent correctly to host B. They have a source IP address of [HOST A's ethernet IP number], but this is perfectly valid for them.

Packets on the way back work the same way - since they are tagged as having originated from HOST A's ether address, they get routed to HOST A via the SL/IP link. 

Hopefully this makes sense. If you imagine you're an IP router and go through the steps involved in routing packets each way, you'll see that it works out right.

Simon Hackett
Adelaide Uni
-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jan 91 09:45:45 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        eru!hagbard!sunic!lth.se!newsuser@bloom-beacon.mit.edu  (Ricard Wolf)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Monitoring Ethernet traffic with a simple Ethernet card
    1) FTP software have a package called LanWatch, witch monitors and
       disassembles network traffic.

The MIT/CMU/Harvard "PCIP" freeware distribution contains "Netwatch",
an ancestor/cousin of LANWatch.  The version on husc6.harvard.edu
represents a considerable improvement on older versions.

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

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 03:10:48 GMT
From:      haven!sura.net!oleary@louie.udel.edu  (dave o'leary)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: An INTERESTING problem
In article <9101100248.AA01030@desktalk.desktalk.com> rlg@desktalk.com (Richard L. Gralnik) writes:
>Hi everyone,  
>
>We are trying to make efficient use of a Class B address in a situation where
>the standard procedure wastes roughly half the available addresses.  Any
>thoughts on our proposed solution(s) or others of your own devising would be
>greatly appreciated.
>
[Typical scenario where variable length subnets are desirable deleted]

>	2.  Use different size subnet masks for the serial lines than for
>		the office subnets.  We don't think the routers will like
>		this very much.
>

OSPF can deal with variable length subnet masks, now that most of
the major router vendors are committed to implementing it, there
shouldn't be any problem.... :-)

					dave
-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jan 91 09:37:10 EST
From:      JOHN%UMSSMDVM@mitvma.mit.edu
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Slip on a Decstation
>
Does anyone out there run slip on a Decstation?  Do I get it from DEC?
Are there any "free" versions?  Please reply to me john at umassmed.
thanks-
-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jan 91 09:26 EDT
From:      Bill Wine <BIWINE@vaxsar.vassar.edu>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: NFS for Mac...
>Hello, all:   Does anybody knows of a program to access NFS servers from
>              a Mac. PDD/Shareware if possible... I have been looking all
>              FTP sites, and the only thing i have found are NNTP readers..
> 
>Thanx for your time...
>Gus Cavazos
>gcavazos at vmtecmex.cem.itesm.mx
>gcavazos at vmtecmex.bitnet

I am not aware of a program that does this, but the GatorBox from Cayman
lets a Mac access NFS servers as if they were Appleshare volumes.

Bill Wine
biwine@vassar.edu
-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jan 91 10:51:44 EST
From:      Jeremy Greene <greene@coral.com>
To:        tcp-ip@nic.ddn.mil
Subject:   inet_ntoa()


The Sun man pages has the following definition:
 
    char *inet_ntoa( ipAddr )
    struct in_addr ipAddr;
 
which use to work, instead of
 
    char *inet_ntoa( ipAddr )
    struct in_addr *ipAddr

which now works. Has anyone else had this problem?
 
JAG

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Fri 11 Jan 91 14:00:49-PST
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        usc!zaphod.mps.ohio-state.edu!mips!smsc.sony.com!tin@ucsd.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: PPP on STREAMS
It is also worth reminding people that PPP support does not necessarilly
imply that header compression is supported.  Header compression support
is orthagonal to whether you run SLIP or PPP...

BillW
-------
-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 06:18:53 GMT
From:      timbuk!cs.umn.edu!uc!noc.MR.NET!nic.stolaf.edu!nic.stolaf.edu!swansonc@uunet.uu.net  (Chris Swanson, St. Olaf College)
To:        tcp-ip@nic.ddn.mil
Subject:   What is PPP (was Re: Installing PPP questions and problems)

I just "tuned-in" to this newsgroup and read this message about PPP.
I am looking at having my own machine at home after I graduate and
running a SLIP line to a host in my hometown.  It seems as if this
"PPP" is a replacement for SLIP, is that correct?  If so, what are the
+/- between it and SLIP?  Any info would be appreciated.  Please
e-mail to the address below, as I do not always get a chance to read
all the news before it is expired.

Thank's in advance,

	-Chris

--
Chris Swanson, Chem/CS/Pre-med Undergrad, St. Olaf College, Northfield,MN 55057
	INTERNET:  swansonc@acc.stolaf.edu	UUCP: swansonc@stolaf
    	AT&T:	   Work: (507)-645-6845		Home: (507)-663-6424
	I would deny this reality, but that wouldn't pay the bills...
-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jan 91 15:42:16 -0500
From:      fks@ftp.com (Frances Selkirk)
To:        tcp-ip@nic.ddn.mil, usc!zaphod.mps.ohio-state.edu!mips!smsc.sony.com!tin@ucsd.edu
Subject:   Re: PPP on STREAMS
	
>  PPP is a newer protocol, designed to get around problems in SLIP.
	
Specifically, PPP masks characters (in a given range) that a modem 
might interpret as control characters and masks them. It transmits the
masked character preceded by a character which signals to PPP that the 
following character is masked. The receiving PPP implementation then 
decodes the masked character. Because of this, PPP can actually be somewhat
slower than SLIP, but it is more dependable. Assumably, that dependability
should save you time in the long run.


	

Frances Kirk Selkirk		 info@ftp.com	           (617) 246-0900
FTP Software, Inc.		 26 Princess Street, Wakefield, MA  01880

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 07:56:44 GMT
From:      PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   Re: An INTERESTING problem

On Wed, 9 Jan 91 18:48:55 PST Richard L. Gralnik said:
>	3.  Use our Class B network number for the central net and for the
>		remote office nets with the 8-bit subnet mask, and use
>		subnetted Class C addresses for the serial lines.  We think
>		this will work since all the Class B subnets have the same
>		net number and subnet mask, and since RIP only sends
>		(sub)net numbers and next hop addresses, the updates should
>		be accurate.

A&Q.
Configuration when routing by a pair of hosts usually provides the alternative
of (1) using a network number dedicated to the serial line or (2) having
each side borrow for the line interface a network address from the other
side (i. e. one it uses on another interface). I bet you're allowed (2) but
avoid it.
PCROUTE's doc says that (1) is "PREFERRED", and that, in case (2) is used,
one should "turn off RIP on this interface".
TCP/IP for VM (version 1.2) seems to propose only (2) for links on SNA. For
example I use home addresses 2.1 on one side and 32.1 on the other albeit
32.1 is the home address of another Ethernet interface of the latter.
What are exactly the reasons favoring (1) besides saving a network number?
What is the RIP concern? RIP broadcast traffic or RIP operability?
I guess there's no reason for added traffic, as each host is supposed to
send only its routing tables. But where goes a broadcast supposed to be sent
to a network and that's received by a single host, etc...
Any guru's comment?

I think that (2) is safe indeed.
I see no reason for keeping a network address contiguous. No more than if
you were using multiple C addresses.

Andr'e PIRARD             SEGI, Univ. de Li`ege
B26 - Sart Tilman         B-4000 Li`ege 1 (Belgium)
pirard@vm1.ulg.ac.be  or  PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jan 91 07:44:07 +0100
From:      Craig Partridge <craig@sics.se>
To:        tcp-ip@nic.ddn.mil
Subject:   comments on Internet Manager's Phone Book

Hi folks:

    The NIC tells me that some people have been sending comments about the
format and organization of the Internet Manager's Phone Book to them.

    This is just a reminder that the Internet Manager's Phone Book is a
a publication of the NSF Network Service Center, *not* the NIC, so comments
on the format and organization of the Phone Book should go to nnsc@nnsc.nsf.net
[Please don't send them to me either -- I'm on a sabbatical -- I'm handling
this to clean up old mail]

    ONLY changes to your NIC entry (many of which were used to generate
the Phone Book) should go to the NIC.

Craig
-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 09:35:54 GMT
From:      julius.cs.uiuc.edu!rpi!uupsi!sunic!sics.se!uplog.uppsala.telesoft.se!uplog.uppsala.telesoft.se!thomas@apple.com  (Thomas Tornblom)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP Bandwidth limits (was Re: TCP window size restriction)
In article <80719@sgi.sgi.com> cjohnson@somni.wpd.sgi.com (Chris Johnson) writes:

	   Well, there is a data rate limit for TCP/IP,
	   but it isn't window size dependent.  The
	   sixteen bit IP id field and the 16 bit max
	   packet length limit a particular connection
	   to 4GB/255 seconds or about 16MB/sec.


Sorry if I'm being overly ignorant but I can't make sense out this.
Where does the time come into this as a limiting factor other than the
available bandwidth of the underlying hardware?

Thomas
-- 
Real life:      Thomas Tornblom             Email:  thomas@uppsala.telesoft.se
Snail mail:     Telesoft Uppsala AB         Phone:  +46 18 189406
                Box 1218                    Fax:    +46 18 132039
                S - 751 42 Uppsala, Sweden
-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jan 91 08:56:44 +0100
From:      Andr'e PIRARD <PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: An INTERESTING problem
On Wed, 9 Jan 91 18:48:55 PST Richard L. Gralnik said:
>	3.  Use our Class B network number for the central net and for the
>		remote office nets with the 8-bit subnet mask, and use
>		subnetted Class C addresses for the serial lines.  We think
>		this will work since all the Class B subnets have the same
>		net number and subnet mask, and since RIP only sends
>		(sub)net numbers and next hop addresses, the updates should
>		be accurate.

A&Q.
Configuration when routing by a pair of hosts usually provides the alternative
of (1) using a network number dedicated to the serial line or (2) having
each side borrow for the line interface a network address from the other
side (i. e. one it uses on another interface). I bet you're allowed (2) but
avoid it.
PCROUTE's doc says that (1) is "PREFERRED", and that, in case (2) is used,
one should "turn off RIP on this interface".
TCP/IP for VM (version 1.2) seems to propose only (2) for links on SNA. For
example I use home addresses 2.1 on one side and 32.1 on the other albeit
32.1 is the home address of another Ethernet interface of the latter.
What are exactly the reasons favoring (1) besides saving a network number?
What is the RIP concern? RIP broadcast traffic or RIP operability?
I guess there's no reason for added traffic, as each host is supposed to
send only its routing tables. But where goes a broadcast supposed to be sent
to a network and that's received by a single host, etc...
Any guru's comment?

I think that (2) is safe indeed.
I see no reason for keeping a network address contiguous. No more than if
you were using multiple C addresses.

Andr'e PIRARD             SEGI, Univ. de Li`ege
B26 - Sart Tilman         B-4000 Li`ege 1 (Belgium)
pirard@vm1.ulg.ac.be  or  PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU
-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jan 91 11:02:17 +0100
From:      Craig Partridge <craig@sics.se>
To:        tcp-ip@nic.ddn.mil
Subject:   more on Elements of Networking Style

I think some folks who have complained about "ENS", have missed its point.

Yes, the prose is sometimes wild and crazy, but then again, it is intended
that way.  Half the point of the book is to have some fun (and certainly, I,
as a reader, had a lot of fun reading it).

As for technical content, that ain't bad neither.  My copy of the book is
believed to still be on a boat, somewhere in the Atlantic,* courtesy of
the postal service, but I recall good discussions on issues in
externalization, design of reference models and on cultural desires (in
corporations) to develop one's own networking protocol suite.  MAP's
writing style should not confuse you into believing there's no substance
behind it.

Craig

*no doubt dodging the Next Wave, but I digress...
-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 14:37:10 GMT
From:      JOHN%UMSSMDVM@MITVMA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Slip on a Decstation

>
Does anyone out there run slip on a Decstation?  Do I get it from DEC?
Are there any "free" versions?  Please reply to me john at umassmed.
thanks-

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jan 91 13:21:43 +0100
From:      Craig Partridge <craig@sics.se>
To:        tcp-ip@nic.ddn.mil
Subject:   More on TCP Performance Limits

There seems to be a lot of misinformation running around.

The end-to-end performance of a TCP connection is limited by two different
factors:

    (1) The window size.  Because the window size determines how much
    unacknowledged data can be in flight, the maximum bandwidth a
    connection can achieve is the window size divided by the round-trip
    time.

    (2) The sequence space size.  To ensure that you don't get sequence
    space wrap (two different instances of byte #37 active at the
    same time), TCP places time limits (which depend on IP flushing
    packets of a certain age) on how fast you can cycle through the
    sequence space.

Right now (1) is the usual limit on throughput.  I believe you have to get
substantially past FDDI speeds for (2) to be a problem.

RFCs 1072 and 1185 discuss these issues in more detail.

Craig Partridge
(on sabbatical at the Swedish Institute of Computer Science).
-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 15:06:09 GMT
From:      snorkelwacker.mit.edu!ira.uka.de!fauern!faui43.informatik.uni-erlangen.de!lswolf@apple.com  (Lars Wolf (Inf4 - hiwi))
To:        tcp-ip@nic.ddn.mil
Subject:   protocol environment

Hello,
I'm working on my diploma thesis about 
	runtime environments for high-speed protocols
(for the transport system of a communication system, layers 2 - 4 in OSI)
I'll implement it in a UNIX-kernel .

Therefore I'm searching for papers in this topic, especially:
	- buffer management
	- multiple timer mechanisms
	- lightweight processes
	- upcall environments

Any references would be very appreciated.

Please mail to me, I'll make a summary for the net.

Thank you very much,
	Lars Wolf

-----------------------------------------------------------------------
| Lars C.  Wolf             (lswolf@immd4.informatik.uni-erlangen.de) |
| Friedrich Alexander Universitaet    Erlangen/Nuernberg    (Germany) |
-----------------------------------------------------------------------
-- 

-----------------------------------------------------------------------
| Lars C.  Wolf             (lswolf@immd4.informatik.uni-erlangen.de) |
| Friedrich Alexander Universitaet    Erlangen/Nuernberg    (Germany) |
-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 16:08:31 GMT
From:      cscnj!paul@rutgers.edu  (Paul Moody)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PPP on STREAMS

Many thanks to all who have responded. We had intended to go with
S5R4. Its nice to know that slip comes with it.

Paul
-- 
Paul Moody			UUCP: rutgers!cscnj!paul 
Computer Sciences Corporation	PHONE: (908)562-6529
# the opinions expressed are entirely imaginary			#
-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 16:14:23 GMT
From:      att!cbnewsj!cbnewsi!kotto@ucbvax.Berkeley.EDU  (karen.otto)
To:        tcp-ip@nic.ddn.mil
Subject:   Resequencing in TCP

I would like to find out how Wollongong TCP does resequencing.
One scenario that has been suggested as likely is that if it 
receives IP packets 1,2,4 it throws 4 away immediately.  Then if 
3 arrives right after 4 is thrown away, the receiving TCP accepts 
3 and states that it is expecting packet 4 and thus packet 4 must be 
retransmitted.  (So basically TCP doesn't accept out-of-sequence 
packets).

I understand that this is implementation dependent.  I am 
particularly interested in the Wollongong implementation, but I 
would also appreciate any information anyone had on any of the 
other implementations out there.

Thank you for any help you can offer, including contacts.


Karen Otto			AT&T Bell Laboratories
karen.otto@att.com		(908)-949-3370

Standard Disclaimer:  All opinions are strictly those of the author.
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 18:17:02 GMT
From:      usc!julius.cs.uiuc.edu!zweig@ucsd.edu  (Johnny Zweig)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP Bandwidth limits (was Re: TCP window size restriction)
cjohnson@somni.wpd.sgi.com (Chris Johnson) writes:
>	Well, there is a data rate limit for TCP/IP,
>	but it isn't window size dependent.  The
>	sixteen bit IP id field and the 16 bit max
>	packet length limit a particular connection
>	to 4GB/255 seconds or about 16MB/sec.

For one thing, 255 seconds seems like a long TTL but whatever. There is _not_
a requirement for IP that ID numbers be unique over the time frame of one TTL
(or 2*TTL or whatever). ID numbers are for fragment reassembly -- no fragments
means no bandwidth limitation (so as long as I guaranteee my super-zippy net
has an MTU of 65536 octets I am okay).

I admit this is dangerous, in the sense that if some moron comes along and
starts fragmenting in a bizarre way such that fragments aren't reassembled
soon enough and their IDs get confused (a multi-megabyte LIFO buffer?) things
will break, but I think it is important to keep in mind that just because IP
was designed around very general interoperability requirements it is broken.

-Johnny IP
-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 18:53:52 GMT
From:      usc!jarthur!bridge2!3comvax!tymix!cirrusl!sunstorm!dhesi@ucsd.edu  (Rahul Dhesi)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sockets, TLI, or what
In <9101021513.aa02786@Mercury.TWG.COM> ljm@TWG.COM writes:

     ...consider TLI the 'native' transport interface for
     UNIX and sockets is more of a cross-platform API.

As others have pointed out, you should have said System V, not UNIX.

     The tradeoff is usually quite simple.  On all the platforms, the
     native interface offers unique advantages to the developer of
     system specific applications in terms of memory usage,
     performance, functionality or perhaps all three.

This is where I get puzzled.  I have read the comparison of sockets vs
TLI in Stevens's book, and I've read AT&T's documentation.  All I can
find is that TLI has some bugs (e.g. failed writes not correctly
reported).  I don't see what TLI does so much better than sockets.  Is
TLI more than another manifestation of the NIH syndrome?  What are its
performance, functionality, and memory usage benefits?
--
History never         |   Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
becomes obsolete.     |   UUCP:  oliveb!cirrusl!dhesi
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 19:37:23 GMT
From:      usc!samsung!emory!hubcap@ucsd.edu  (System Janitor)
To:        tcp-ip@nic.ddn.mil
Subject:   LAT
Would anyone in this forum care to comment on these claims?

-Mike

*********** LAT/ TELNET comparison ***********

- LAT is optimized for terminal/host connectivity on a single LAN
        "For asynchronous traffic on local networks, LAT is the best
        available technology and won't easily be supplanted by OSI's
        VT or IP's TELNET [protocols]" (Donald G. Hirsh, DEC
        Professional, February 1990).

- LAT causes less of a burden on the CPU and the network 
        "In preliminary test using KI Research's KiNet, DR Labs found
        the DEC's LAT protocol imposed lower overhead on both the host
        CPU and the network than TELNET.  For example, with 45 active
        TELNET session on a Mips M/120-5 system, the CPU had zero
        percent idle time, meaning that it was overload, and only 4.4
        percent of the network bandwidth was utilized. With 64 active
        LAT sessions to the same machine, the CPU was still 50 percent
        idle, and only 2 percent of the network bandwidth was
        utilized. This difference is due in large part to the fact
        that LAT does not use the full DECnet stack, whereas TELNET
        uses the full TCP/IP stack." (Lee Schlesinger, Digitial
        Review, August 27, 1990)
-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 21:17:53 GMT
From:      timbuk!shamash!easyaspi.udev.cdc.com!gsa@uunet.uu.net  (gary s anderson x2911)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  TCP Spoofing...
In article <12652397791.27.PADLIPSKY@A.ISI.EDU>, PADLIPSKY@A.ISI.EDU (Michael Padlipsky) writes:
|> In religious terms, letting "the customer decide" where ACKs come from
|> IN THE TCP CONTEXT is tantamount to letting the parishoner decide whether
|> the "nots" belong in the Commandments.  Unlike Ekstwennifie's "D" bit,
|> the meaning of the TCP ACK is not defined to be voluntary ... and IS
|> defined to have end-to-end/process-to-process significance.
|> 

The one element missing from this religious agrument is the scope of the
TCP acknowledgement.  Applications use the TCP features to reliably move
bytes between systems.  Applications should not (and generally don't) rely
on TCP services to denote success or failure of application activities.
For example, the FTP client application relies on a peer (ftp server) response
to confirm the completion of an FTP request (e.g. create file).  This 
weak application confirmation strategy fails if the network dies after
the request is sent and before the confirmation is received (i.e. did the
file actually get created?!!?).  NOTE - the great power of TCP was helpless
in preventing this problem.

My point is that the scope of the TCP acknowledgement is limited to the TCP
protocol.  This feature is merely a tool used by TCP to provide the guaranteed
data delivery mechanism.  One can certainly find ways to extend this feature,
however, no such standard exists at this instance in time.  Consequently,
the strength of the solution is not where the ACKs come from, but whether or
not the application will successfully operate in this environment (i.e. is
the application still provided a reliable data transfer service).  

NOTE - please do not misconstrue this note as a recommendation for implementing
an "intermediate TCP" solution.  This was merely an open-minded statement
which implies that such a solution can be constructed (with some effort!!!).
-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 21:22:14 GMT
From:      att!watmath!watserv1!utgpu!utzoo!henry@ucbvax.Berkeley.EDU  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: LAT
In article <12578@hubcap.clemson.edu> hubcap@hubcap.clemson.edu (System Janitor) writes:
>- LAT is optimized for terminal/host connectivity on a single LAN

Ah, so one never needs to connect one's terminal to a host that is not
on the same local network?  Gee, DEC, thanks for telling me.  I thought
otherwise. :-)

It is difficult to evaluate the accuracy of such claims when the LAT
specs are (last I heard) still secret.

My first reaction is "this sounds like marketing fluff".

>- LAT causes less of a burden on the CPU and the network 
>        "In preliminary test using KI Research's KiNet, DR Labs found
>        the DEC's LAT protocol imposed lower overhead on both the host
>        CPU and the network than TELNET...

This is *extremely* sensitive to implementation details.  My gut reaction
is that it says almost nothing about the protocols.

>       ...This difference is due in large part to the fact
>        that LAT does not use the full DECnet stack, whereas TELNET
>        uses the full TCP/IP stack...

Now this *is* marketing fluff.  Telnet uses the full TCP/IP "stack", all
two levels of it:  IP for data delivery, TCP for reliability, sequencing,
and flow control.  Unless the laws of nature have gotten repealed somehow,
LAT needs all those functions too.  I can think of no reason offhand why
a well-tuned TCP/IP implementation -- more often spoken of than found,
alas -- should incur any extra overhead compared to whatever LAT uses.

For a guess, they're comparing a user-level Telnet server implementation
against an in-kernel LAT server, and it is no surprise that the in-kernel
approach is more efficient.
-- 
If the Space Shuttle was the answer,   | Henry Spencer at U of Toronto Zoology
what was the question?                 |  henry@zoo.toronto.edu   utzoo!henry
-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 21:35:12 GMT
From:      phri!roy@nyu.edu  (Roy Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: LAT
hubcap@hubcap.clemson.edu (System Janitor) writes:
> Would anyone in this forum care to comment on these claims? [...]
> LAT causes less of a burden on the CPU and the network 

	How much of this is inherent in the protocols and how much depends
on the implementations?  Most Unix telnet servers are implemented as user
processes which use pseudo terminals to talk to login shell processes, which
is a very inefficient way to do things.  For a single character typed by the
user, you get:


	TCP/IP           pty driver           TCP/IP      kernel process
           \           /       \             /
    - - - - \ - - - - / - - - - \ - - - - - / - - - - - - - - - - - -
             \       /           \         /
	      telnetd              telnetd                user process

as the character comes in off the network, gets handed to telnetd which
turns it around to give to the pty driver which generates the echo and the
echo'ed character is handed back to telnetd which sends it back out onto the
network again; 4 context switches for each character typed.  Some time ago I
remember reading about somebody (Rick Ace?) who had a neat hack which did
most of telnet entirely in the kernal, only invoking the user-space telnetd
when a IAC character was encounted.  I wonder how that implementation would
stack up against LAT for CPU utilization?
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane?  Did you say arcane?  It wouldn't be Unix if it wasn't arcane!"
-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 22:06:35 GMT
From:      lll-crg.llnl.gov@lll-winken.llnl.gov  (Mark Boolootian)
To:        tcp-ip@nic.ddn.mil
Subject:   Does a TCP/IP test suite exist?

Is anyone aware of a test suite for TCP/IP?  We would like to test the 
robustness of an implementation and are hopeful something like a test suite
exists.  Boy, that was short and to the point!

Please email any responses as I'm always behind in reading the newsgroup...

My thanks precede your reply,
mb
booloo@lll-crg.llnl.gov
-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 22:09:12 GMT
From:      rogue.llnl.gov!oberman@lll-winken.llnl.gov
To:        tcp-ip@nic.ddn.mil
Subject:   Re: LAT
In article <12578@hubcap.clemson.edu>, hubcap@hubcap.clemson.edu (System Janitor) writes:
> Would anyone in this forum care to comment on these claims?
> 
> -Mike
> 
> *********** LAT/ TELNET comparison ***********
[Comments on superiority of LAT to Telnet and VT deleted.]

These comments are certainly correct if taken in the correct context.

1. LAT operates only on a LAN. It can't be routed and depends on the broadcast
nature of LANs. While bridges don't effect LAT, routers, even if between LANs
will break it.

2. Normal caveats on the optimization of any specific implementation apply.
While it would be difficult, I can imagine a very bad implementation of LAT
running with more overhead than a good Telnet.

3. LAT depends on multicasts for servers to learn of available services. This
generates 1 packet per host per minute background on a LAN. It is not
significant except on VERY large LANs. And the multicasts are not, of course,
blocked by bridges. We have about 1000 LAT hosts on our LAN and the multicast
level is not a problem, but it sure is obvious on an analyzer.

4. LAT is proprietary and licensed by DEC. If you use it, DEC want's their cut.
Ki Research is paying DEC for every license they ship. Telnet is available from
almost everyone.

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

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 22:10:29 GMT
From:      mips!batman!robishaw@apple.com  (Gary Robishaw - Loral Rolm Mil-Spec)
To:        tcp-ip@nic.ddn.mil
Subject:   Needed - Free sources for TFTP daemon
Does anybody out there know where I can get a free copy (source) of a
TFTP daemon. I've just ported a BOOTP daemon and would like to start
on TFTP to complete the package.

Thanks in advance,

Gary

-- 
Gary Robishaw          "Every man takes the limits of his own field of vision 
robishaw@mips.com       for the limits of the world." 
408/432-5960                             Arthur Schopenhauer
Usnail -- 3151 Zanker Rd. San Jose, Ca. 95134-1928
-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 22:34:55 GMT
From:      sdrc!mustard@uunet.uu.net  (Sandy Mustard)
To:        tcp-ip@nic.ddn.mil
Subject:   Latest FTP RFCs
I have been porting some code which is doing automated
file transfers by logging on to the FTP daemons and
issueing ftp commands. As I have ported this code to
an IBM MVS mainframe, I have noticed that the responses
from various FTP commands do not comply with the state
table (or valid reply list) as defined in RFC959.

I would like to know what is the latest RFC concerning
FTP commands and their valid replies so I can determine
if the original coder of this code is in error or that
IBM's FTP is in error.

Thanks,
Sandy Mustard
mustard@sdrc.uu.net
-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 22:56:50 GMT
From:      eagle!news@ucbvax.Berkeley.EDU  (Steven Eubanks)
To:        tcp-ip@nic.ddn.mil
Subject:   Telnet rotors/connection distribution?

I am looking for anyone who has any information/experience regarding
"rotoring" or distributing Telnet connections across a pool of multiple
equivalent hosts (IP addresses).

CURRENT ENVIRONMENT:

This site currently has a cluster (yes, of course VAXes) of host machines,
configured identically (applications as well as hardware) providing
central application services to a large LAN composed of
PCs/MACintoshes/Workstations (2000+).  In this (VAXcluster) configuration,
any PC/MAC/WS user can access any of the clustered host machines to execute
these centrally-located applications.  Until recently host connectivity
across the LAN was provided by a non-TCP protocol suite which provided a
"rotoring" capability which "pseudo-randomly selected" which of the n
identical nodes the user would attach to. Voila! Instant connection
distribution. [Notice I didn't quite say load balancing ;-)] Now, having
installed TGV's Multinet on the VAXcluster, and migrating more of our
networked PCs to TCP, we are wishing to duplicate that same "rotor group
connectivity" using TCP/IP.

PROBLEM/QUESTIONS:

How??  Has anyone successfully done/addressed this?

Since all our PCs/MACs/WSs are directly connected to the ethernet LAN,
there's no intermediate device to distribute the connections.  DNS, at
least as much as I know of the RFC-compliant version, doesn't address this
problem.  I can't think of anything that can be done on the VAX end
(though I'm willing to be proved wrong).  Surely, we're not the only site
having reached this dilemma.  Ideas??  Suggestions??  

[Please address all distributed computing environment rhetoric to
/dev/null;  we're working on it. :-) ]

Thanks in advance for all the advice!

Steve
--
Steven W. Eubanks,  EDS/LIMS			NASA Lewis Research Center
Internet:xxseub@osprey.lerc.nasa.gov		21000 Brookpark Rd. 
(216)433-8498					Cleveland, OH  44135
Disclaimer:  Opinions like mileage, may vary.
-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 23:04:16 GMT
From:      van-bc!ubc-cs!alberta!cpsc.ucalgary.ca!yogi.fhhosp.ab.ca!henry@ucbvax.Berkeley.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   Re: LAT
> Would anyone in this forum care to comment on these claims?
> 
> -Mike
> 
> *********** LAT/ TELNET comparison ***********

I can't comment from a technical point of view, but from a real-world
user's point of view, LAT has one distinct advantage - it handles
buffering in a non-annoying way.  Control-C's are have very little
latency as compared to TELNET.

If you're considering buying a terminal server, I'd buy one with both..

Cheers,
-Henry Bland
-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 91 23:27:55 GMT
From:      usc!jarthur!nntp-server.caltech.edu!todd@ucsd.edu  (Todd_Booth)
To:        tcp-ip@nic.ddn.mil
Subject:   How to spool print jobs to term srv (ip address/port)
My configuration is:

Host   term_server
 |        |  |
 +--------+  printer
  ethernet

I can setup the terminal server to accept data sent to it's ip address
at a given port and route that data to the printer.

But I can't find any software to run at the host end that will spool
printer data to a given ip address (term server) and port.  Has anyone
done this before or know how?

thanks, --todd

--
todd (booth) 

todd@quotron.com 213 302-4368
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 91 00:33:28 GMT
From:      royce@scoraz.resp-sci.arizona.edu (Royce Robbins)
To:        comp.protocols.appletalk,comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.mac.comm
Subject:   Summary: AppleTalk <-> Ethernet with PCroute


   I wanted to share my experience with the Net.  Some time ago I asked for
help in doing what I describe, and received it.  Just wanted to pass it along.

Summary:
   PCroute provides a viable solution at a fraction of the cost of a FastPath-
type DDP-IP gateway for situations that have a heterogeneous mix of PCs, Macs, 
UNIX, and VMS hosts on LocalTalk and ethernet, that need TCP/IP-based 
internetworking but don't need AppleTalk routing.  With the collection of 
software described, TCP/IP services (telnet, ftp, ARP, etc.)  are 
provided, as well as UNIX/VMS lpr style print spooling is available in both 
directions (LocalTalk <-> Ethernet);  PC and UNIX/VMS hosts enjoy NFS client 
and server file services, while Macs have NFS client-only file sharing (server 
services are available in other products).  
   Advantages include:
     Low cost - can recycle existing hardware, any new hardware is quite 
       inexpensive and can be purchased in small increments.
     Higher speed - using a FlashCard in the PCrouter and FlashBoxes on 
       LocalTalk devices will give better than three times the performance of 
       AppleTalk.  FastPaths etc., won't work at FlashTalk speed.
     Less server overhead - The whole CAP/UAB/KIP suite is unnecessary.
     AppleShare without a dedicated AppleShare server.
   Disadvantages are:
     No non-local AppleTalk routing.
     Only one LocalTalk interface per PCrouter.
     Changing number or type of interface requires recompiling PCroute with 
       Turbo Assembler.
 
Problem:
   Provide TCP/IP based services (telnet, ftp, NFS, printer access)
   for machines on three separate networks.  AppleTalk to "The World" 
   not required or desired.
 1) A number of PC-NFS clients on an ethernet segment served by a Sun4
 2) The campus backbone and the rest of the world
 3) A LocalTalk segment with Macs and a LaserWriter to serve as print 
    client to the PCs and Sun4

              PC        PC  PC   PC       PC
               |         |   |    |        |
    T-----+----+---------+---+----+---+----+----T (Thinwire Ethernet)     1)
        |                           |
      +-+--+                     +--+----+
      +Sun4+    +-------------+  |       |
      +----+    |Apple Laser  |  | Router+------->"The World" (Ethernet)  2)
                |Writer II NTX|  |       |
                +------+------+  +----+--+
                       |              |                                        
      +----------+-----+-----+--------+--+ (LocalTalk)                    3)
      |          |           |           |      
    Mac SE   Mac SE/30    Mac IIx     Apple IIgs


Solution:
   The standard solution would be to buy a FastPath, GatorBox, MultiGate 
or the like and run KIP/CAP/UAB on the Sun, for a cost of around $2000.  
However, here a very low cost solution was required as there was little 
money and little administrative support ("Whada we wanna do that for?").
   The solution now in place provides a heterogeneous network that is
purely IP-based, i.e. no AppleTalk traffic leaves the LocalTalk segment, but
full client and limited server services are provided to the Mac hosts.

Router:
   Vance Morrison's excellent PCroute software.
     Runs on any PC clone and provides a fully functional IP router.  It 
     accepts up to six network interfaces, in a combination of Ethernet, 
     Starlan, AppleTalk, SLIP and Packet Driver at rates of better that 3Mb/s. 
     It supports subnetted IP routing; static routes; ICMP echo (ping), TTL, 
     Redirect and Unreachable as appropriate; fragmentation; RIP; BSD error 
     logging; proxy ARP; and BootP forwarding.  It supports only WD8003E, S or 
     SH cards, unless used with a packet driver.  Both Apple's AppleTalk PC 
     card and the TOPS FlashCard are supported (but only one per router).  
     Requires Turbo Assembler 1.0 to configure anything other than the supplied 
     Ether-Ether, SLIP-SLIP or Ether-SLIP routers.
     Freely available via anonymous ftp from accuvax.nwu.edu as
        /pub/pcroute/pcroute.2.1.tar.Z  (Executeables and docs only)
        /pub/pcroute/pcroute.2.1.src.tar.Z (Source, executables and docs)
     The author can be reached as morrison@accuvax.nwu.edu.

   I put together a PC with two floppies, a new 10MHz motherboard, two new 
WD8003E cards and a FlashCard, and installed PCroute.  Total cost: $715

Thinwire segment:
 PCs:  
   PC-NFS from Sun provide client services.

   SOS (Stan's Own Server) from Lawrence Berkley Labs.
     Turns a PC into an NFS file server for those rare times it is needed.  
     Runs on top of PC-NFS.
     Public domain.  Contact stan@lbl-csam.lbl.doe.gov for availability.
     
 Sun4: Configured a remote printer in printcaps, added Mac host names to
       hosts.lpd.  No KIP/CAP/UAB installed.

LocalTalk segment:
   MacTCP from Apple.
     This is a software driver that implements the TCP/IP protocols of IP, 
     ICMP, UDP, ARP, RARP, RIP, BootP, TCP and provides a domain name resolver.

   SU-Mac/IP from Stanford University.
     Consists of several parts: Mac/IP which provides telnet (vt100 emulation), 
     ftp, finger and whois clients; MacMH a mail client that requires a POP3 
     server; SU-lpr which provides UNIX facility for printing text file.  Also 
     included is a tn3270 emulation package.  Includes required MacTCP.
     Contact macip@jessica.stanford.edu for distribution details and liscensing.
     Documentation is available on jessica.stanford.edu in /netinfo/macip.

   NCSA Telnet-MacTCP from NCSA, Univeristy of Illinois.
     Provides telnet client (vt102 and Textronix 4014 emulation), ftp server 
     services.
     Freely available via anonymous ftp from ftp.ncsa.uiuc.edu (and others) as
         /NCSA_Telnet/Mac/telnet.2.3tcp.sithqx

   PathWay Client NFS for Mac from The Wollongong Group.
     Provides NFS client services to the Macs, as well as an SNMP agent and a 
     Mac resident LPR Print Server for printing to LaserWriters from a UNIX or 
     VMS host.  Requires AppleShare be installed, and the LPR server requires 
     Multifinder and Print Monitor.  Includes required MacTCP.
     Contact The Wollongong Group, Inc., 1129 San Antonio Rd, Palo Alto, CA 
     94303, phone 1-800-872-8649, fax (415) 969-0196.
     Available for around $200.

   The missing piece was the LPR server from Wollongong.  I'd had the telnet 
and ftp services for a while when I heard about it--but I couldn't print to the 
LaserWriter, now I can.  Aside from snotty customer service personnell, I'm 
happy with it: it works.  The host Mac handles all print spooling to the 
LaserWriter and I can print both text and PostScript files transparently.  The 
NFS services work as advertised, you get an AppleShare volume on the UNIX/VMS 
host.  I've had a few problems writing from applications, however.  It can get 
pricey as each CPU requires its own liscense (multiple 
discounts apply).  Since I only wanted it for the LPR server, one copy was 
sufficient.   
   I prefer SU-Mac/IP over NCSA because it is more thouroughly integrated into 
the Mac interface, provides an ftp client instead of NCSA's server (where you 
had to log in to the remote host and ftp back to your own Mac) and just 
generally seems more robust, (it doesn't require the router be rebooted when it 
hangs) and has the additional applications. 
   Total cost: (one copy of PathWay Client NFS for Mac) $117 

   Total cost for providing services described: $832.  

   Not bad I'd say.  I'd be happy to share my experience with anyone who is 
interested.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Royce Robbins                         INTERNET: royce@resp-sci.arizona.edu
Div Resp Sciences                          FAX: (602) 626-4884
UofArizona                               PHONE: (602) 626-5022
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Standard disclaimers apply.  Trademarks to respective companies, etc.

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 91 01:25:19 GMT
From:      albers@ka3ovk.irs.GOV (Jon Albers)
To:        rec.hamradio.packet,comp.sources.wanted,comp.protocols.tcpip,comp.unix.sysv386
Subject:   KA9Q Net/NOS for SCO Unix V 3.2 wanted

Newsgroups: rec.ham-radio.packet, comp.sources.wanted, comp.protocols.tcp-ip, comp.unix.sysv386

I am looking for source code for KA9Q Net or preferably NOS ported to SCO
UNIX V 3.2.  I do not have regular ftp access, so I would prefer to get it
via anonymous uucp or downloading (I will pay for phone call).  Please
semd E-mail if you have or know where I can get NOS for SCO Unix.

							Jon Albers
					...uunet!media!ka3ovk!albers

-- 
| Jon Albers, IRS, Information Systems Management, Support and Installation.  |
| Office Symbols: ISM:S:S:SI   voice: (202/FTS)535-3729  Packet: KA3OVK@N4QQ  |
| UUCP:(media|teemc|tcsc3b2|ki4pv)!ka3ovk!albers ARPA: JALBERS@SIMTEL20       |

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 91 01:46:23 GMT
From:      usc!wuarchive!uwm.edu!src.honeywell.com!thumper!linde@ucsd.edu  (Larry Linde)
To:        tcp-ip@nic.ddn.mil
Subject:   3-COM/Bridge terminal servers forsale

3-COM/BRIDGE Equipment forsale


CS210's   10 Serial ports, 1 Ethernet 802.3  TCP/IP SW
      	    This is a nice terminal server box. It has 
	    a 3.5" floppy drive with the TCP/IP software on it. 
	    Supports full modem control on all ports with baud 
	    rates up to 38.4k baud. Fully software configurable.
	    You can telnet to the ports or from to other hosts. It 
	    supports IEN116 or standard NAMED for name service. Supports 
	    full subnetting. You can get a new SW release and manual
	    from 3-Com for 200.00 if you wish. The New SW from
	    3-COM will support SNMP (its is beta at present)
            950.00 each or best offer. 


GS300's   Bridge gateway server. If you do not know what it is
	    you most likely do not need one. But its primary 
	    use is to link distant networks over common carrier 
	    lines. (phone -> TCP/IP IE: to tie into the internet)
	    850.00 each or best offer.

NCS150    Network control server (if you don't know what it is
	    you do not need one.) 
	    750.00 or best offer.


Terms: You pay shipping. 10% down/remaining COD. Or you can pick
       it up. Its all in very good condition and fully functional.
       Age varries some says bridge some has 3-com on it. Looks nice.


Larry Linde
linde%thumper@src.honeywell.com
ph# (612) 753-5601 
-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 91 01:46:41 GMT
From:      albers@ka3ovk.irs.GOV (Jon Albers)
To:        rec.hamradio.packet,comp.protocols.tcpip,comp.unix.sysv386,comp.sources.wanted,alt.sources.wanted
Subject:   KA9Q Net/NOS wanted for SCO Unix V/386 3.2


I am looking for source code for KA9Q Net or preferably NOS ported to SCO
UNIX V 3.2.  I do not have regular ftp access, so I would prefer to get it
via anonymous uucp or downloading (I will pay for phone call).  Please
semd E-mail if you have or know where I can get NOS for SCO Unix.

							Jon Albers
					...uunet!media!ka3ovk!albers

-- 
| Jon Albers, IRS, Information Systems Management, Support and Installation.  |
| Office Symbols: ISM:S:S:SI   voice: (202/FTS)535-3729  Packet: KA3OVK@N4QQ  |
| UUCP:(media|teemc|tcsc3b2|ki4pv)!ka3ovk!albers ARPA: JALBERS@SIMTEL20       |

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Jan 91 15:08:39 -0800
From:      "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
To:        Michael A. Patton <MAP@lcs.mit.edu>
Cc:        rlg@desktalk.com, tcp-ip@nic.ddn.mil
Subject:   Re: An INTERESTING problem

Mike, I disagree that #2 is risky (using variable length subnets).  Vendors
running OSPF have to implement variable length mask support, and since
Proteon, 3com, Wellfleet and ACC also have demonstrated OSPF interoperability
recently, with cisco committing to have it by Q2 1991, I fail to see how
this restricts your choice of vendors in any significant way!

Also note, that of the system is running OSPF, subnets no longer need to
be contiguous.  This works fine (we have done this here at Ames).  Time
moves on and progress is made.  People can take advantage of the new
technology.  We don't still eat with stone knives and forks.  Let's try and
avoid the use of their equivalents in routing technology.

						Thanks,
						   Milo
-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Jan 91 17:30:52 MST
From:      cpw%snow-white@LANL.GOV (C. Philip Wood)
To:        craig@sics.se
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  more on Elements of Networking Style
I second that.  "ENS" should be required reading for anyone entering the
Internet arena.  And it's less filling!

Phil

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Sat 12 Jan 91 22:30:33-PST
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        timbuk!shamash!easyaspi.udev.cdc.com!gsa@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  TCP Spoofing...
Regardless of the "legality" of TCP ACK spoofing, I still claim that
that it is not useful to do so.  Especially in the situations originally
brought up (speeding up transport on slow modems, similar to telebit's
kermit, modem, and uucp spoofing).  The windowing inherent in TCP makes
ACK spoofing in these situation unnecessary, since the ACK return time
is not the limiting factor in the end-to-end throughput.


    My point is that the scope of the TCP acknowledgement is limited to
    the TCP protocol.  This feature is merely a tool used by TCP to
    provide the guaranteed data delivery mechanism.

The first sentence is true, the second is most certainly not.  The
round trip time (calculated based on the time to get an ACK) is used
to determin retrasmission intervals, and in newer (Van Jacobson) TCPs,
to estimate the effective bandwidth of the network connection, so that
network congestion can be avoided.  By spoofing ACKs, you gain very
little, and lose a great deal.

Bill Westfield
cisco Systems.
-------
-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Sat 12 Jan 91 22:40:25-PST
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        fks@ftp.com
Cc:        tcp-ip@nic.ddn.mil, usc!zaphod.mps.ohio-state.edu!mips!smsc.sony.com!tin@ucsd.edu
Subject:   Re: PPP on STREAMS

    >  PPP is a newer protocol, designed to get around problems in SLIP.

    [Stuff about masking dangerous characters]

This is only one of the problems PPP was designed to solve.  Off the
top of my head, here are some others:

  PPP has a CRC covering the whole packet, SLIP uses the IP/TCP/UDP
  checksum, which was (a) never intended to detect the types of errors
  likely to occur in async transmission, and (b) not always present
  (NFS comes to mind).

  PPP is designed to support protocols other than IP.

  PPP includes a negotiation protocol to negotiate "stuff", like the
  address of each end, compression, encryption, authentication, protocols,
  and so on.  Many people seem to think that PPP implies support of TCP
  header compression, but this is just an option that can be negotiated.

  PPP is defined for both Sync and Async communications.  Things like
  async PPP to sync PPP translation are theoretically possible.

On the dim side, PPP is very new, so not all of its advantages are
exploited by the implementations currently available.  Currently,
IP is the only protocol widely supported (and the only one that has
made it to RFC status, I think.) Hopefully, time will change this.

Bill Westfield
cisco Systems.
-------
-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 91 16:00:35 GMT
From:      mcsun!ukc!axion!micromuse!peter@uunet.uu.net  (Peter Galbavy)
To:        tcp-ip@nic.ddn.mil
Subject:   IP + SLIP connection - HELP ?
Help,

This may be a bit of a naive question - so no flames on that score
please.

I am in the UK, with a Telebit T2500, and would like to know if anyone
out there on the Internet would let me 'SLIP' into their site for
occasional ftp access to sites such as prep.ai.mit.edu, gatekeeper
etc, for new releases etc.

I have a registered IP network (two class C's).

Two questions:

1) I do not know the legal standing of this ?

2) Anyone willing to let me in ?

BTW. When I say occasional - I mean it, phone charges being what they
are.

Cheers,
-- 
Peter Galbavy
Tech Support, Micromuse Ltd
Phone: +44 71 352 7774		E-Mail: P.Galbavy@micromuse.co.uk

Disclaimer: Time flies like an arrow... Fruit flies like a banana
-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Sun 13 Jan 91 00:14:59-PST
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        usc!samsung!emory!hubcap@ucsd.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: LAT
    Would anyone in this forum care to comment on these claims?

Yeah, I'll comment.  A word about my background first.  Around 1983,
TCP started to be implemented, and I worked in the network group at
SRI International.  We were talking about using the network to replace
our terminal port selectors.  Bridge communications built the worlds
first commercial terminal server, but it spoke XNS, and they were not
interested (at that time) in supporting TCP.  On the other hand, they
would provide documentation so we could write our own code.  TCP was
very young in those days, and we reflected that maybe a special
purpose terminal protocol would be useful.  We didn't do anything, but
were very excited when DEC announced LAT, since it incorporated many
of the ideas we had been talking about.  Unfortunately, DEC refused to
divulge a specification for their new protocol, preferring to keep it
to themselves.  Somewhat later, I moved to Stanford University, where
all terminal access to the computers was already via the network.
Initially, this was using the Xerox PUP "Chat" protocol, but
eventually software was written for our "ethertips" was written to
support TCP.  I did the monitor modifications to TOPS20 to allow it to
support 60+ incoming telnet users and still have some cycles left.
Later, cisco Systems spun out of Stanford, taking the ethertip and
router code, and making them into commercial products.  I went to work
there, doing much work on the terminal server related software,
including adding LAT support about a year ago...


    - LAT is optimized for terminal/host connectivity on a single LAN
        "For asynchronous traffic on local networks, LAT is the best
        available technology and won't easily be supplanted by OSI's
        VT or IP's TELNET [protocols]" (Donald G. Hirsh, DEC
        Professional, February 1990).

Yes, LAT is optimized for terminal host connectivity, but most of those
optimizations are sort of pointless.  The biggest "optimzation" is probably
the ability to put traffic from/to multiple users in a single packet.  In
reality, I doubt whether this happen much - for output to a terminal, a
user could really use a whole packet's worth of data, and for input from
the terminal, even the ~60 ms "slot" times used by LAT don't usually
result in data from more than one used in a packet.

The lack of a network layer might be considered an optimization, but this
"single LAN" that it allows is a fast-vanishing beast.  The fact that it
cannot operate over a complex or Wide-area network is a SERIOUS limitation
of LAT.  Cisco recently announced a "protocol translator" that can convert
between LAT and X25 PAD calls, and offered this to a customer as a solution
for getting LAT across an X.25 network (what they wanted was bridging over
X.25).  Somewhat reluctantly, the customer was willing to test an arrangement
that looked like:

	   LAT        PAD                                 PAD      LAT
  [LAT TS]=======[PT]----[X25 Sw]----[x25 Net]----[X25 Sw]----[PT]======[VMS]
	   ether     1Mb         56kb         56kb        1Mb      Ether

They measured echo delays, and watched the X.25 network loading.  They (and
even I) were surprised when this arrangment resulted in signifcantly BETTER
response times than a solution that did bridge over X.25.  Loading of the
X.25 network was also very much less.

On the other hand, the conclusion that LAT will not easilly be replaced by
Telnet or VTP is quite true.  For one thing, LAT does have several real
(as opposed to theoretical) advantages:

    1) most existing LAT implementations are more efficient that the
	existing telnet implementations.  Sad, but true.

    2) LAT was designed with a specific OS in mind, and supports the
	concepts of that OS better than telnet, which is more general.
	For example, host control of "local flow control" and data
	transparency are clearly defined in LAT, while the flow control
	option has only recently been added to telnet, and is not widely
	available to users.

    3) There is an enormous installed base of LAT.  LAT comes free with
	each DEC computer, while adding IP tends to cost someting.  DEC
	was the first company to push the network as a way of connecting
	terminals to their computers (for which they deserve quite a bit
	of credit), and is \the/ market leader in terminal server sales
	(in spite of the fact that their terminal servers are expensive
	and feature-poor compared to many of their competitors.)

On the other hand, it is equally unlikely that LAT will replace Telnet, or
prevent VTP from being deployed.  For one thing, DEC wants license fees
for LAT implementations, and royalties for each line of LAT terminal servers.


    - LAT causes less of a burden on the CPU and the network 
        "In preliminary test using KI Research's KiNet, DR Labs found
        the DEC's LAT protocol imposed lower overhead on both the host
        CPU and the network than TELNET.  For example, with 45 active
        TELNET session on a Mips M/120-5 system, the CPU had zero
        percent idle time, meaning that it was overload, and only 4.4
        percent of the network bandwidth was utilized. With 64 active
        LAT sessions to the same machine, the CPU was still 50 percent
        idle, and only 2 percent of the network bandwidth was
        utilized. This difference is due in large part to the fact
        that LAT does not use the full DECnet stack, whereas TELNET
        uses the full TCP/IP stack." (Lee Schlesinger, Digitial
        Review, August 27, 1990)

I suspect that most of this is related to the implementations, rather
than the protocols themselves.  As someone has already mentioned, the
usual unix telnetd implementation of telnet is a performance nightmare
due to its excessive context switching.  Many telnet terminal servers
negotiate very small (and non-optimal) packet and tcp window sizes in
an attempt to save memory and/or provide quicker response to interrupt
characters.  Many unix TCPs are not up to the current "state-of-the-art"
in TCP performance issues.

Of course, this is all accademic, since for the end users "the
implementation is the protocol" or some such.  On the other hand, this
is an essentially accademic forum, so we can talk theory.


    >I can't comment from a technical point of view, but from a real-world
    >user's point of view, LAT has one distinct advantage - it handles
    >buffering in a non-annoying way.  Control-C's are have very little
    >latency as compared to TELNET.

    Be careful to distinguish between the protocol and the implementations.

Henry is exactly correct.  This is entirely an implementation issue.
cisco's implementation of telnet has always been "correct", but other
implementation details caused our handling of interrupt characters to
be slower than a lot of people would like.  Under pressure from customers,
we were finally able to make our telnet flush output essentially as quickly
as desired (without using small windows or packets, and without any local
handling of interrupt characters).  It does require that the other end
also handle telnet correctly.


In summary, there is no particularly good reason why LAT should work
better or be a more popular soution for connecting terminals to
computers, but currently it does, and it is, and it's likely to remain
that way for a very long time, mostly because comercial pressures have
made it a more user-tuned product.  And that's important.

Bill Westfield
cisco Systems.
-------
-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Sun 13 Jan 91 00:26:31-PST
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        att!cbnewsj!cbnewsi!kotto@ucbvax.Berkeley.EDU
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Resequencing in TCP
    I would like to find out how Wollongong TCP does resequencing.
    One scenario that has been suggested as likely is that if it 
    receives IP packets 1,2,4 it throws 4 away immediately.

The "Requirments for Internet Hosts" (RFC1122) specifies that TCPs
SHOULD accept out-of-sequence packets, since not doing so can
significantly reduce throughput when packets are lost.  Some
implementations do not do this, so as to conserve memory (I don't
know offhand whether Wollongong does or doesn't).

The latest berkeley software not only accepts these packets, but
contains special code to allow "fast recovery" when a single packet
from a data stream is lost (normally, this would take at least one
retransimssion interval to retransmit the packet, but Van Jacobson
figured out a neat way to notice that a packet was probably lost
before the retransmission interval expires.)

The cisco TCP implementation takes a middle-of-the-road approach.
Up to 5 out-of-sequnce TCP packets are accepted, and then we throw
any more away.  Since our window is 4x a typical Max packet size,
we don't often have to drop any packets...

Bill Westfield
cisco Systems.
-------
-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Jan 91 00:39:58 PST
From:      earle@poseur.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support)
To:        johng@uniwa.UWA.OZ, comp.protocols.tcp-ip
Cc:        tcp-ip@nic.DDN.MIL
Subject:   Re: Installing PPP questions and problems
In comp.protocols.tcp-ip, John Gibbins writes:
>1) When building, the make depend failed because slcompress defines
>BCOPY which has already been defined by machine/param.h (via
>sys/param.h) because I am on a 3/260 running 4.1.  Greg Earle
>(earle@poseur.JPL.NASA.GOV) said he had run it on a 3/260 also running
>4.1.  (Did you have this problem Greg?)
>The simple solution would seem to be to just #undef BCOPY before the
>#define BCOPY in slcompress.c.  Does this seem reasonable?

Yes, I had this problem (see below).  I did an

	#ifdef BCOPY
	#undef BCOPY
	#endif

>2) Greg mentioned that the test for __sys_types_h in
><pixrect/pr_impl_util.h> is wrong.  I agree, but I haven't been able to
>connect this with ppp.c.  From the name, "pixrect" sounds like it is
>part of sunview.  If so, why should it have anything to do with data
>comms (especially as I don't even have a graphics monitor!).

(a) "pixrect" may be the underlying graphics model that SunView is based on,
    but that is not germane here.

(b) Where this file comes into play is that it contains a test which attempts
    to grok whether you're running under SunOS 3.x, 4.0.x, or 4.1/4.1.1.  It
    just so happens that this file happens to be an include file which has to
    do with the pixrect code.  It could be anything, really.

>3) Are there any other things I should watch for during the installation
>like adding #include "ppp.h" to str_conf.c (thanks to Robert McLay et al
>for that warning)?

Here's some additional data points, in addition to the overlap mentioned
above  Some of this has since been mentioned/dealt with:

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

Here's a quick executive summary of what to look out for once you've
installed those 2 files (the original Clarkson PPP code and the OSU patches
and extra scripts & goodies):

(1) The Readme.streams file (instructions for installing under SunOS 4.x)
    neglects to mention in step (3) that one needs to put a `#include "ppp.h"'
    in /sys/sun/str_conf.c.

(2) slcompress.c (which gets compiled into the kernel) contains a macro BCOPY
    definition (#define BCOPY ... ).  If you have a Sun-3/260, some include file
    somewhere does a "#ifdef SUN3_260 ... #define BCOPY ... #endif" (so that
    some kernel code somewhere will notice that this machine has hardware bcopy
    assist).  This causes a clash during the kernel build.

(3) ppp.c has the following hack to get the SunOS release level:

#ifdef sun
/*
 *      Get definition of SUNOS
 */
#include <pixrect/pr_impl_util.h>
#endif

...

# if defined(sun) && defined(SUNOS) && SUNOS >= 41
    if (setsid() < 0) {
        perror("ppp: setsid()");
        exit(1);
    }
# else
    if (ioctl(fd, TIOCSPGRP, &pid) < 0) {
        perror("ppp: ioctl(TIOCSPGRP)");
        exit(1);
    }
# endif

    The trouble is, the <pixrect/pr_impl_util.h> include file is wrong - it
    sets SUNOS to "41" iff it sees "_sys_types_h" defined (<sys/types.h> is
    previously included).  But <sys/types.h> defines "__sys_types_h" (note
    the additional underscore prepended), so as supplied, the test will fail
    and the setsid() code will not get compiled.  ppp will then exit with
    the ` perror("ppp: ioctl(TIOCSPGRP)") ' message under 4.1 or 4.1.1.
    The fix is to change the 3 instances of "_sys_types_h" in that include
    file ( <pixrect/pr_impl_util.h> ) to "__sys_types_h".

    Also, the chat.c file provided in the OSU patches chooses a lock file
    directory (/usr/spool/locks vs. /usr/spool/uucp) based on whether the
    "HDB" symbol is defined; once you've fixed the above include file, you can
    add this snippet right above the "# ifndef LOCK_DIR" (line 44 or so):

/* Hack to get OS release level */
#include <pixrect/pr_impl_util.h>
#if defined(sun) && defined(SUNOS) && SUNOS >= 41
#define HDB
#endif

(4) The OSU code supplies some scripts - fix-cua, ppp-on, unlock - that
    diddle with lock files; in their default form they all assume SunOS 4.0.x
    (i.e., they embed "/usr/spool/uucp").  They should be changed to test for
    the existance ("if [ -d /usr/spool/locks ] ... ") of the 4.1/4.1.1 HDB
    lock directory, and use if appropriate.

(5) In Karl's README file for his "how-to-use" document, he shows a script
    he uses as the login shell for a PPP login:

 #!/bin/sh
 /usr/bin/mesg n
 stty -tostop
 exec /usr/local/etc/ppp 137.175.6.2:

    It is my opinion that ppp should be started with the `-p' option (passive),
    since it is on the target side (PPP `server' if you will).  ppp can be run
    without the `-p' on the initiating side.  He later says that the ppp
    command can be run from the `ppp-on' script via something like

 ppp -v 137.175.6.3: /dev/cua &

    There is no "-v" option to `ppp'.  (I use "ppp -d 128.149.1.95: /dev/cua0 &"
    for debugging, or just plain "ppp 128.149.1.95: /dev/cua0 &")

(6) Finally, remember to turn off XON/XOFF flow control (S58) on *both* modems
    (ideally, set them to use RTS/CTS flow control - and set the serial ports
     on each end to use hardware Carrier Detect via the zs flags field in the
     kernel config file, and change "local" to "modem" in /etc/ttytab for
     those ports, so that "ttysoftcar -n" can do its thing).  In the `chat'
    program I remembered to turn XON/XOFF off for the local modem, but the
    remote office modem still had it turned on.  Auuggh!  Weirdness ensued.

    Also, though most of the routing stuff in Karl's README is correct, he
    fails to mention the ARP hack.  My office machine is this one (poseur),
    128.149.1.97.  The home SPARCstation-1+ (spunky) I have configured to be
    128.149.1.95.  On `poseur' (as in Karl's README) the link is configured to
    have the *same* IP address as the Ethernet interface:

ie0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
        inet 128.149.1.97 netmask ffffff00 broadcast 128.149.1.0
        ether 8:0:20:1:b0:65
ppp0: flags=51<UP,POINTOPOINT,RUNNING>
        inet 128.149.1.97 --> 128.149.1.95 netmask ffffff00
lo0: flags=49<UP,LOOPBACK,RUNNING>
        inet 127.0.0.1 netmask ff000000

    So, to make routing totally transparent (I run `in.routed -q' on `poseur')
    I toss the arp hack into /etc/rc.local:

if [ -f /usr/etc/arp ]; then
	arp -s spunky 8:0:20:1:b0:65 pub
fi

(Where, of course, "8:0:20:1:b0:65" is poseur's Ethernet address)

    One last thing about routing - if you don't declare the PPP interface to
    be PRIVATE (a SunOS extension) on the "server" end, the point-to-point
    route will be advertised to the world unless you are either running
    "in.routed -q" or running "gated" with a configuration file that is set
    up to not announce that interface.  Some people may not like to have
    that route advertised.  Caveat actor.

(7) One final thing; to use Karl's scripts, you need to build the `xlogout'
    program (he didn't mention that).  That comes with X11 R4 in the directory
    contrib/clients/xlogout.

That's all you need to know!  Snarf the 2 files from tut.CIS.Ohio-State.EDU,
unbundle them, apply the 2 patch files, read this message again, and start
installing with the Readme.streams file (being aware of (1) and (2) above).

	- Greg Earle
	  Sun Microsystems, Inc.
	  earle@poseur.JPL.NASA.GOV
	  earle@Sun.COM

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 91 17:37:55 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!verber@ucsd.edu  (Mark Verber)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: NFS for Mac...
There are MacOS native implimentations sold by Intercon and by TWG.
IMHO the product from Intercon is nicer.  I seem to recall that the
Intercon price is under $300.

Cheers,
Mark
-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 91 21:17:55 GMT
From:      fernwood!portal!cup.portal.com!jbartas@uunet.uu.net  (John A Bartas)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Monitoring Ethernet traffic with a simple Ethernet card
I could really use the Packet Driver based Netwatch, but, alas I have no
FTP access to the net. Could some kind soul give me a 2400 baud phone
number where I could get it with Kermit?

Also, is there a contact person at Harvard who is activly maintaining 
PCIP? I willl want to add SNMP interpreting to Netwatch (if it's not 
already there) and would like to send the mods back to Netwatch's
keepers.

Thanks in advance,

-JB-
=================================================================
John Bartas - NetPort Software       |   "We have met the enemy, 
jbartas@cup.portal.com (415)961-1715 |     and he is us." -Pogo
-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 91 00:14:03 GMT
From:      mips!smsc.sony.com!tucker@apple.com  (Tim Tucker 817)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: LAT
> - LAT causes less of a burden on the CPU and the network
>       "In preliminary test using KI Research's KiNet, DR Labs found
>       the DEC's LAT protocol imposed lower overhead on both the host
>       CPU and the network than TELNET.  For example, with 45 active
>       TELNET session on a Mips M/120-5 system, the CPU had zero
>       percent idle time, meaning that it was overload, and only 4.4
>       percent of the network bandwidth was utilized. With 64 active
>       LAT sessions to the same machine, the CPU was still 50 percent
>       idle, and only 2 percent of the network bandwidth was
>       utilized. This difference is due in large part to the fact
>       that LAT does not use the full DECnet stack, whereas TELNET
>       uses the full TCP/IP stack." (Lee Schlesinger, Digitial
>       Review, August 27, 1990)

Hmmm, in theory LAT is cheaper than TCP/IP, but I wonder if Digital Review
was comparing apples and oranges?

Most likely the TCP/IP implementation was based on BSD.  That means the user
space BSD telnet/rlogin daemons are used.  These daemons, I'm not knocking
them, cause a very heavy context switch burden under high multi-user loads.

Several years ago I worked a complete kernel implementation of both telnet
and rlogin for a BSD based system (the Gould UTX/32 2.0 OS).  It turned out
to be pretty easy.  We used the public domain reference code that has been
on the archives for years as an example on how to get started.  The result
was exactly what you would expect.  We went upto 128 users, I think, during
QA tests and still meet our application load requirements (bid requirements).

It would be interesting to see how these LAT kernel stacks compare against
a lean kernel implementation of TELNET or RLOGIN.

Tim Tucker
tucker@smsc.sony.com
-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 91 02:27:18 GMT
From:      magnus.ircc.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!news-server.csri.toronto.edu!utzoo!henry@tut.cis.ohio-state.edu  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: LAT
In article <1991Jan11.170417.1732@yogi.fhhosp.ab.ca> henry@yogi.fhhosp.ab.ca writes:
>I can't comment from a technical point of view, but from a real-world
>user's point of view, LAT has one distinct advantage - it handles
>buffering in a non-annoying way.  Control-C's are have very little
>latency as compared to TELNET.

Be careful to distinguish between the protocol and the implementations.
As I understand it, there is no reason in the TELNET *protocol* why
interrupts should have any significant latency, although getting it right
in the *implementation* is subtle and many implementors ignore the issue.

>If you're considering buying a terminal server, I'd buy one with both..

I'd test the TELNET latency instead.
-- 
If the Space Shuttle was the answer,   | Henry Spencer at U of Toronto Zoology
what was the question?                 |  henry@zoo.toronto.edu   utzoo!henry
-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 91 06:24:43 GMT
From:      uokmax!d.cs.okstate.edu!minich@apple.com  (Robert Minich)
To:        tcp-ip@nic.ddn.mil
Subject:   PPP != SLIP; PPP != SLIP++
by fks@FTP.COM (Frances Selkirk):
|>  PPP is a newer protocol, designed to get around problems in SLIP.
| 	
| Specifically, PPP masks characters (in a given range) that a modem 
| might interpret as control characters and masks them. It transmits the
| masked character preceded by a character which signals to PPP that the 
| following character is masked. The receiving PPP implementation then 
| decodes the masked character. Because of this, PPP can actually be somewhat
| slower than SLIP, but it is more dependable. Assumably, that dependability
| should save you time in the long run.

Well, PPP does a bit more than that. :-) More specifically, it fills in
tons of deficiencies of SLIP. PPP handles issues such as passing multiple
protocols (eg, DECNET, AppleTalk, <fill in you vendor>, etc.),
tracking the quality of the PPP link, authentication, option
configuring, etc. One important example is having, say, a dialup machine
using PPP to obtain an IP address.
  As far as raw speed, PPP has the extra overhead of the PPP link layer
packet while SLIP is just raw IP with _NO_ link layer. If speed is a big
concern, then get a faster line to talk over. :-) Seriously, even with
some excellent compression techniques for TCP, response rate over slow
lines is going to be less than ideal. Hopefully, we'll all have access to
reasonable data lines by the year <????> and that issue will be moot. 
-- 
|_    /| | Robert Minich            |
|\'o.O'  | Oklahoma State University| "I'm not discouraging others from using
|=(___)= | minich@d.cs.okstate.edu  |  their power of the pen, but mine will
|   U    | - "Ackphtth"             |  continue to do the crossword."  M. Ho
-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Jan 91 15:32:00 -0500
From:      Bob Stewart <rlstewart@eng.xyplex.com>
To:        eagle!news@ucbvax.Berkeley.EDU
Cc:        tcp-ip@nic.ddn.mil
Subject:   Telnet rotors/connection distribution?
We have a rotary capability in our terminal servers.  That won't help you with
PC/Mac to VAX, but I can tell you what I understand of how it works.

DNS will return multiple IP addresses for the same name.  At the name server,
you pick a rotary name and give it the appropriate list of addresses, which
will then go to anything that asks to resolve that name.  I don't know of any
reasonable facility to accomplish load balancing at this point.  DNS wasn't
intended for real-time information.  The catch to this is that most
applications (like Telnet) that do name lookups are pretty stupid about
receiving multiple addresses.  I think what we do in that case is try the
first one, if that doesn't work, we go to the next, and so on.  A slightly
smarter algorith might pick one at random, or keep the whole list and use the
entries in turn for subsequent connections.  As I sit here making all this up,
it strikes me that picking one at random has its features, but that probably
violates the idea (as I recall) that the name server is supposed to put them
in the preferred order.

In your case, all of this implies that you'd probably have to be able to make
some programming changes at the end that originates the connection, requiring
either source code or an armlock on the appropriate vendors.

I'm curious to see if any other suggestions appear, or if anyone is horrified
by our use of DNS.

	Bob
-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Jan 91 14:46:42 EST
From:      ccci!tcs@uunet.UU.NET (Terry Slattery)
To:        William "Chops" Westfield <uunet!mathom.cisco.com!BILLW@uunet.UU.NET>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: PPP on STREAMS
> On the dim side, PPP is very new, so not all of its advantages are
> exploited by the implementations currently available.

While PPP solves some of the SLIP problems and is blessed with RFC status,
there is still a problem with *real* multi-vendor support.  I cannot get a
vendor supported, dial-up, serial link protocol for interconnecting
workstations, routers, and terminal servers.  When I asked vendors at
Interop about PPP, many shrugged it off.  There wasn't even the vague "We're
working on it" that was heard about OSPF, Frame Relay, and all the other new
stuff.  No-one is interested in SLIP support due to the problems already
mentioned on this list, and I agree with them.

Besides the use of connecting remote workstations to central sites, there is
a real need to build backup connections for diagnosing and working around
WAN link failures.  A few places can afford to purchase switched 56K
service, but most perfer to live with one circuit, and rely on some method
of accessing the remote equipment when this one link dies.  Multiple dial-up
links could be brought up to replace the failed link if the OSPF or IGRP
routing protocol support of multi-path were used.

One of the problems is that FDDI, Frame Relay, OSPF, and all the new stuff
is 'sexy' and is getting the majority of the resources at workstation and
router vendors.  Until enough customers start asking for PPP, they will
continue to put it on the back burner.

I don't recall ever hearing about a PPP interoperability test.  Perhaps
Interop should consider setting up a demonstration of PPP at its next
conference?

Consider this my vote for vendors to support PPP in their products.

        -tcs

Terry Slattery
Chesapeake Computer Consultants, Inc.           Network and Unix Consulting
2816 Southaven Drive                            (301) 970-8076
Annapolis, MD  21401
-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 91 13:57:54 GMT
From:      att!watmath!watserv1!utgpu!utzoo!censor!geac!torsqnt!tmsoft!mshiels@ucbvax.Berkeley.EDU  (Michael A. Shiels)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PPP on STREAMS

But does PPP negotiate things like full/half duplex connection?  If it's half
duplex do some sort of polling back and forth to say who can transmit.
-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Jan 91 22:42:21 -0500
From:      Rob Coltun <rcoltun@ni.umd.edu>
To:        csusac!csuchico.edu!walleye.ecst.csuchico.edu!garlick@ucdavis.ucdavis.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  can anyone identify this mystery box?
Ahh. An error correction unit (ECU). Lets see, it was used to insure
reliability between two endpoints of a 50kb analog (line between 316/516
IMPs or maybe between an IMP and a VDH) or something like that. It's
been a long time, it's a bit fuzzy.

---rob
-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Jan 91 21:02:06 EST
From:      "Mike StJohns" <stjohns@umd5.UMD.EDU>
To:        garlick@ecst.csuchico.edu (Jim Garlick)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: can anyone identify this mystery box?
>> 
>> I have come across a mystery piece of equipment manufactured by
>> "Acc", circa 1980, that looks like some kind of sophisticated modem.  
>> It is a box with four plug-in modules:  two "power modules" and two 
>> "logic modules".  Front panel says "ECU".  Lots of led's and toggle 
>> switches, plug out the back that says "to host/imp" and "comm line".  
>> A big piece of packing tape on the top says "Arpa".
>> 
>> Anyone know what this is or how to get ahold of Acc?

Jim, the box you have is an "Error Correcting Unit" one of the last of
a dying breed - donate it to your museum.  ECU's were used in the old
ARPANET and are still used in the MILNET to take an 1822Distant Host
interface and extend it over a standard bit-synchronous data stream.
The ECU's converted the 1822 control and data signals into an SDLC (I
think?) stream.

ACC is still on the net - you might check with Gary Krall
(krall@acc.com)

Mike
-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Jan 91 15:30:00 IST
From:      Hank Nussbacher <HANK%VM.BIU.AC.IL@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil, ripe@mcsun.EU.NET
Cc:        bitnet-2@tcsvm
Subject:   When is a link saturated?
I have recently started to monitor my links with SNMP on an hourly
basis and have seen that for my 64kb lines - the typical line utilization
is around 25%-30%.  I compute maximum link thruput for a 64kb line
as 28.1Mb/hour.  But I know that achieving 28.1Mb/hour is close to
impossible due to protocol overhead.  In addition, the lines I am
analyzing are routing IP, Decnet and Appletalk at the same time.

I previously believed that a 65% upper limit was a rational limit to
use for such a line.  That translates into 18Mb/hour (for a 64kb line)
and I figured that I may have a spike here and there above 18Mb/hour
but not anything that could be sustained.  This past week, I had 2 links
that maintained a 23Mb/hour and 25Mb/hour sustained rate for over 5
hours.  That is 88% link capacity.  This turned out to be almost all
VMNET (NJE/IP) traffic due to a reload of a 2 tapes that were restored
to the NJE spool system for dispersion throughout our network.  This
taught me that VMNET can drive a link to 88% of its total capacity, even
while other protocols are running in parallel as well as other
applications (Telnet and FTP).

This led me to check further and I found that our 9.6kb IP link to the
USA (which is hopelessly overloaded and scheduled to be upgraded to
64kb on January 14th), has been running at 70% of capacity (maximum
capacity is 101.2Mbytes per day) on average for the past 4 months.
This link is a strict IP link with just FTP, Telnet and IRC traffic.

I now have all the numbers but I am missing one crucial number.  At
what percentage of capacity should a link be upgraded?  Is it 25%?
40%? 65%?  I'd like to hear what "rules of thumb" others use in order
to determine when a link is saturated or near saturation and needs to
be upgraded.

Thanks,
Hank Nussbacher
Israel Network Information Center
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 91 20:08:40 GMT
From:      vthrc@uqvax.cc.uq.oz.au (Danny Thomas)
To:        comp.protocols.appletalk,comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.mac.comm
Subject:   *two* LocalTalk cards in a PCRouter!, bridging AppleTalk? IP?

References: <849@organpipe.UUCP>
Organization: VTHRC, University of Queensland

In article <849@organpipe.UUCP> royce@scoraz.resp-sci.arizona.edu (Royce 
Robbins) writes:
>    Advantages include:
>    Low cost - can recycle existing hardware, any new hardware is quite 
>        inexpensive and can be purchased in small increments.
>    Higher speed - using a FlashCard in the PCrouter and FlashBoxes on 
>       LocalTalk devices will give better than three times the 
 performance of 
>       AppleTalk.  FastPaths etc., won't work at FlashTalk speed.
>    Less server overhead - The whole CAP/UAB/KIP suite is unnecessary.
>    AppleShare without a dedicated AppleShare server.
> Disadvantages are:
>    No non-local AppleTalk routing.
>    Only one LocalTalk interface per PCrouter.
       ^^^
>    Changing number or type of interface requires recompiling PCroute 
with  Turbo Assembler.

One thing left out of RoyceUs list is PCRouterUs ability to support 
multiple interfaces. At present ours has a backbone ethernet and two 
LocalTalk interfaces (half a MultiGate, but for TCP/IP only), and will 
probably be expanded with two more ethernet cards. The PCRouter would then 
be handling two separate nets, each with an ethernet and AppleTalk 
segment. Does anyone know whether the code from PCBridge has been 
integrated into PCRoute yet, cause IP bridging between ethernet and 
LocalTalk for each of the nets would be more than useful in the expanded 
configuration.
N.B. the reason for running two nets into the router is that shortly(?) 
it'll be connected onto the campus backbone via the glass-fibre link into 
this building, but if there is more than one interface onto the backbone 
things become rather more expensive. It'll be doing the job of both a 
router (e.g. a WellFleet) and an ethernet/LocalTalk interface (e.g. 
FastPath), allup cost around $2000 (in Oz a FastPath cost around $4000)! 
Of course it only handles IP and I wouldn't recommend it for high traffic 
situations, but it is adequate for many departmental situations.

It is easy to configure the PCRoute software for two LocalTalk boards; the 
problem comes about when you try and load a separate FlashCard (software) 
driver for each card. The second ATALK.EXE detects that one is already 
resident and refuses to load. Sometimes life is easy and simple hacks 
work; in this case modifying the driver name embedded at the beginning of 
one of the ATALK.EXE binaries from "ATALK.SYS" to something else does the 
job! I used "BTALK.SYS", but you could probably use anything else.
    The only thing stopping you from using more cards is the inability to 
choose from more than 2 I/O addresses. Some people might also find the 
small selection of interrupt levels annoying. We are also thinking of 
modifying a board to accept a DIN-8 socket so we can use the same PhoneNet 
connectors for both Macs and PCs (you can buy them cheaply in packets of 
ten). A simple PC hardware question is whether more than one board can run 
under DMA.

Now for some questions:
 has anyone modified PCRoute to accept the LocalTalk card made by Apple. I 
borrowed one and it didn't work, nor would TOPS software recognize it. I 
assume it has a completely different programmatic interface. Presumably 
quite a bit of the AppleTalk protocol is handled by the 65xx processor on 
the card, furthermore the latest version of the software handles a network 
running AppleTalk phase 2, which might be handy for some folks. I donUt 
know whether the latest TOPS software driver does that, nor have I tried 
hard to get it to work, but would like to hear from anyone who has. I 
donUt know much about DaynaUs LocalTalk board either.

I have briefly thought about bridging AppleTalk between ethernet and 
LocalTalk interfaces. Bridging makes it looks like ethernetted and 
LocalTalkUd machines are on the same net (zone) and shouldnUt be too 
difficult cause you donUt have to support any of the higher-level 
AppleTalk protocols that deal with routing, zones, etc.,*that* sort of 
thing would be non-trivial, an exercise for the reader as they say. In 
bridging you donUt have to deal with the contents of packets (i.e. 
protocols) but merely source and destination addresses. You dynamically 
construct (and continuously maintain, since AppleTalk uses dynamically 
assigned addresses; ARP is the only protocol the bridging code has to deal 
with) a table saying which node addresses belong to which interface. You 
have to look at every packet and if the destination exists on the other 
interface, queue it for transmission out of that one. Broadcasts are 
always passed. Things get harder if you want to use the same interfaces 
for IP routing as well. When bridging you must use the LAP level to grab 
every packet from the net and inspect the addresses, but IP stuff is dealt 
with in higher levels of the protocol stack above those dealing with 
sockets. Does anyone have any thoughts, corrections, suggestions, 
experience along these lines. This could be useful to people considering 
CAP now that it supports EtherTalk.

Danny Thomas,
Vision, Touch and Hearing Research Centre
University of Queensland.

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jan 91 02:04:24 EST
From:      enger@seka.scc.com (Robert M. Enger)
To:        csusac!csuchico.edu!walleye.ecst.csuchico.edu!garlick@ucdavis.ucdavis.edu, rcoltun@ni.umd.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  can anyone identify this mystery box?


Rob:

Works on DDS circuits too!  You and I were on were on the opposite ends of one,
in the now distant past  :-)

Bob
-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 91 21:29:31 GMT
From:      HANK@VM.BIU.AC.IL (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   When is a link saturated?

I have recently started to monitor my links with SNMP on an hourly
basis and have seen that for my 64kb lines - the typical line utilization
is around 25%-30%.  I compute maximum link thruput for a 64kb line
as 28.1Mb/hour.  But I know that achieving 28.1Mb/hour is close to
impossible due to protocol overhead.  In addition, the lines I am
analyzing are routing IP, Decnet and Appletalk at the same time.

I previously believed that a 65% upper limit was a rational limit to
use for such a line.  That translates into 18Mb/hour (for a 64kb line)
and I figured that I may have a spike here and there above 18Mb/hour
but not anything that could be sustained.  This past week, I had 2 links
that maintained a 23Mb/hour and 25Mb/hour sustained rate for over 5
hours.  That is 88% link capacity.  This turned out to be almost all
VMNET (NJE/IP) traffic due to a reload of a 2 tapes that were restored
to the NJE spool system for dispersion throughout our network.  This
taught me that VMNET can drive a link to 88% of its total capacity, even
while other protocols are running in parallel as well as other
applications (Telnet and FTP).

This led me to check further and I found that our 9.6kb IP link to the
USA (which is hopelessly overloaded and scheduled to be upgraded to
64kb on January 14th), has been running at 70% of capacity (maximum
capacity is 101.2Mbytes per day) on average for the past 4 months.
This link is a strict IP link with just FTP, Telnet and IRC traffic.

I now have all the numbers but I am missing one crucial number.  At
what percentage of capacity should a link be upgraded?  Is it 25%?
40%? 65%?  I'd like to hear what "rules of thumb" others use in order
to determine when a link is saturated or near saturation and needs to
be upgraded.

Thanks,
Hank Nussbacher
Israel Network Information Center

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 91 22:26:01 GMT
From:      csusac!csuchico.edu!walleye.ecst.csuchico.edu!garlick@ucdavis.ucdavis.edu  (Jim Garlick)
To:        tcp-ip@nic.ddn.mil
Subject:   can anyone identify this mystery box?
I have come across a mystery piece of equipment manufactured by
"Acc", circa 1980, that looks like some kind of sophisticated modem.  
It is a box with four plug-in modules:  two "power modules" and two 
"logic modules".  Front panel says "ECU".  Lots of led's and toggle 
switches, plug out the back that says "to host/imp" and "comm line".  
A big piece of packing tape on the top says "Arpa".

Anyone know what this is or how to get ahold of Acc?

Jim Garlick
garlick@ecst.csuchico.edu
Jim Garlick
System Software Specialist
garlick@ecst.csuchico.edu
(916) 898-4635
-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 91 01:34:07 GMT
From:      pluto!rich@nyu.edu  (Rich Rupp)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: LAT
In article <1991Jan13.001403.2933@smsc.sony.com>, tucker@smsc.sony.com (Tim Tucker 817) writes:
> > - LAT causes less of a burden on the CPU and the network
> >       "In preliminary test using KI Research's KiNet, DR Labs found
> > [description deleted]
> Hmmm, in theory LAT is cheaper than TCP/IP, but I wonder if Digital Review
> was comparing apples and oranges?

I'm familiar with the DR Labs tests, since our VCP-1000 hardware was used
as the terminal server in both the TCP/IP/TELNET and LAT cases.

In the case of a single user on a terminal server connected into a host, LAT
wins over telnet because it's a light-weight protocol - few layers, with very
little processing required. The data buffer's can be passed off without 
telnet's requirement to look at each of the user's characters for IAC's.

If multiple sessions are from a single terminal server to the same host, the
savings is greater because of LAT's ability to multiplex data from multiple
sessions in a single packet.

We've spent a lot of time doing comparisons. We have lat implementations on
5 platforms, including system V and bsd. It is still a big win even if you
implement Rick Ace's telnet improvements.

You'll be seeing a lot of Unix box vendors offering LAT on their platforms.
It's not just for DEC compatibility. It's because in some of the new, 
multiprocessor boxes their marketing people have targeted the machines for
a large number of users and they are finding that the TCP/TELNET connections
alone drive the machines to their knees.

-- 

----------------------------------------------------------------------------
Richard L. Rupp                                           rich@pluto.dss.com
Datability Inc.                              212 807 7800, Fax: 212 807 0958
-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jan 91 09:56:32 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        mips!batman!robishaw@apple.com  (Gary Robishaw - Loral Rolm Mil-Spec)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Needed - Free sources for TFTP daemon
Long ago, wwhen 4.2 first came out with a somewhat broken TFTP, Larry Allen
(then at MIT) wrote a better one.  If you can't find it anywhere else, you
can get a copy from vax.ftp.com - pub/pc800/tftpd.shr.

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

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jan 91 11:37:49 -0600
From:      dab@berserkly.cray.com (David Borman)
To:        sgi!cjohnson%somni.wpd.sgi.com@ucbvax.Berkeley.EDU, tcp-ip@nic.ddn.mil
Subject:   Re: IP Bandwidth limits (was Re: TCP window size restriction)
> From tcp-ip-RELAY@NIC.DDN.MIL Fri Jan 11 23:00:40 1991
> Date: 10 Jan 91 23:17:18 GMT
> From: sgi!cjohnson%somni.wpd.sgi.com@ucbvax.Berkeley.EDU  (Chris Johnson)
> Organization: Silicon Graphics, Inc., Mountain View, CA
> Subject: IP Bandwidth limits (was Re: TCP window size restriction)
> References: <9101091020.AA08870@techops.cray.com>, <THOMAS.91Jan10103915@uplog.uppsala.telesoft.se>
> Sender: tcp-ip-relay@nic.ddn.mil
> To: tcp-ip@nic.ddn.mil
> 
> 
> 	Well, there is a data rate limit for TCP/IP,
> 	but it isn't window size dependent.  The
> 	sixteen bit IP id field and the 16 bit max
> 	packet length limit a particular connection
> 	to 4GB/255 seconds or about 16MB/sec.
> 
> 					cj*
> 

Gosh, thanks.  I guess I shouldn't believe my memory to memory TCP
tests (through the software loopback driver on a Cray YMP computer) that
show that I've run a TCP stream at 795 mbits/second..., and over 360
mbits/second between machines, across an 800 mbit/second channel.  (See
the article "High Speed Networking at Cray Research" in the next issue
of CCR for more info.)

There is no theoretical limit to how fast TCP can run.  Period.  End
of discussion.  However, there are physical limiting factors on how
fast a specific TCP/IP connection can run:

1) You can't go any faster than then the speed of the slowest link
   in the path.  (pretty obvious...)

2) You can't go any faster then the memory bandwidth of the slowest
   machine involved  (assuming you have a highly tuned implementation
   that only requires one pass over the data, slower if you don't).

3) You can't go any faster than the maximum TCP window offered by
   the receiver divided by the round-trip-time, because you can never
   send more than one entire TCP window per RTT.  (Once you've sent
   the entire window, you've got to wait for that ACK...)  The maximum
   TCP window is 64K-1 bytes.  With the expanded TCP window option
   (RFC 1072), the maximum TCP window is 1.07 gbits ((64K-1)*(2^14)).

Now, can we stop all these erroneous messages about limits on the speed
of TCP?

			-David Borman, dab@cray.com
-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 91 01:58:52 GMT
From:      van-bc!robinson@ucbvax.Berkeley.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   Re: LAT
In article <12578@hubcap.clemson.edu> hubcap@hubcap.clemson.edu (System Janitor) writes:
>Would anyone in this forum care to comment on these claims?
>

>*********** LAT/ TELNET comparison ***********
>
>
>- LAT causes less of a burden on the CPU and the network 
>        "In preliminary test using KI Research's KiNet, DR Labs found
>        the DEC's LAT protocol imposed lower overhead on both the host
>        CPU and the network than TELNET.  For example, with 45 active
>        TELNET session on a Mips M/120-5 system, the CPU had zero
>        percent idle time, meaning that it was overload, and only 4.4
>        percent of the network bandwidth was utilized. With 64 active
>        LAT sessions to the same machine, the CPU was still 50 percent
>        idle, and only 2 percent of the network bandwidth was
>        utilized. This difference is due in large part to the fact
>        that LAT does not use the full DECnet stack, whereas TELNET
>        uses the full TCP/IP stack." (Lee Schlesinger, Digitial
>        Review, August 27, 1990)

A good question to ask is whether LAT performs checksumming. Given that LAT
is a LAN protocol, it seems that it is quite possible that it (perhaps
optionally) does no checksumming and instead relies on the LAN to detect
and discard corrupted packets (as does ethernet). If this is the case then
it would have a natural, and arguably unfair, advantage over TCP due to the
rather CPU intensive nature of checksumming. 

I believe that checksumming is *not* a TCP option (although in practice it
is usually possible to turn it off in BSD derived implementations), but
even if it is the above comparison is less meaningful without knowing
whether both protocols were running with checksumming on or off.
-- 
Jim Robinson
{uunet,ubc-cs}!van-bc!mdivax1!robinson
robinson@mdivax1.uucp
-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jan 91 11:06:10 -0500
From:      tmallory@BBN.COM
To:        tcp-ip@nic.ddn.mil
Subject:   Re: An INTERESTING problem, Re: An INTERESTING problem

In article <9101100248.AA01030@desktalk.desktalk.com> rlg@desktalk.com
(Richard L. Gralnik) writes:
>The standard wisdom/procedure is to assign a subnet number to each remote
>office, another subnet number to each serial line, and another (or many)
>to the central site net.  We want to use an 8-bit subnet mask for the 
>obvious reasons, but the cost of this is that the serial lines become 2-node 
>subnets, thereby wasting 251 addresses (including 0 and 255) each.  Since 
>there are 20 remote sites, and the user wants redundant serial lines because 
>the network is mission-critical, we eat up 60+ subnet numbers right off the
>bat.  

Another obvious approach is to use two sizes of subnet masks. Given the
minimum usable size of two bits(00 unused, 11=broadcast, 01 and 10 the hosts),
you can get 64 trunks worth of subnets out of each subnet with an 8-bit host
space.  This is fairly efficient, and allows for use of the conventional
addressing procedure.  Of course, once you have the hierarchical subnetting
then you have the option of giving less than 254 host addresses to smaller
sites.  BBN T/20s give you this option, others probably do as well.

Paul Tsuchiya wrote a paper on assigning addresses in a hierarchical manner
that allowed for expansion of chunks of the address space without forcing host
addresses to change.  The basic idea was to assign addresses right-to-left,
starting with large masks that could be shrunk to expose more of the host
address space.  It's single most important requirement was support for
variable length subnet masks.  I'm pretty sure that it did NOT require
non-contiguous subnet masks, just a general left-to-right hierarchy.  I can't
locate the paper now, but I'm sure someone(Paul?), can supply a pointer to it.

Tracy Mallory
BBN Communications
-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 91 02:48:58 GMT
From:      sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP Bandwidth limits (was Re: TCP window size restriction)
In article <80719@sgi.sgi.com> cjohnson@pei.com (Chris Johnson) writes:
+---------------
| Well, there is a data rate limit for TCP/IP,
| but it isn't window size dependent.
+---------------

...in a zero-delay network. But in the presence of any round-trip delay,
TCP *is* rate-limited to approximately one window-size per round trip.
For example, on a maximally-configured FDDI network, the idle-net token
rotation time is 1.6 milliseconds, or "20,000 bytes". Under some reasonable
assumptions (e.g., hosts are very fast, but not infinitely so), one can
show that this will limit TCP speed to about (16/(16+20))*12.5 = 6.9 MByte/s
for a single connection between a pair of hosts (assuming all other hosts
are idle).

By sending more than the usual two ACKs per window (usual anti-"silly window"
strategy), one can get ACKs for data close to the "end" of the window sent
with the same token rotation as the data itself, and data rates closer to
10-12 MB/s could be obtained. (Even with very fast hosts and FDDI interfaces,
I assume a few packets near the end on the trasmit burst will not get ACKed
in time to go out with the "current" token rotation.)

Of course, most FDDI rings will not be "maximally" configured, and will
have less idle-ring token delays. But there are other media with substantial
delay-bandwidth products (e.g. long-haul lines, satellites), and this is
why RFC 1072 was promulgated.

+---------------
| The sixteen bit IP id field and the 16 bit max
| packet length limit a particular connection
| to 4GB/255 seconds or about 16MB/sec.  | cj*
+---------------

...iff all packets have an initial TTL of 255. If one knows (somehow) that
the true needed TTL is lower (it's usually *much* lower!), the TTL rate
limit is higher (usually *much* higher). For example, a TTL of 15 seconds
yields a TTL-limited rate of ~286 MB/s.


-Rob

-----
Rob Warnock, MS-9U/515		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311
-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jan 91 11:44:13 -0500
From:      barns@gateway.mitre.org
To:        sdrc!mustard@uunet.uu.net (Sandy Mustard)
Cc:        tcp-ip@nic.ddn.mil, barns@gateway.mitre.org
Subject:   Re: Latest FTP RFCs
Please start with RFC 1123's chapter on FTP and work backwards from
there through the references.  As I recall it, we left this somewhat
intentionally open to people inventing other reply codes where there
is cause (a judgment call, but not meant to allow new codes with the
same semantics as old ones).  Also, the RFC 959 list is slightly
defective here and there.  Feel free to send me mail if you want to
discuss specific cases.  I spent considerable time pondering reply
codes when RFC 1123 was being written and I helped stir up some
discussions.  With a little luck, I may remember what happened and why.
In case of desperation, I have the email discussions stashed somewhere.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org
-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jan 91 08:34:40 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Getting/setting the time across slow links.
Is there a protocol that will allow the setting of system time across
a link that may have long (but hopefully consistant) delays??
I am looking for something that will determine average rtt and then
adjust the time it receives accordingly.

Any suggestions??

bill

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jan 91 09:36:21 CST
From:      mark@telesys.ncsc.navy.mil (Mark L. Williams)
To:        tcp-ip@nic.ddn.mil
Cc:        702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu
Subject:   Re:  Getting/setting the time across slow links.
There's an article in December 1990 Unix Review on Network Time Protocol
(NTP) referencing RFC 1129; RFC by David L. Mills, article by Rob Kolstad.
Perhaps one or the other can provide what you need.

Mark

Mark L. Williams
Naval Coastal Systems Center
Code 7630
Panama City, FL 32405
(904)235-5153
mark@telesys.ncsc.navy.mil
-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 91 03:45:26 GMT
From:      sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: More on TCP Performance Limits
In article <9101111221.AA08912@garuda.sics.se> craig@SICS.SE
(Craig Partridge) writes:
+---------------
| There seems to be a lot of misinformation running around.
| The end-to-end performance of a TCP connection is limited by two different
| factors:
|     (1) The window size...
|     (2) The sequence space size...
+---------------

And (at least) one more:

      (3) The underlying IP ID space size.

Item #1 depends on the round-trip time, #2 and #3 do not.

As Chris Johnson noted, you can only send <#_of_distinct_IP_IDs> (64K) times
<max_IP_pkt_size> (64K) bytes per TTL, where the TTL has to at least be large
enough to cover your number_of_hops, and in any case shouldn't be smaller
than 15 since that's the suggested default reassembly timeout. With TTL=255,
that's 16.8 MB/s; for TTL=15, that's 286 MB/s.

Why be concerned about reassembly timeouts? Because to get the data rates
noted above, you have to send max-sized IP packets (64 Kbytes), which implies
fragmentation on almost all current media (except HiPPI). (Also means TCP
MSS = 64K, but that's the least of the worries.) And you don't want later
fragments being confused with earlier ones. If your IP holds onto frags for
a minimum of 15 seconds (see RFC 791, Page 27), that puts an effective minimum
on TTL of 15 seconds, at least for the purposes of the rate-limit calculation.

But RFC 1122 says [page 35]:

                 A fixed value [of TTL] must be at least big enough for the
                 Internet "diameter," i.e., the longest possible path.
                 A reasonable value is about twice the diameter, to
                 allow for continued Internet growth.

And further [page 57]:

         There MUST be a reassembly timeout.  The reassembly timeout
         value SHOULD be a fixed value, not set from the remaining TTL.
         It is recommended that the value lie between 60 seconds and 120
         seconds...

         DISCUSSION:
              The IP specification says that the reassembly timeout
              should be the remaining TTL from the IP header, but this
              does not work well because gateways generally treat TTL as
              a simple hop count rather than an elapsed time.  If the
              reassembly timeout is too small, datagrams will be
              discarded unnecessarily, and communication may fail.  The
              timeout needs to be at least as large as the typical
              maximum delay across the Internet.  A realistic minimum
              reassembly timeout would be 60 seconds.

Using the suggested 60 seconds produces a IP ID re-use rate-limit of 71.6 MB/s,
120 seconds gives 35.8 MB/s.

So the IP ID rate-limit (item #3) is also a serious issue in gigabit/sec TCP
networking. Some of the ideas in RFC 1185 may be helpful here, but in the
presence of fragmentation, TCP options cannot be recognized in any fragment
except the first. The solution may be to use some form of MTU discovery, then
send *all* TCP segments with the "Don't Frag" bit on the in the IP packets
(avoiding reassembly aliasing), *let* the IP IDs wrap as they will, and use
the timestamp mechanisms of RFC 1185 to sort out potential duplicates.


-Rob

-----
Rob Warnock, MS-9U/515		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311
-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Mon 14 Jan 91 12:10:02-PST
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        eagle!news@ucbvax.Berkeley.EDU
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Telnet rotors/connection distribution?
The folks at CMU did this by causing the domain system to repsond
to address lookup requests for a given name with the ip address of
the least loaded system.  The repsonse include a zero time-to-live,
forcing an address lookup everytime someone tried to connect.

The IETF was petitioned to allow such zero TTLs, and various terminal
server vendors were prodded to support them, both of which happened.

BillW
-------
-----------[000200][next][prev][last][first]----------------------------------------------------
From:      lefty@TWG.COM
To:        tcp-ip@nic.ddn.mil
Subject:   Re: LAT
<van-bc!robinson@ucbvax.berkeley.edu> writes:
>A good question to ask is whether LAT performs checksumming. Given that LAT
>is a LAN protocol, it seems that it is quite possible that it (perhaps
>optionally) does no checksumming and instead relies on the LAN to detect
>and discard corrupted packets (as does ethernet). If this is the case then
>it would have a natural, and arguably unfair, advantage over TCP due to the
>rather CPU intensive nature of checksumming.

LAT does _not_, in fact, perform any checksumming of the data streams.  It
should probably be pointed out that LAT, unlike IP, was originally designed
specifically with an Ethernet environment in mind; checksumming in those
circumstances was probably felt to be unnecessary.
 
>I believe that checksumming is *not* a TCP option (although in practice it
>is usually possible to turn it off in BSD derived implementations), but
>even if it is the above comparison is less meaningful without knowing
>whether both protocols were running with checksumming on or off.

Of course, with telnet, checksumming is occurring at both the IP and TCP
layers of the protocol.  LAT, having been derived independently of any
particular protocol stack, doesn't incur this kind of overhead...

-
David N. Schlesinger (lefty@twg.com)   |
Sr. Software Engineer                  |  "And you may ask yourself,
The Wollongong Group                   |     'How do I work this?'"
415/962-7100                           |
-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jan 91 12:56-0500
From:      Andrew.S.Hooper@QueensU.CA
To:        Discussion of BITNET II<BITNET-2@TCSVM.BITNET>, Hank Nussbacher<HANK@VM.BIU.AC.IL>, tcp-ip@nic.ddn.MIL, ripe@mcsun.EU.NET
Subject:   When is a link saturated?
It depends on the services you are trying to offer over the link. If it is
batch-type stuff like VMNET and FTP, you need to think mostly about throughput:
Are the VMNET queues being cleared in a reasonable time, say 1 day after a
3 hour interruption?

When you try to mix batch and interactive services on the same link you can
really have trouble with heavy loads. For interactive service, I think
instantaneous IP queue sizes are more relevant than total data rate,
particularly on a slow link. Consider the impact on a character-at-a-time
telnet session when an FTP transfer starts up. FTP will send an 8k byte
buffer, which will be queued up on the serial link as a sequence of IP
datagrams. At 64 kbps, it will take a mimimum of one second to send this
sequence on the link (7 seconds at 9.6). Most IP routers don't consider the
type-of-service field when queueing datagrams, so any incoming Telnet
datagrams will go to the end of the queue and will suffer noticeable delay.
Eventually the FTP connection will notch down to match the link speed, but
the mechanism needs time to take hold. The large variations in delay make
its impact more severe.

The "slow-start" mechanism should ameliorate the queue problem, but in
practice it seems not to be sufficiently widespread to help much. Line-mode
Telnet support would also help.

We have a 19.2 kbps link. The batch services like VMNET and NNTP can at times
drive it at 90% for three hours at a stretch.
-----
Andy Hooper         Queen's University, Kingston, Canada
-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Jan 91 15:42 H
From:      <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   rfc1119 network time protocol (NTP) implementation

Hi,
        Does anybody know is there an implementation for NTP version 2?
If it is PD software, could you please tell me where can I ftp it?
        Thanks a lot.

- beng hang (email:taybengh@nusdiscs)
-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jan 91 13:15:17 PST
From:      mcmahon@TGV.COM (John 'Fast-Eddie' McMahon)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/Connect II and MultiNet (Part II)
In article <663619006.888386.MCMAHON@TGV.COM> I Wrote:
#The problem with MultiNet and TCP/Connect II FTP seems to be in the TCP/Connect
#parser that reads the LIST FTP command back from the MultiNet server.  If you
#switch the host type from "Automatic" to "Generic" when establishing the
#connection it will work just fine.

Intercon informed me that this would be fixed in Release 1.0.5 of their
software, to be released in February.

--
John 'Fast-Eddie' McMahon    :    MCMAHON@TGV.COM    : TTTTTTTTTTTTTTTTTTTTTTTT
TGV, Incorporated            :                       :    T   GGGGGGG  V     V
603 Mission Street           : HAVK (abha) Gur bayl  :    T  G          V   V
Santa Cruz, California 95060 : bcrengvat flfgrz gb   :    T  G    GGGG   V V
408-427-4366 or 800-TGV-3440 : or qrfgeblrq ol znvy  :    T   GGGGGGG     V
-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jan 91 10:41:07 EST
From:      hsw@sparta.com (Howard Weiss)
To:        csusac!csuchico.edu!walleye.ecst.csuchico.edu!garlick@ucdavis.ucdavis.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  can anyone identify this mystery box?
The ECU was an Error Control Unit that allowed hosts to be separated from
their respective IMPs (now packet switch nodes) on the ARPANET/MILNET.
Using the distant host interface, the host to packet switch interface
could only drive a signal about 2000 feet (which was a great improvement
over the 30 feet that was achievable with local host interfaces).  The
ECU allowed a host to be separated by a larger distance and still look
like it was a locally attached host.  Basically, the ECU converted the
ARPANET 1822 interface signalling into an SDLC which was then recoverted
into 1822 by the distant end ECU.  ECU's were always used as pairs - one
on the host end and one on the IMP end.

ACC at the time was Associated Computer Consultants and they are now
known as Advanced Computer Communications.  Sorry, don't have a phone
number.

Howard Weiss

SPARTA, Inc.
Columbia, MD 21046
hsw@sparta.com

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 91 07:42:00 GMT
From:      TAYBENGH@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   Re:  8K limitation and sendto() in Sun UDP-based RPC


Hi,
        The 8K limitation in Sun UDP-based RPC is imposed by socket library.
Since it is possible to increase the socket send/recv buffer size by calling
setsockopt() up to a certain limit (in SunOS4.1, the limit is around 52000),
do you think it is wise to incooprate this into SunRPC library to circumvent
the 8K limitation?
        Thanks a lot for your help.

p/s: will I have problems port it over to platfroms other than BSD if I use
     setsockopt()? Is this function widely supported? I know it is NOT
     supported in WIN/TCP for 3B15 in my site.

Another Note: Most of the responses I got suggest if large amount of data
              is expected in using Sun RPC, use TCP-based instead of UDP-based.

- Beng Hang (email: taybengh@nusdiscs.bitnet)

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jan 91 15:48:26 PST
From:      tcpdump@ee.lbl.gov
To:        tcp-ip@nic.ddn.mil, sun-nets@umiacs.umd.edu, sun-spots@rice.edu, unix-wizards@sem.brl.mil
Subject:   New tcpdump and Berkeley Packet Filter available for anonymous ftp

A new release of tcpdump, 2.0, is now available for anonymous ftp
from ftp.ee.lbl.gov.  This version should run on almost any BSD
(or BSD-like) system, not just on Suns.  It has been tested on:

   - Sun OS 3.x & 4.x on Sun-3s & Sun-4s
   - HP 9000/3xx's running Utah's 4.3BSD.
   - Ultrix on Vaxes & DECstations (Ultrix support courtesy of Jeff
     Mogul of DECWRL)
   - IBM RT's (enetfilter support courtesy of Rayan Zachariassen of CA*Net).

In addition, this release includes a new, portable, kernel packet
capture/filter system, the Berkeley Packet Filter (BPF).  BPF is similar
to the `enet' filter distributed with 4.3BSD but is substantially more
efficient.  It is also a (vastly more efficient) alternative to the
`Streams' NIT abortion in Sun OS 4 that, unlike NIT, lets you monitor
your own outbound traffic.  Both tcpdump and BPF are available via
anonymous ftp from ftp.ee.lbl.gov (128.3.254.68), in the compressed 
tarchive tcpdump-2.0.tar.Z.  (Remember to set binary mode.)

Here is a teaser from the README:

 - A packet dumper has been added (thanks to Jeff Mogul of DECWRL). 
   With this option, you can create an architecture independent binary 
   trace file in real time, without the overhead of the packet printer.  
   At a later time, the packets can be filtered (again) and printed.

 - BSD is supported.  You must install BPF in your kernel.  
   Since the filtering is now done in the kernel, fewer packets are
   dropped.  In fact, with BPF and the packet dumper option, a measly
   Sun 3/50 can keep up with a busy network.

 - Compressed SLIP packets can now be dumped, provided you use our
   (soon to be released) SLIP software and BPF.  These packets are 
   dumped as any other IP packet; the compressed headers are dumped 
   with the '-e' option.

 - Tcpdump is smarter about choosing an interface.  Without '-i', the
   system interface list is searched for the lowest numbered, "interesting"
   network interface.

 - Machines with little-endian byte ordering are supported (thanks to
   Jeff Mogul).

 - Ultrix is supported (also thanks to Jeff Mogul).

 - IBM RT and Stanford Enetfilter support has been added by
   Rayan Zachariassen <rayan@canet.ca>.  Tcpdump has been tested under
   both the vanilla enetfilter interface, and the extended interface 
   present in the MERIT version of the enetfilter.

 - TFTP packets are now printed (requests only).

 - BOOTP packets are now printed.

 - SNMP packets are now printed (thanks to John LoVerso of Xylogics).

Problems, bugs, questions, desirable enhancements, etc., should be sent
to the email address "tcpdump@ee.lbl.gov".  We welcome all such feedback.

 - Steve McCanne (mccanne@ee.lbl.gov)
   Craig Leres (leres@ee.lbl.gov)
   Van Jacobson (van@ee.lbl.gov)
-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jan 91 13:21:04 EST
From:      Greg Vaudreuil <gvaudre@NRI.Reston.VA.US>
To:        ietf@venera.isi.edu, tcp-ip@nic.ddn.mil
Subject:   Internet Mail Extensions Working Group

A new working group has been created in the Internet Engineering Task
Force to extend the current suite of Internet mail protcols.  This
group resulted from an informal discussion at the December 1990 IETF
meeting in Boulder Colorado.  The group intends to develop and
standardize a specification(s) to extend the internet mailer
protocols, RFC 821 and RFC 822 to facilitate multiple character sets
and multi-media mail.

Preliminary discussion focused on eliminating the 7bit and the line
length restriction in RFC 821 SMTP.  Other changes include
standardizing a header and message format for specific message body
parts.

Below is the charter for the new group.  The next meeting is intended
to be at the March IETF Meeting in St. Louis.  Participation is
encouraged on the working group mailing list.  Developers and
implementors of multi-media mail systems as well as developers of
international character set based mail agents are encouraged to join
this important standardization effort.

Greg Vaudreuil
Working Group Chair.


Internet Mail Extensions (smtpext)

Charter

Chair(s):
     Gregory Vaudreuil, gvaudre@nri.reston.va.us

Mailing Lists:
     General Discussion:  ietf-smtp@dimacs.rutgers.edu
     To Subscribe:  ietf-smtp-request@dimacs.rutgers.edu

Description of Working Group:

     The SMTP extensions working group is chartered to develop
     extensions to the base SMTP protocol (RFC821) and the format of
     Internet mail (as defined in RFC 822).

     Among the extensions to be considered to SMTP are the
     elimination of the line length and 7 bit restrictions to allow
     the sending of arbitrary binary information.  Among the
     extensions to RFC 822 are the definition of specific standard
     body parts and encoding formats.  Body parts are intended to
     allow the sending of arbitrary binary files, the sending of
     structured mail, and the use of alternate encoding of
     international character sets for mailers that do not understand
     eight bit characters.

Goals and Milestones:

Mar 1991      Rewrite RFC 1154 to include specific types of body parts
              and encodings.
Mar 1991      Write a document for the sending of 8 bit character sets
              through 7 bit mailers with the TEX-HEX encoding scheme.
Mar 1991      Write a document specifying the elimination of line
              length restrictions and eliminating the 7 bit
              restrictions in SMTP.
Jul 1991      Submit the three edited documents as Internet-Drafts.
Oct 1991      Discuss distribution and deployment of mailers and user
              interfaces complying with the new SMTP and Message
              format.
Oct 1991      Finalize the 3 above documents.  Submit a recommendation
              to the IESG to forward the 3 above documents to the IAB
              and RFC Editor as Proposed Internet Standards.



                                   1
-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jan 91 14:39:00 EST
From:      CHRISTOPHER TANNER <TANNERC@CRL.AECL.CA>
To:        tcp-ip@NIC.DDN.MIL
Subject:   Running WIN/TCP (VMS) FTP from batch
I am using WIN/TCP 5.1 on VMS 5.4 and am trying to run FTP inside a command
procedure (in a batch job). I would like to create a command file for FTP in
inside the command procedure on a temporary file (with a "unique" name) and
pass it to FTP. I have tried putting the 'commandfile' command on the FTP
command line with little success. I cannot get FTP to pick up the username
and password properly.

Putting the 'commandfile' command in FTP's regular input (ie in a line right
after the FTP line) will not work, since I want to pass the file name in a
logical.

I would like to be able to execute something like:
   FTP commandfile 'ftpcommands'

rather than
  $ FTP -n hostname
   username
   password
   commandfile filename.txt


THanks for your help

Chris Tanner                          TANNERC@CRL.AECL.CA
AECL Research
-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jan 91 18:29:18 -0500
From:      backman@ftp.com  (Larry Backman)
To:        Jeremy Greene <greene@coral.com>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: inet_ntoa()

    
    
    The Sun man pages has the following definition:
     
        char *inet_ntoa( ipAddr )
        struct in_addr ipAddr;
     
    which use to work, instead of
     
        char *inet_ntoa( ipAddr )
        struct in_addr *ipAddr
    
    which now works. Has anyone else had this problem?
     
    JAG
    



   JAG of ex-Interlan fame?

		

			Larry

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jan 91 15:33:45 EST
From:      Bob Stratton <dsc3rjs@nmdsc20.nmdsc.nnmc.navy.mil>
To:        usc!jarthur!nntp-server.caltech.edu!todd@ucsd.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   How to spool print jobs to term srv (ip address/port)
   >From tcp-ip-RELAY@NIC.DDN.MIL Sun Jan 13 09:33:16 1991
   Date: 11 Jan 91 23:27:55 GMT
   From: usc!jarthur!nntp-server.caltech.edu!todd@ucsd.edu  (Todd_Booth)
   Organization: California Institute of Technology, Pasadena
   Sender: tcp-ip-relay@nic.ddn.mil

   But I can't find any software to run at the host end that will spool
   printer data to a given ip address (term server) and port.  Has anyone
   done this before or know how?

Try getting the file "tcpcon" from cisco's ftp host (ftp.cisco.com?),
it does just what you are describing (I think.) Bill, can you fill us
in on the proper host name???

Bob Stratton		| strat@ai.mit.edu       [Internet]
Stratton Systems Design	| dsc3rjs@vmnmdsc        [BITNET,only if you must]
			| +1 703 823 MIND        [PSTNet]
Disclaimer: The above opinions are mine alone - Who else would want them?
-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Jan 91 23:42 H
From:      <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  8K limitation and sendto() in Sun UDP-based RPC

Hi,
        The 8K limitation in Sun UDP-based RPC is imposed by socket library.
Since it is possible to increase the socket send/recv buffer size by calling
setsockopt() up to a certain limit (in SunOS4.1, the limit is around 52000),
do you think it is wise to incooprate this into SunRPC library to circumvent
the 8K limitation?
        Thanks a lot for your help.

p/s: will I have problems port it over to platfroms other than BSD if I use
     setsockopt()? Is this function widely supported? I know it is NOT
     supported in WIN/TCP for 3B15 in my site.

Another Note: Most of the responses I got suggest if large amount of data
              is expected in using Sun RPC, use TCP-based instead of UDP-based.

- Beng Hang (email: taybengh@nusdiscs.bitnet)
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 91 13:14:19 GMT
From:      gd@aprm (Gary Dunn)
To:        comp.protocols.tcp-ip
Subject:   help with mail headers

Text: 

Where can I go for help in fixing my mail headers?  I don't get Internet
news, just mailing lists via DDN.  (I need to fix things so that my
 From: line looks like <aprm%gd@shafter-emh2.army.mil> or 
<shafter-emh2.army.mil!aprm!gd> or something like that).

 
Gary Dunn, USARPAC DCSRM IMO                 |
Ft. Shafter LAN: aprm%gd               _   _ |
DDN: aprm%gd@shafter-emh2.army.mil    /.\ /.\|
Work phone:  (808) 438-2716           \_/|\_/
FAX: (808) 438-8954                      |
                                        /
 
        Real programmers don't comment their code.  If it was
        hard to write, it should be hard to understand, and
        even harder to modify.

 --- End of Message -----------

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 91 13:34:40 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Getting/setting the time across slow links.

Is there a protocol that will allow the setting of system time across
a link that may have long (but hopefully consistant) delays??
I am looking for something that will determine average rtt and then
adjust the time it receives accordingly.

Any suggestions??

bill

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 91 15:24:00 GMT
From:      eru!hagbard!sunic!erbe.se!prc@bloom-beacon.mit.edu  (Robert Claeson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: LAT

In article <1991Jan11.170417.1732@yogi.fhhosp.ab.ca>, henry@yogi.fhhosp.ab.ca writes:

|> I can't comment from a technical point of view, but from a real-world
|> user's point of view, LAT has one distinct advantage - it handles
|> buffering in a non-annoying way.  Control-C's are have very little
|> latency as compared to TELNET.

What terminal server have you been using? The Annex IIe from Xylogics that
I occasionally use doesn't have any noticeable delay in handling control C.
Whenever I type it, the output stops immediately.

-- 
Robert Claeson                  |Reasonable mailers: rclaeson@erbe.se
ERBE DATA AB                    |      Dumb mailers: rclaeson%erbe.se@sunet.se
Jakobsberg, Sweden              |  Perverse mailers: rclaeson%erbe.se@encore.com
Any opinions expressed herein definitely belongs to me and not to my employer.
-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jan 91 21:44:48 CST
From:      slevy@poincare.geom.umn.edu
To:        tcp-ip@nic.ddn.mil
Subject:   NSFNET usage
Has anyone surveyed recently to see how the bandwidth of NSFnet or some other
large chunk of Internet is being used, as in per-application-protocol packet or
byte counts?  For example, how much traffic is devoted to FTP, SMTP, NNTP?
Do we still suffer from floods of DNS traffic due to resolver or application
bugs?  How many single-character telnet/rlogin packets traverse the backbone?

    Stuart Levy, Geometry Group, University of Minnesota
    slevy@geom.umn.edu

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 91 16:06:10 GMT
From:      tmallory@BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: An INTERESTING problem


In article <9101100248.AA01030@desktalk.desktalk.com> rlg@desktalk.com
(Richard L. Gralnik) writes:
>The standard wisdom/procedure is to assign a subnet number to each remote
>office, another subnet number to each serial line, and another (or many)
>to the central site net.  We want to use an 8-bit subnet mask for the 
>obvious reasons, but the cost of this is that the serial lines become 2-node 
>subnets, thereby wasting 251 addresses (including 0 and 255) each.  Since 
>there are 20 remote sites, and the user wants redundant serial lines because 
>the network is mission-critical, we eat up 60+ subnet numbers right off the
>bat.  

Another obvious approach is to use two sizes of subnet masks. Given the
minimum usable size of two bits(00 unused, 11=broadcast, 01 and 10 the hosts),
you can get 64 trunks worth of subnets out of each subnet with an 8-bit host
space.  This is fairly efficient, and allows for use of the conventional
addressing procedure.  Of course, once you have the hierarchical subnetting
then you have the option of giving less than 254 host addresses to smaller
sites.  BBN T/20s give you this option, others probably do as well.

Paul Tsuchiya wrote a paper on assigning addresses in a hierarchical manner
that allowed for expansion of chunks of the address space without forcing host
addresses to change.  The basic idea was to assign addresses right-to-left,
starting with large masks that could be shrunk to expose more of the host
address space.  It's single most important requirement was support for
variable length subnet masks.  I'm pretty sure that it did NOT require
non-contiguous subnet masks, just a general left-to-right hierarchy.  I can't
locate the paper now, but I'm sure someone(Paul?), can supply a pointer to it.

Tracy Mallory
BBN Communications

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 91 16:23:26 GMT
From:      max4.llnl.gov!scooper@lll-winken.llnl.gov  (Steve Cooper)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PPP on STREAMS
>
>I don't recall ever hearing about a PPP interoperability test.  Perhaps
>Interop should consider setting up a demonstration of PPP at its next
>conference?

At Interop '90 there was a small "Solutions Showcase (tm) Demonstration"
on PPP.  It had cisco, Telebit, 3Com, and Network Systems communicating
at 56K bps synchronous and Telebit, INTERACTIVE, and Xylogics communicating
at 9.6K and 19.2K bps asynchronous.  There is also a nice little article
discussing SLIP and PPP in the January 7, 1991 _UNIX Today!_.

>Consider this my vote for vendors to support PPP in their products.
>
>        -tcs
>

You can add my vote, too.

--
---------------------------------------+--------------------------------
Stephen P. Cooper                      | scooper@aracmax1.llnl.gov (now)
who works at but does not represent    | cooper10@llnl.gov (soon)
Lawrence Livermore National Laboratory |
-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Mon 14 Jan 91 21:44:14-EST
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        rlg@desktalk.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Elements of Networking Style
Richard Gralnik
and other possibly interested parties
(but not, of course, jqj)--

I hope and trust it does not constitute Abuse of List to explain in
public why Simon&Schuster told you The Book was "on back order";
after all, this is a correction of inadvertantly misleading prior
material, Not A Solicitation To Buy.

At any rate, since I knew that either there was an error somewhere
or Simon&Schuster had hired an accountant from the movie industry,
based on having received royalties for only around half the number of
copies in the print run, I just spent what felt like all day on the
phone and learned a few interesting things:

1. When Simon&Schuster acquired Prentice-Hall, somebody gave 800
Information Simon&Schuster's number in Prentice-Hall's name, BUT
Prentice-Hall still does have its own 800 numbers.  (Since it would
presumably be improper for me to post the latter, I suggest that IF
anybody happened to be trying to get The Book and couldn't find one of
the stores that still carry it, the thing to do would be to call the
advertized Prentice-Hall 800 number and if Simon&Schuster answers,
insist on being transferred to Prentice-Hall--or, if going
through a friendly bookstore, alert them to the necessity of talking
to Prentice-Hall, not Simon&Schuster.)

2. Simon&Schuster and Prentice-Hall "dual list" some titles;
Simon&Schuster personnel are SUPPOSED to refer people to Prentice-Hall
when Simon&Schuster shows THEY are out of stock for such titles,
since Prentice-Hall isn't necessarily out also--as they aren't w/r/t
The Book, as it happens.

3. Simon&Schuster's database is garbaged even w/r/t the binding that
corresponds to the ISBN (0-13-268111-0 is the paperback, not the
hardcover), as well as w/r/t availability.

4. Prentice-Hall apparently won't take personal orders over the
phone (just orders from stores that have accounts), and their Mail
Order department doesn't have an 800 number, but if you ask for Mail
Order's address when (well, IF and when) you get through to the
Prentice-Hall Customer Service 800 number, you should be able to get it.
(Again, I don't want to use the List for commercial benefit--however
pathetically small the royalties are--so won't post the address here,
though presumably I wouldn't have to be so punctilious as to decline
to respond to direct inquiries.)

5. Even Prentice-Hall thinks the hardcover's out of stock, which doesn't
correspond to the numbers I've seen so I might still be interested
in whether anybody on the List happens to know Art Buchwald's lawyer ...
but, then, they've raised prices so many times that I'd scarcely expect
anybody to spring for the hardcover anyway.  (And please be aware that
I ALWAYS wanted them to price The Book for the "mass", rather than the
textbook, market--not for fear of later being kvetched at by those who
didn't pay proper attention to the subtitle and felt they'd not gotten
what they'd bargained for, but just because it would have been
gratifying to get to a second printing even if it made the royalties
bathetic rather than pathetic--but authors don't get to set prices.)

thanks for your interest,
thanks to those who were kind enough to post positive comments,
apologies--or, more accurately, regrets--for the FUs,
and
cheers to all,
     map
-------
-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jan 91 15:40:24 +0100
From:      prindevi@inria.inria.fr (Philippe-Andre Prindeville)
To:        ripe@mcsun.eu.net, tcp-ip@nic.ddn.mil
Cc:        bitnet-2@tcsvm.bitnet
Subject:   Re:  When is a link saturated?
I don't think you can simplify the question to this extent.  It
depends on how bursty the traffic patterns are, and what sort
of best/worst/mean case service you want to provide.  The phone
companies use two numbers, for instance, 80% and 95% of the
service expected (or provided).  For instance, they try to
engineer the networks so that levels of quality for 80% and
95% of the calls-placed, packets routed, or whatever exhibit
a certain level of quality.

For datagram traffic, if you look at Delay vs. Throughput on
a graph, you will see that for a linear increase is Throughput,
you start to see much greater increases in Delay.  This might
not be acceptable for interactive uses.

Look at the famous "DEC-bit" paper by Raj Jain, DEC-TR-508
(if memory serves).  It is available upon request from DEC.
Don't send me mail asking how to get it.

-Philip
-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 91 17:39:03 GMT
From:      bonnie.concordia.ca!news-server.csri.toronto.edu!csri.toronto.edu!mart@uunet.uu.net  (Mart Molle)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: more on Elements of Networking Style
In article <9101111002.AA08769@garuda.sics.se> craig@SICS.SE (Craig Partridge) writes:
>
>I think some folks who have complained about "ENS", have missed its point.
>
>Yes, the prose is sometimes wild and crazy, but then again, it is intended
>that way.  Half the point of the book is to have some fun (and certainly, I,
>as a reader, had a lot of fun reading it).
>
>As for technical content, that ain't bad neither.  [...]   MAP's
>writing style should not confuse you into believing there's no substance
>behind it.

Sorry to disagree, but I think you got it backwards: it is, most
unfortunately, MAP and the Internet In Crowd who have missed the
point.  Many years ago, after seeing a book review somewhere (I
don't remember anymore, maybe IEEE Spectrum or Proc. IEEE), I ordered
a copy to use as reference material in my Computer Networks course
to counteract the strong OSI bias in Tanenbaum's book (First edition,
the second seems better...).   None of the students was willing to
read the whole thing -- even `Those Dreaded Engineers' who publish a
student newspaper most notable for its jokes and lack of good taste
were turned off by it.

Taken by itself, the title essay `The Elements of Networking Style' was
good enough for me to forgive the `wild and crazy' prose.  But taken
as a whole, the book was repetitive and monotonous.  Furthermore, who
was the intended audience?  He seemed to be preaching to the converted.
While I'm sure people like Craig Partridge had a lot of fun reading it
(heck -- I admit it -- I did too ...when I wasn't being too distracted
by the repetition...), they already *knew* the lessons he was preaching.
On the other hand, he seemed all too willing to hurl insults at anybody
who he deemed pro-ISO, and hence ignorant of Those Lessons, to the point
where I'm convinced that none of those people read it (or, if they did,
took anything he said seriously).

In other words, I'm sure The Book had zero impact on the state of the
networking world.  It should have had more.  Quite possibly, it *could*
have had more if a bit more effort had been put into integrating the
material.

Mart L. Molle
Computer Systems Research Institute
University of Toronto
Toronto, Canada M5S 1A4
(416)978-4928
-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 91 19:01:42 GMT
From:      raj@hpindwa.cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Latest FTP RFCs


Curiousity Toss-Up Question...

Will the performance difference between a 'typical' LAT implementation
and a 'typical' Line-Mode Telnet be as great as the current
differences?

Admittedly, a very difficult question to answer decisively, but I'm
just as interested in the speculation...

rick jones

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 91 19:03:53 GMT
From:      mstar!mstar.morningstar.com!bob@uunet.uu.net  (Bob Sutterfield)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: LAT
In article <12653518846.15.BILLW@mathom.cisco.com> BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes:
   The lack of a network layer might be considered an optimization,
   but this "single LAN" that it allows is a fast-vanishing beast.
   The fact that it cannot operate over a complex or Wide-area network
   is a SERIOUS limitation of LAT.

Right, but as you later say,

   ...LAT will not easilly be replaced by Telnet or VTP...
       3) There is an enormous installed base of LAT.  

After a few years of listening in on the "Campus-Size LAN Discussion
Group <BIG-LAN@SUVM.BITNET>", it seems that the "single LAN" might not
be vanishing quite as quickly as one might hope.  There are
organizations out there today, actively installing very large bridged
networks.  Why?  because (a) DEC sells bridges and (b) DEC sells LAT;
which are complementary solutions to certain problems imposed by the
fact that (c) DEC sells VMS.

If the DEC salesman got to campus before the Sun or Cisco or Bridge or
Proteon salesmen, and if the local tech people grew up in the VMS
culture, then the campus computing services bureaucrats are more prone
to specifying LAT and bridging their network.  The benefits of routers
are immaterial in a LAT network, and in fact routers break the LAT
functionality upon which the users have already become dependent.

Sorry if this sounds like cynical VMS- or DEC-slamming, it's intended
only as a recognition of marketing reality.
-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 91 21:16:44 GMT
From:      hubcap@hubcap.clemson.edu (System Janitor)
To:        comp.protocols.tcp-ip
Subject:   campus PC lab on the net...

Hello...

If anyone who knows where I can obtain (purchase or public domain) software
that will allow PCs (ms-dos) to do nfs and or lpr would drop me a line, I'd
appreciate it. The PCs are currently running NCSA telnet, but that's not
carved in stone... in other words, I'd still be very interested in 
investigating an nfs solution that required some other flavor of TCP/IP.

-Mike

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 91 21:35:11 GMT
From:      srb@beach.cis.ufl.edu (Sreedhar Barakam)
To:        comp.os.vms,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Wollongong TCP/IP for DOS Problem


	We have Novell's Netware, and Unix 4.2BSD nets linked using
	wollongong TCP/IP.  Wollongong's router seem to fail when
	Unix system goes down and it locks up all the netware terminals
	that are currently logged into the Unix system.  If anybody
	has any information regarding this please e-mail.  I can summarize
	and post here if needed.
	Thanks

	Sreedhar.

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 91 22:24:39 GMT
From:      bbn.com!papaya.bbn.com!rsalz@eddie.mit.edu  (Rich Salz)
To:        tcp-ip@nic.ddn.mil
Subject:   Dialup IP release
Bolt Beranek and Newman, Inc., and CREN/CSNET are pleased to announce the
first public release of Dialup IP.  The code works in binary-only
BSD-derived sytems; we have installed it on Ultrix3.x systems, 4.3BSD
systems, and Sun's running 3.5.

Dialup IP is a driver that sends IP datagrams over SLIP connections.  A
flexible scripting language is provided to initiate a call and negotiate
the login process on the remote host.

The biggest advantage of this package over some other serial line IP
systems is that Dialup IP will automatically initiate or disconnect phone
calls as needed.  When the line becomes inactive (based on a settable
timeout), Dialup IP will hang up the line.  Connections can be brought up
manually, or automatically when the network needs to send a packet to the
remote host.  In addition, the automatic calling can be subject to access
controls based on the source or destination system or network, as well as
the network protocol being used and the current time of day.  This can be
useful, for example, to prevent FTP requests on "student systems" from
incurring long-distance phone charges.

Dialup IP may be freely redistributed, under the same terms as the BSD
"freed" software.  Copies are available by FTP on bbn.com in
pub/dialupip.tar.Z and on uunet.uu.net in pub/networking/dialupip.tar.Z.
Please do not ask us to send tapes or send it via email.

We cannot provide any official support or maintenance, but are interested
in hearing of any bugs, added features, or ports to new platforms, and
might coordinate a new release.  We have provided the BSD developers with
a copy of the package, and they expect to integrate it into an upcoming
release.

A mailing list has been created to discuss Dialup IP; write to
<dialupip-request@sh.cs.net> to be added to it.

Sincerely,
Rich $alz <rsalz@bbn.com>,
John Curran <jcurran@sh.cs.net>
-- 
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
Use a domain-based address or give alternate paths, or you may lose out.
-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 91 22:48:40 GMT
From:      eagle!news@ucbvax.Berkeley.EDU  (Steven Eubanks)
To:        tcp-ip@nic.ddn.mil
Subject:   REPOST: Telnet rotors/connection distribution??
Sorry, I was informed that my return address was bogus; hence the repost.

I am looking for anyone who has any information/experience regarding
"rotoring" or distributing Telnet connections across a pool of multiple
equivalent hosts (IP addresses).

CURRENT ENVIRONMENT:

This site currently has a cluster (yes, of course VAXes) of host machines,
configured identically (applications as well as hardware) providing
central application services to a large LAN composed of
PCs/MACintoshes/Workstations (2000+).  In this (VAXcluster) configuration,
any PC/MAC/WS user can access any of the clustered host machines to execute
these centrally-located applications.  Until recently host connectivity
across the LAN was provided by a non-TCP protocol suite which provided a
"rotoring" capability which "pseudo-randomly selected" which of the n
identical nodes the user would attach to. Voila! Instant connection
distribution. [Notice I didn't quite say load balancing ;-)] Now, having
installed TGV's Multinet on the VAXcluster, and migrating more of our
networked PCs to TCP, we are wishing to duplicate that same "rotor group
connectivity" using TCP/IP.

PROBLEM/QUESTIONS:

How??  Has anyone successfully done/addressed this?

Since all our PCs/MACs/WSs are directly connected to the ethernet LAN,
there's no intermediate device to distribute the connections.  DNS, at
least as much as I know of the RFC-compliant version, doesn't address this
problem.  I can't think of anything that can be done on the VAX end
(though I'm willing to be proved wrong).  Surely, we're not the only site
having reached this dilemma.  Ideas??  Suggestions??  

[Please address all distributed computing environment rhetoric to
/dev/null;  we're working on it. :-) ]

Thanks in advance for all the advice!

Steve
--
Steven W. Eubanks,  EDS/LIMS			NASA Lewis Research Center
Internet:xxseub@osprey.lerc.nasa.gov		21000 Brookpark Rd. 
(216)433-8498					Cleveland, OH  44135
Disclaimer:  Opinions like mileage, may vary.
-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 91 00:55:03 GMT
From:      mshiels@tmsoft.uucp (Michael A. Shiels)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Bridge scorecard?

We are in the process of evaluating some Ethernet bridge products and were
wondering if there is a "scorecard" out there for them.  If not I would like
to volunteer to accept specifications from vendors/users and compile a card.

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 91 02:02:36 GMT
From:      envy!karn@bellcore.com  (Phil R. Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: LAT
In article <1991Jan14.015852.26228@mdivax1.uucp>,  writes:
|> A good question to ask is whether LAT performs checksumming. [...]
|> [...] rather CPU intensive nature of checksumming. 

Checksumming is a complete non-issue here. Its cost falls into the
noise when compared to all the other things that happen when you type
a character or refresh a screen.

Even in high bandwidth situations (i.e., FTP rather than TELNET) the
cost of TCP checksumming is usually minimal compared to, say, the cost
user/kernel context switches and of talking to the Ethernet hardware.

And Van Jacobson and Dave Borman have shown how TCP implementations
can combine checksumming with data copying. This all but eliminates
the cost of checksumming, especially on machines with fast processors
and slow memories.

Even if TCP checksumming weren't minimal, it would be a big mistake to
turn it off - the "end to end argument" reigns supreme.

Phil
-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 91 02:46:41 GMT
From:      deccrl!news.crl.dec.com!shlump.nac.dec.com!pa.dec.com!mogul@bloom-beacon.mit.edu  (Jeffrey Mogul)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: More on TCP Performance Limits
In article <81033@sgi.sgi.com> rpw3@sgi.com (Rob Warnock) writes:
>In article <9101111221.AA08912@garuda.sics.se> craig@SICS.SE
>(Craig Partridge) writes:
>| There seems to be a lot of misinformation running around.
>| The end-to-end performance of a TCP connection is limited by two different
>| factors:
>|     (1) The window size...
>|     (2) The sequence space size...
>And (at least) one more:
>      (3) The underlying IP ID space size.
>[...]
>So the IP ID rate-limit (item #3) is also a serious issue in gigabit/sec TCP
>networking. Some of the ideas in RFC 1185 may be helpful here, but in the
>presence of fragmentation, TCP options cannot be recognized in any fragment
>except the first. The solution may be to use some form of MTU discovery, then
>send *all* TCP segments with the "Don't Frag" bit on the in the IP packets
>(avoiding reassembly aliasing), *let* the IP IDs wrap as they will, and use
>the timestamp mechanisms of RFC 1185 to sort out potential duplicates.

Note that the Path MTU Discovery Protocol (RFC 1191) specifically
requires the participating sending host to send all TCP segments
with DF set.  With this mechanism in use, the IP ID field becomes
effectively unused, and then the size of the ID space is immaterial
to the maximum rate on the connection.  The rate is thus controlled
only by the sequence space and window sizes.

You might end up sending 8 bytes per segment, but this doesn't limit
the theoretical TCP bandwidth ... only the practical bandwidth.

-Jeff
-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 91 03:57:20 GMT
From:      pte900@jatz.aarnet.edu.au (Peter Elford)
To:        comp.protocols.tcp-ip
Subject:   Re: Dialup IP release

In article <3212@litchi.bbn.com>, rsalz@bbn.com (Rich Salz) writes:
|> Bolt Beranek and Newman, Inc., and CREN/CSNET are pleased to announce the
|> first public release of Dialup IP.  The code works in binary-only
|> BSD-derived sytems; we have installed it on Ultrix3.x systems, 4.3BSD
|> systems, and Sun's running 3.5.
|> 
 ..
|> 
|> Dialup IP may be freely redistributed, under the same terms as the BSD
|> "freed" software.  Copies are available by FTP on bbn.com in
|> pub/dialupip.tar.Z ...

The file appears to be pub/dialup2.0.tar.Z

-- 
Peter Elford,                           	e-mail: P.Elford@aarnet.edu.au
Network Co-ordinator,	 			phone: +61 6 249 3542
Australian Academic Research Network,		fax: +61 6 247 3425
c/o, Computer Services Centre,			post: PO Box 4
Australian National University			      Canberra 2601
Canberra, AUSTRALIA		

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 91 06:33:21 GMT
From:      Juha.Heinanen@FUNET.FI (Juha Heinanen)
To:        comp.protocols.tcp-ip
Subject:   When is a link saturated?

i have heard that the next version of cisco software (8.3 or 9.0 i
don't know what they decide to call it) will support separating
interactive traffic in higher priority output queues, which should
allow higher average loads than is currently feasible.

-- juha

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 91 07:11:33 GMT
From:      nipper@ira.uka.DE ("Arnold Nipper - XLINK - Phone: +49 721 608 4331")
To:        comp.protocols.tcp-ip
Subject:   Re:  When is a link saturated?

In your letter dated Tue, 15 Jan 91 08:33:21 +0200, you wrote:
>
>i have heard that the next version of cisco software (8.3 or 9.0 i
>don't know what they decide to call it) will support separating
>interactive traffic in higher priority output queues, which should
>allow higher average loads than is currently feasible.
>

For those who don't read Comp.dcom.sys.cisco:
--------------------------------------------------------------------------------
From: kozel@milano.cisco.com (Edward R. Kozel)
Newsgroups: comp.dcom.sys.cisco
Subject: Release: Priority Queuing
Date: 24 Sep 90 03:19:44 GMT

PRIORITY QUEUING FEATURE LETS CISCO ROUTERS IMPROVE 
SERVICE ON LOW-BANDWIDTH SERIAL LINES

MENLO PARK, Calif., Sept.18, 1990 -- Cisco Systems has added to its
internetwork router/bridges a software feature that lets users assign
priorities to classes of data sent over a network, thereby maximizing service
on low-bandwidth congested serial interfaces.

Cisco's new "priority output queuing" feature is a mechanism for prioritizing
datagrams, typically classified by protocol (e.g., TCP, DECnet, AppleTalk,
bridging) or sub-protocol (Telnet, FTP, LAT, electronic mail) type.  It is
designed as a flexible way to let the user specify the data types most
important to his application (e.g., TCP/IP, over DECnet, terminal traffic over
file transfer) and ensure that those types are transmitted first over an
interface.

Cisco, whose router products also support concurrent bridging, is the first
vendor to offer priority queuing for both routed and bridged protocols.

According to Doug Tsui, manager of product marketing, priority output queuing
addresses the problem of heavily loaded, low-bandwidth serial interfaces,
generally 56 Kbps or slower.

"The serial lines linking wide-area multi-purpose networks often get bogged
down with large numbers of file transfers occurring simultaneously with
interactive terminal traffic such as Telnet or LAT sessions," Tsui said.  "Not
only is response time for terminal traffic traditionally low, but in the case
of LAT, for example, there is a maximum timeout of 255 milliseconds; if an
acknowledgement isn't received by then, the session terminates.  Priority
output queuing solves this problem by letting the user give LAT priority over
all other traffic."

Priority queuing addresses operational as well as technical issues, Tsui said.
"Suppose a company has set up a multiprotocol WAN.  Department A, the
company's R&D lab using TCP/IP, has bought and installed all the routing
equipment, and wants to ensure that its critical design data have top priority
on available bandwidth.  Priority queuing in effect establishes grades of
service, 'favoring' TCP/IP packets so they get switched before DECnet packets
from another department."

Tsui noted that priority queuing is especially useful in international
networks, where bandwidth is often most expensive.

Priority output queuing works by classifying datagrams according to various
criteria and queuing them on one of four output queues.  When the router is
ready to transmit a datagram, it scans the priority queues in order, from
highest to lowest, to find the highest-priority datagram.  When that datagram
has been transmitted, the queues are scanned again.

Priority output queuing will be available as a standard feature (no extra
cost) with cisco routers shipped beginning in November.  Existing units can be
upgraded under cisco's software maintenance program.

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

Arnold

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 91 07:28:23 GMT
From:      Juha.Heinanen@FUNET.FI (Juha Heinanen)
To:        comp.protocols.tcp-ip
Subject:   When is a link saturated?

well, to my best understanding the "priority output queue" feature as
implemented in cisco 8.2 DOESN'T support giving high priority to
telnet, rlogin, etc. interactive tcp/ip services no matter what the
announcement on sep 18, 1990 said.  this is because the extended
access lists (on which the feature is based) simply are not powerfull
enough to do so.  i'm pleased if someone can prove that i'm wrong by
giving me the proper configuration commands.

-- juha

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 91 09:00:36 GMT
From:      Christian.Huitema@MIRSA.INRIA.FR (Christian Huitema)
To:        comp.protocols.tcp-ip
Subject:   Re: When is a link saturated?

Cisco's response is one of the possible solution to the "link saturation"
problem. In fact, to state a complete definition, a link is saturated when in
cannot accept more traffic without degrading the overall quality of service
beyond acceptable limits. This relates directly to the problem of congestion
control in datagram networks.

Amongst the strategies for pushing the limits, one find indeed the separation
of traffic in different "priority" classes. This can be done by using a
priority parameter in the datagram headers, e.g. IP "class of service"
parameter. The effect is that priority traffic is treated as "foreground",
while non priority traffic is queued in background and only obtain what is left
after the priority traffic is served. In fact, that strategy should be
implemented carefully, as one must guarantee that at least some non priority
traffic is transmitted.

The scheme used by cisco does probably not rely on the IP "class of service", 
as most TCP and UDP implementations use the same "standard" class of service
for all connections. One can indeed use the "protocol identifier" (TCP, UDP,
ICMP..) and place different priorities to different protocols, but I am a bit 
puzzled by cisco's assertion that they give "telnet" traffic precedence over 
"ftp": after the first synchronisation, neither the IP headers nor the TCP 
header bear any indication of the application layer protocol. The only way to 
make this correlation is to "remember the first exchange"; but if parallel 
routes can be used, there is not even a garantee that the synchronisation 
packets and the data packets will follow the same route! One should also note
that if IP segmentation is used, the TCP header is only present in the first
segment...

A more conventional scheme relies on the separation of the traffic in classes
based on the packet size: interactive traffic use shorter packets than file
transfer; the shorter packets get routed first.

A promising scheme, which I heard several time, is to manage one queue per
source host. The idea here is to give an even share of the network to every
station; it is also an incentive to implement decent end to end flow controls
(e.g. slow start) as the rogue TCP which use very long queues will observe very
long transit delays and thus very poor performance, while the correct TCP will
work normally. I dont know whether cisco or others plan to implement that.

Christian Huitema 

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 91 09:22:48 GMT
From:      ronald@integow.uucp (Ronald Wopereis)
To:        alt.sources.wanted,bit.listserv.aix-l,bit.listserv.ibm-nets,bit.listserv.ibmtcp-l,bit.listserv.tn3270-l,comp.protocols.tcp-ip,comp.unix.aix
Subject:   UNIX to AS/400 , telnet , tn3270, 5250 ?

Folks,

I am looking for a connection to make between a UNIX box ( Motorola, Sun
Sparc ) and an IBM AS/400 over TCP/IP.

I have the tn3270 program, but from what I've heard, I need a different
protocol to talk to the IBM AS/400, which is said to be the 5250 protocol.


Questions that I have are :

	
	(1) Is there a program available ( freeware or commercial
		package ? ) I saw Rabbit software offers the
		RabbitPLUS 3270 (TM) package, but can I talk to
		the AS/400 with this protocol ?
	
	(2) Does anyone out there have any experience in connecting
		these two machines ?

Thank you all who've read this far.
-- 
UUCP: ..!uunet!mcsun!hp4nl!integow!ronald  or  ronald@integow.uucp 
Ronald Wopereis, Consultancy Manager, Integrity Software Consultants, 
         Pelmolenlaan 16, 3447 GW Woerden, Netherlands,
            tel +31 3480-30131, fax +31 3480-30182

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 91 10:22:54 GMT
From:      Juha.Heinanen@FUNET.FI (Juha Heinanen)
To:        comp.protocols.tcp-ip
Subject:   When is a link saturated?

Christian,

   The scheme used by cisco does probably not rely on the IP "class of
   service",  as most TCP and UDP implementations use the same
   "standard" class of service    for all connections. One can indeed
   use the "protocol identifier" (TCP, UDP, ICMP..) and place
   different priorities to different protocols, but I am a bit  
   puzzled by cisco's assertion that they give "telnet" traffic
   precedence over "ftp": after the first synchronisation, neither the
   IP headers nor the TCP header bear any indication of the
   application layer protocol. 

   The only way to make this correlation is to "remember the first
   exchange"; but if parallel routes can be used, there is not even a
   garantee that the synchronisation packets and the data packets will
   follow the same route! 

This can't be true.  If I start a telnet session to another host,
isn't the destination port number equal to 23 in all TCP headers that
are sent from my host and the source port number equal to 23 in all
reply TCP headers?  

The current problem in Cisco's implementation is that the priority
queue mechanism can use IP extended access lists but the in an
extended access list one can only specify the destination TCP port
number, which in the case od a reply TCP packet is whatever number my
host has selected.  So even in the current implementation, my packets
be routed at high priority, but the replies come slow!

   One should also note that if IP segmentation is used, the TCP
   header is only present in the first segment... 

This should not be a major problem if we can assume that most of the
interactive packets are small as you say yourself below.

   A more conventional scheme relies on the separation of the traffic
   in classes based on the packet size: interactive traffic use
   shorter packets than file transfer; the shorter packets get routed first.

   A promising scheme, which I heard several time, is to manage one
   queue per source host. The idea here is to give an even share of
   the network to every station; it is also an incentive to implement
   decent end to end flow controls (e.g. slow start) as the rogue TCP
   which use very long queues will observe very long transit delays
   and thus very poor performance, while the correct TCP will work
   normally. I dont know whether cisco or others plan to implement
   that.

This won't help interactive users in a multiuser environment where
other users' file transfers can override the interactive user.

-- Juha

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 91 14:25:47 GMT
From:      mostek@PECAN.CRAY.COM (James Mostek)
To:        comp.protocols.tcp-ip
Subject:   Re: More on TCP Performance Limits



It seems that most of the contributors are pointing out that IP
limits the performance of TCP/IP with the TTL and ID fields.
They claim that IP would break if too many packets are in the network
at any point in time (two packets could have the same ID).

However, if IP builds a packet for TCP with bad data,
TCP will drop the packet and it will be retransmitted.
TCP's checksum will certainly show an improper packet.

This is a very obscure case (an ID from a later
fragment arrives before its predecessor).
So we are not talking about many retransmissions.

TCP is built to handle bad data.
I'm not familiar with UDP, how would it handle this?

I don't think people should make the calculations in previous mails
to claim that TCP/IP's performance is limited by IP's ID and
TTL fields.

Jim Mostek
Cray Research, Inc
mostek@cray.com

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 91 16:39:28 GMT
From:      drubin@polyof.poly.edu (A1 dave rubin (single) )
To:        comp.protocols.tcp-ip
Subject:   Terminal Servers supporting TN3270

I am looking to purchase a terminal server that supports tn3270 for
connecting to IBM Mainframes.  Do any such servers exist?  If not, have
any manufacturers announced plans to support tn3270 in the future, and
how soon?

Please respond via E-mail .. thanks.

--
Dave Rubin
Polytechnic University
drubin@polyof.poly.edu

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 91 17:03:32 GMT
From:      mann@star.enet.dec.com (Bruce Mann ZK1-3/J35 DTN 381-1298)
To:        comp.protocols.tcp-ip
Subject:   TELNET LAT comparison ...


	There is a lot of misinformation about LAT.

	The reason LAT outperforms TELNET (or any other
protocol) under a workload where many connections exist
between the same two systems is the message rate. The  
"full protocol stack" issue is a red herring.

	For instance, with 128 connections active,
LAT may be sending about 20-30 packets/second while
other protocols send 100s of packets/second.

	This is because LAT attempts to put all the
different session data into a single physical datagram,
unlike other protocols. This results in LAT's peculiar
timer-based operation and other special policies.

	LAT has no provision for checksumming - it
relies on the underlying LAT 32-bit CRC. Since LAT
only operates across LANs, data integrity problems
introduced by ISO layers 3-7 reformatting packets
(routers/gateways) is not an issue for LAT. Bridges
normally forward packets without regenerating CRCs.

					Bruce Mann
					LAT inventor

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 91 17:32:07 GMT
From:      larry@nstar.rn.com (Larry Snyder)
To:        comp.dcom.modems,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.sysv386,fido.unix
Subject:   dedicated line using 386/ix

We recently worked out a deal to install a 19.2kb dedicated
line between nstar.rn.com and another site 160 miles away -
and plan to run SLIP over this connection.  Both ends will be
running Interactive Unix 386 release 2.21 - and we are at a loss
as to what type of modems to place on each end.

V.32 was our original idea - but now that V.32bis is out - we
are thinking about using V.32bis which should increase the throughput.

Any comments or feedback would be most welcome.


-- 
   Larry Snyder, NSTAR Public Access Unix 219-289-0282 (HST/PEP/V.32/v.42bis)
                        regional UUCP mapping coordinator 
  {larry@nstar.rn.com, ..!uunet!nstar!larry, larry%nstar@iuvax.cs.indiana.edu}

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 91 17:37:09 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: PPP on STREAMS


    At Interop '90 there was a small "Solutions Showcase (tm) Demonstration"
    on PPP.  It had ... and Telebit, INTERACTIVE, and Xylogics communicating
    at 9.6K and 19.2K bps asynchronous....

We had PPP code there, but not all implementations interoperated as of that
date.  The list of implementations that I know to interoperate is larger now,
but I'd still recommend "try before you buy".

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

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 91 18:09:08 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Bandwidth limits (was Re: TCP window size restriction)

Hmm.  If I understand the arguments correctly, the ident/sequence
number limitations are only theoretical - if your network hangs on to
fragments or packets for long periods of time, and then delivers them,
they could lead to all sorts of interesting failures - fragments from
different packets getting reassembled together, or old segments being
interpretted as recent.

The latter case sound pretty catastrophic, but the fragmentation
problem seems less serious - putting together the wrong fragments
should simply result in a TCP checksum error.

Note that these problems don't actually limit the throughput of TCP,
they just limit the throughput below which you are assured reliable
transport in spite of arbitrary network failure modes.

I don't know what the impact of the fact the the IP TTL is rarely used
as a time would be on this whole mess, but I suspect that it isn't
good.  (Eg, setting the TTL to 255 doesn't guarentee your packet will
be dead 255 seconds from now in todays networks...)

BillW
-------

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 00:09:07 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: PPP on STREAMS

In article <9101131946.AA28696@ccci>, tcs@ccci.UUCP (Terry Slattery) writes:
> ...
> 
> I don't recall ever hearing about a PPP interoperability test.  Perhaps
> Interop should consider setting up a demonstration of PPP at its next
> conference? ...


There was talk of an INTEROP PPP test.  I heard at first it would be
restricted to "commercial implementations that would be available to end
users by Oct. 1990", or words to that effect.  That sort of requirement has
a chilling effect on what is necessarily a low profit product.  (How much
would you pay for a PPP implementation?  How many copies at that price
would be required for my employer to recover my time to port or implement
it and to pay for stocking, distributing, and advertising it?  How many
copies would be required to recover the INTEROP fees to participate in the
demo?)  By the end of the 2nd FDDI Hot Staging, I was told the rules were
much looser.  Perhaps I just misunderstood at first.

Trade show "interoperability tests" don't measure what you may think they
measure.  They do not ensure that two random companies' products will work
usefully together in your network.  Instead they show that the vendor
representatives can avoid killing each other and the show management during
the hot stagings and that things can be made to look good during the show.
They are marketing events.  (I have been involved with INTEROP demos for
two years.  I cannot answer any questions about what I may have observed at
any booth other than my employer's, and so can say nothing about observed
interopability or problems.)


Vernon Schryver,   vjs@sgi.com

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 00:17:48 GMT
From:      swansonc@acc.stolaf.edu (Chris Swanson, St. Olaf College)
To:        comp.protocols.tcp-ip
Subject:   Re: Dialup IP release



I missed this entire thread.  Could someone enlighten me to what
dialupip is?  Is it like SLIP, if not, what are the differences.
Please e-mail responses to me as I do not have a lot of time to devote
to news reading.  I will sumerize if there is intrest.

	-Chris

--
Chris Swanson, Chem/CS/Pre-med Undergrad, St. Olaf College, Northfield,MN 55057
	INTERNET:  swansonc@acc.stolaf.edu	UUCP: swansonc@stolaf
    	AT&T:	   Work: (507)-645-6845		Home: (507)-663-6424
	I would deny this reality, but that wouldn't pay the bills...

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 00:21:45 GMT
From:      prindevi@INRIA.INRIA.FR (Philippe-Andre Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re:  When is a link saturated?


	well, to my best understanding the "priority output queue" feature as
	implemented in cisco 8.2 DOESN'T support giving high priority to
	telnet, rlogin, etc. interactive tcp/ip services no matter what the
	announcement on sep 18, 1990 said.  this is because the extended
	access lists (on which the feature is based) simply are not powerfull
	enough to do so.  i'm pleased if someone can prove that i'm wrong by
	giving me the proper configuration commands.

You're overlooking a point here:  the *hosts* are just as involved
in this process -- they *must* use proper type-of-service labelling
of their packets (as per Host Req.) for this to work.  It is not
the job of the router to look at Transport-level information, no
matter what nifty features ciscos have.  Thus telnet/rlogin must
use low-delay, and ftp high throughput service specifiers in their
IP header.

The latest version of telnet, which will be released with 4.4,
includes code to enable this option.

-Philip

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 00:29:08 GMT
From:      prindevi@INRIA.INRIA.FR (Philippe-Andre Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re:  When is a link saturated?


	Tsui noted that priority queuing is especially useful in international
	networks, where bandwidth is often most expensive.

Wow!  That is a new one on me.  Can someone explain how ordering
packets (but not discarding) can save bandwidth?  Assuming that
the number of retransmissions aren't influenced, but merely that
interactive applications observe smaller round-trip times, the
total throughput should be the same...

I must be missing something obvious.  Can someone enlighten me
(and possibly others)?

Thanks,

-Philip

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 00:45:28 GMT
From:      albers@ka3ovk.irs.GOV (Jon Albers)
To:        comp.unix.sysv386,rec.ham-radio.packet,comp.protocols.tcp-ip,comp.sources.wanted
Subject:   KA9Q Net or NOS for SCO UNIX SysV/386 3.2.2


I am looking for source code to NOS for SCO UNIX sys V 3.2.  Does anyone have
working source which will compile under this version of SCO UNIX?  I would
prefer it be available via uucp, as I do not have easy ftp access.

								Jon Albers
					....uunet!media!ka3ovk


-- 
| Jon Albers, IRS, Information Systems Management, Support and Installation.  |
| Office Symbols: ISM:S:S:SI   voice: (202/FTS)535-3729  Packet: KA3OVK@N4QQ  |
| UUCP:(media|teemc|tcsc3b2|ki4pv)!ka3ovk!albers ARPA: JALBERS@SIMTEL20       |

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 01:18:19 GMT
From:      Yves.Devillers@INRIA.INRIA.FR (Yves Devillers)
To:        comp.protocols.tcp-ip
Subject:   Re: When is a link saturated?


 In your previous mail you wrote:

   	Tsui noted that priority queuing is especially useful in international
   	networks, where bandwidth is often most expensive.

   Wow!  That is a new one on me.  Can someone explain how ordering
   packets (but not discarding) can save bandwidth?  Assuming that
   the number of retransmissions aren't influenced, but merely that
   interactive applications observe smaller round-trip times, the
   total throughput should be the same...

   I must be missing something obvious.  Can someone enlighten me
   (and possibly others)?

-->aren't you missing the fact that when interactive users get poor reactions
they complain about the network being overloaded but don't get satisfied
(satisfaction being higher bandwidth to allow better interactions) since
those lines are so expensive that noone has money for them

On the other side giving better priority to interactive traffic ("re-ordering")
makes:
1- interactive users happy (better responsiveness)
2- network manager happy (no extra penny spent)
3- bulk traffic ftp fans unhappy

The total throughput is *globally* the same, not *individually* :-)

 Yves

 ----------------------------------------------------------------
 Yves Devillers
 Internet:    Yves.Devillers@inria.fr  Institut National de Recherche
 Goodie-Oldie: ...!uunet!inria!devill  en Informatique et Automatique
 Phone: +33 1 39 63 55 96              INRIA, Centre de Rocquencourt
 Fax:   +33 1 39 63 53 30              BP 105, 78153 Le Chesnay CEDEX
 Twx:   633 097 F                      France.

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 05:53:55 GMT
From:      oleary@noc.sura.net (dave o'leary)
To:        comp.protocols.tcp-ip
Subject:   Re: Willingness to pay for PPP (Was: Re: PPP on STREAMS)

In article <81325@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <9101131946.AA28696@ccci>, tcs@ccci.UUCP (Terry Slattery) writes:
>> ...
>> 
>> I don't recall ever hearing about a PPP interoperability test.  Perhaps
>> Interop should consider setting up a demonstration of PPP at its next
>> conference? ...
>
>There was talk of an INTEROP PPP test.  I heard at first it would be
>restricted to "commercial implementations that would be available to end
>users by Oct. 1990", or words to that effect.  That sort of requirement has
>a chilling effect on what is necessarily a low profit product.  (How much
>would you pay for a PPP implementation?  How many copies at that price
>would be required for my employer to recover my time to port or implement
>it and to pay for stocking, distributing, and advertising it?  How many
>copies would be required to recover the INTEROP fees to participate in the
>demo?)  By the end of the 2nd FDDI Hot Staging, I was told the rules were
>much looser.  Perhaps I just misunderstood at first.

	[other stuff about interoperability tests deleted]
>
>Vernon Schryver,   vjs@sgi.com
>

SURAnet is eagerly looking forward to the day when router vendors
have implemented PPP.  Since we run as a sort of "cooperative" with
each site making its own purchasing decisions, providing a wider 
variety of choices to our customers is very important.  We will 
maintain a list of vendors whose products interoperate with those
currently on our network, and recommend them to new customers.  
Those that don't interoperate, well, we won't recommend them.

					dave

p.s. I am confident that the rest of the SURAnet technical staff
	agrees with me on this point.

p.p.s. to router vendors: we will probably connect 30 or more new
	sites this year.  Maybe a lot more.

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 05:55:01 GMT
From:      j.onions@xtel.co.uk (Julian Onions)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Mail Extensions Working Group

> The problem with X.400 is that it is still not "here yet".  
Yes - but neither is the extended SMTP. It may be designed but can I
call up a random implementation and expect to send a multi-media
document there? I doubt it. X.400 may not be 'there' either but if you
have to choose between getting people to install new SMTP and user
agents and a new service altogether (X.400) - there doesn't seem a lot
in it. 

> Politically, I
> have to say that "yes, we will move to X.400" but practically, I don't see
> X.400 displacing RFC-822/SMTP based mail for some time to come.  
Probably true, but do you see this new standard becoming widely
adopted and displacing all the exisiting SMTP implementations in the
near future?

> X.400 still
> has to mature in a number of areas (e.g. P7 isn't yet up to the level of
> service provided by IMAP2).
OK, but sitting back and hoping it will mature won't help - by pushing
for its use you can expose the weaknesses and get things fixed and
providing useful services.

> There has been a lot of pressure from our European friends (!) to extend SMTP
> and RFC-822 to allow 8-bit mail using the so-called "International Character
> Set."  I agree that this is necessary, but we need some scheme to support thi
 s
> in the 7-bit e-mail world so that mail can pass through a 7-bit SMTP
> implementation unmolested (or at least transformed so that a reverse
> transformation is possible).
X.400 allows any binary data, it also allows conversion to be
implicitly performed to get the data into a format the receiver can
interpret - and if we have to gateway to RFC-822/SMTP world, the
appropriate transformations will be done so that the receiver only
gets ascii text (or the message bounced if the transformation is just
plain impractical e.g. hologram to ascii text!).

Julian.

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 05:57:18 GMT
From:      beame@maccs.dcss.mcmaster.ca (Carl Beame)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   VT220 8-bit emulation and Telnet Binary mode


	I'm just finishing up some testing of a new VT220 emulator and
I have run into a small problem. The VT220 can do both 7-bit and 8-bit
emulation and therefore must be able to have an 8-bit data path at times.
Currently, I send a WILL BINARY/DO BINARY Telnet sequence when 8-bit mode
is entered and a WONT BINARY/DONT BINARY sequence when 7-bit mode is entered.

	This seems correct, but I am getting different behaviour againts
several systems. And against many systems, 8-bit mode is unworkable.
Here is a small table of results when switching to 8-bit mode, the column 
<CR> working indicates whether a carriage return properly terminates an
input line.

System O/S           Responds DO/WILL     <CR> working
================================================================
Multinet VMS		Yes			Yes
Sun OS 4.1  		Yes			No
Solbourne 4.0C		Yes			Yes
SCO V3.2		Yes			No
CS/100 (milking mach.)	Yes			Yes
IBM FAL/VM (line mode)	No			Yes

Do I just give up the idea of using VT220 8-bit mode against Unix
hosts ? Do I ignore Binary mode, since many hosts transmit in Binary
even if the option is not set ?

Comments welcome.

	- Carl Beame
	Beame & Whiteside Software Ltd.
	Beame@McMaster.CA

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 11:30:38 GMT
From:      S.Kille@CS.UCL.AC.UK (Steve Kille)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Mail Extensions Working Group

I was going to take this issue up within the group, but since you have
staarted a wider dicsussion....

First, I think that the groups charter is too concerned with
mechanism/protocol (extensions to SMTP).  It would be useful to have a
higher level goal (Like you, I had assumed that this was primarily support
of Multimedis on the Internet.  However, Marks message indicates that there
might be other reasons).

I would agree with you that X.400 is the best way to go in the medium term,
for a lot of the reasons that you give.  I think that it may be the dominant
medium sooner rather than later, as the hard problem is not the message
transfer, but implementing high quality user agents.   

I think that there are several reasons why the SMTP work will go ahead.

1) Maturity of X.400.  1988 is needed.  There are not sufficient
implementations of suitable maturity available.  There is no X.400
infrastructure on the Internet, and the experiments are not that widely
supported and are 1984 based.  There is a need to sort out a number of
adressing and routing problems before an infrastructure could be deployed.
These are not fundamental problems - just reasons that it cannot be used yet.

2) Desire to experiment with MMM now.  It seems useful to use a lightweight
message transport mechanism, based on existing infrastructure.  SMTP is the
only viable infrastructure available now.

3) Negative attitude to OSI in the Internet.  I asked if X.400 had been
considered when this WG was announced at the IETF in Boulder.   Much of the
group treated this as a joke.  In some ways I see this as an unfortunate and 
parochial.  In other ways I sympathise - OSI zealots have been too strong on
political directions and theory and too weak on useful working code.



So, let me make a suggestion and plea.

Scope of group:  The group should expand its charter to consider services
(MMM support at least), and look at X.400 as a potential provider of these.  

Work undertaken:  The means to support structured messaging (essentially the
revised RFC 1154) should be modified to be compatible with X.400.  This is
straightforward.   Service goals:
   1) Any body format defined for RFC 1154 should implicity define a
   valid X.400(88) body part
   2) Any X.400(88) body part should implicitly define an RFC 1154 body part.
This will allow the multimedia UA work to be (largely) independent of
whether SMTP or X.400 is used as a transport.  Gatewaying between RFC 1154
enhanced SMTP and X.400(88) need not loose user information.

The technical key to achieving this is to allocate body parts by use of
object identifiers (OID) common to X.400(88) and RFC 1154, and to define
compatible encoding rules.   

Thus when Adobe register an OID for Postscript, this will define a usage
both in X.400 and SMTP worlds.

I think that this will be a very big win for everyone, and I'd strongly
encourage the group to develop such a solution.  This will allow the interim
work to develop, and will help a lot later if/when X.400 is used.



Steve

   

   

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 15:19:19 GMT
From:      mclay@vato.ae.utexas.edu (Robert McLay)
To:        comp.protocols.tcp-ip
Subject:   Problems w/ PPP and setsid


When I use PPP over a serial line between a sun4/330 and a sun 4/20
both running sunOS 4.1, I get the following error message:

ppp: setsid(): Not owner.

and the connection over the modem hangs up.   I haven't been able to
figure out what I'm not the owner of.  Is there some discussion
somewhere which will explain about setsid(2)?  The man page is too
terse for me to understand.

Here is the details of the set up I'm using.  I have the PPP from
tut.cis.ohio-state.edu from pub/ppp-sparc4.1.tar.Z.

I have an account on the work machine (sun4/330) called Pmclay

Pmclay:79SXQ7UAnIvZY:4:8:PPP start Robert McLay:/tmp:/usr/local/etc/pppstart

Here is what pppstart looks like:

#!/bin/sh
/usr/bin/mesg n
stty -tostop hupcl
exec /usr/local/etc/ppp -p 128.83.152.29:

Heres what ppp is set to:

-rwsr-xr-x  1 root     uucp       147456 Jan 10 12:59 /usr/local/etc/ppp*

Here is exactly what happens when I try to login by hand.

Script started on Thu Jan 10 13:23:07 1991
bash$ tip tb
connected

RRING

CONNECT 9600


navier.ae.utexas.edu login: Pmclay
Last login: Thu Jan 10 13:20:53 on ttya
SunOS Release 4.1_PSR_A (NAVIER) #10: Wed Jan 2 13:47:27 CST 1991
~ppp: setsid(): Not owV~ai2#6J	(ZgOZo-wY	'J4]
|?#j	h7u:#<z$%Us&2eW*kl>T  >s4cxS* ?),,l9;/z8af2i	=R{2o.jU)GT{\YlB
wD@$m|B~A'i{qCf*}^
K
Kq/D";[b.89q!4-N
]1b>qbb4?]x7ZCh$Ts8]/R Lc6$k:0D(*_Z$pcg
W%Vy$o
?kw{%dh Ehl0LnS
NO CARRIER

Lost carrier.
[EOT]

[EOT]

script done on Thu Jan 10 13:24:38 1991


Note that if I delete the exec in pppstart it does work.

Any ideas?
--

______________________________________________________________________________
Robert McLay                   | When you have a problem, put NO in front of
Manager CFD Lab                | it and you have:  NO PROBLEM.
Dept ASE-EM                    |
University of Texas at Austin  |           -- Eric Beckman's 2nd Law
                               |
mclay@wilbur.ae.utexas.edu     |

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 15:27:56 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: When is a link saturated?

ISO TP and DECnet only include service ID information when creating the
connection.  TCP always includes this information, in the "port" fields.

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

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 15:27:58 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: UNIX to AS/400 , telnet , tn3270, 5250 ?


    I have the tn3270 program, but from what I've heard, I need a different
    protocol to talk to the IBM AS/400, which is said to be the 5250 protocol.

IBM has apparently developed a 5250-over-Telnet scheme, which may or may not
resemble current 3270-over-Telnet practice.  I am not aware of any movement
to publish this as a standard, but maybe I haven't asked in the right places.

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

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 16:07:44 GMT
From:      kannan@OAR.NET (Kannan Varadhan)
To:        comp.protocols.tcp-ip
Subject:   Re: Problems w/ PPP and setsid



>>> From: mclay@vato.ae.utexas.edu (Robert McLay)
>>> Date: 16 Jan 91 15:19:19 GMT
 
> When I use PPP over a serial line between a sun4/330 and a sun 4/20
> both running sunOS 4.1, I get the following error message:
> 
> ppp: setsid(): Not owner.
> 
> and the connection over the modem hangs up.   I haven't been able to
> 
> Here is the details of the set up I'm using.  I have the PPP from
> tut.cis.ohio-state.edu from pub/ppp-sparc4.1.tar.Z.


I made those changes, and forwarded them to Karl Fox, they work
quite fine for me.

When you run ppp by hand, you will not be able to set the session
id.  This is because your login tty is not a controlling terminal etc.

Check if the ppp executable is setuid root, so as to be able to
manipulate the controlling terminal etc.

I am puzzled because the message seems to be one generated by a
perror() statement.  The ppp-sparc4.1.tar.Z code does not have a
perror() statement associated with the setsid() code.  Can you forward
the relevant sections of code so I can take a look at it?


Kannan


-=-
Kannan Varadhan, Internet Engineer (OARNet),		+1 614 292 4137
Ohio Supercomputer Center, 1224, Kinnear Rd.,  Columbus, OH 43212

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 16:27:57 GMT
From:      ejm@ejmmips.NOC.Vitalink.COM (Erik J. Murrey)
To:        comp.protocols.tcp-ip
Subject:   Re: When is a link saturated?

In article <9101150900.AA08526@jerry.inria.fr>,
Christian.Huitema@MIRSA.INRIA.FR (Christian Huitema) writes:
> .... One can indeed use the "protocol identifier" (TCP, UDP,
> ICMP..) and place different priorities to different protocols, but I
 am a bit 
> puzzled by cisco's assertion that they give "telnet" traffic precedence over 
> "ftp": after the first synchronisation, neither the IP headers nor the TCP 
> header bear any indication of the application layer protocol. The only
 way to 
> make this correlation is to "remember the first exchange"; but if parallel 
> routes can be used, there is not even a garantee that the synchronisation 
> packets and the data packets will follow the same route! One should also note
> that if IP segmentation is used, the TCP header is only present in the first
> segment...
> 
 
I don't understand why the "remember the first exchange" is necessary. 
Both telnet and rlogin use a reserved port number that appears in either
the source or destination TCP port fields on *every* packet that is
routed for the entire session.  The one exception is when IP gets
fragmented, which is rare in modern WAN's with current TCP implementations.


... Erik
---
Erik Murrey
Vitalink Communications
ejm@NOC.Vitalink.COM   ...uunet!NOC.Vitalink.COM!ejm

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 16:47:08 GMT
From:      mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   phone number to get off LOTUS Marketplace: Households


There have been a few messages recently about the LOTUS CD-ROM
database of 120 million Americans offering a better than ever means
for your privacy to be invaded.

If you want to get off the database, you can call LOTUS customer
service at (800) 225-5800 and asked to be removed.

This has the advantage over writing in that it costs LOTUS every time
someone calls in on their 800 number, instead of making us pay for the
postage stamp.

 _____   | ____ ___|___   /__ Mark ("Gaijin") Crispin "Gaijin! Gaijin!"
 _|_|_  -|- ||   __|__   /  / R90/6 pilot, DoD #0105  "Gaijin ha doko?"
|_|_|_|  |\-++-  |===|  /  /  Atheist & Proud         "Niichan ha gaijin."
 --|--  /| ||||  |___|    /\  (206) 842-2385/543-5762 "Chigau. Omae ha gaijin."
  /|\    | |/\| _______  /  \ FAX: (206) 543-3909     "Iie, boku ha nihonjin."
 / | \   | |__|  /   \  /    \MRC@CAC.Washington.EDU  "Souka. Yappari gaijin!"
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 17:00:30 GMT
From:      jas@proteon.com (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   TELNET versus LAT

But could a protocol be designed that had the advantages of LAT
(multiple streams in one packet, rate limiting, etc.) that ran over a
network protocol (such as DECnet routing without NSP), or had adaptive
timeouts?  I strongly suspect that the answer would be yes.  Such a
protocol would eliminate the crazy jumping through hoops people are
going through to try and bridge LAT across multiple media and wide
area networks.

I suspect at least part of the design parameters of LAT has more to do
with the implementation characteristcs of DECnet under VAX/VMS than
with the design of the "ultimately efficient" virtual terminal
protocol.

Indeed, despite implementation problems, in some ways CTERM (the
DECnet virtual terminal protocol) is a better protocol, since it can
dynamically switch between local and remote echo, even in a screen
editor.  Of course, the application has to be well written to gain the
advantages of the CTERM protocol.

Unfortunately, with LAT proprietary, the standards bodies won't get to
learn from it in designing future protocols.  It would be nice if the
ISO virtual terminal protocols could have had some of these
advantages.

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 18:50:37 GMT
From:      BDK@unb.CA
To:        comp.protocols.tcp-ip
Subject:   Re: Terminal Servers supporting TN3270

I looked at this a while ago. There are only two products that I could
find. The Yale Multi-Protocol Gateway does the job but it is expensive.
There is a company called XYPLEX (phone 508-264-9900) that makes
a TN3270 terminal server. However they only support VT100, VT220 and
standard  ANSI X3.64 compaitible terminals. They demonstrated them
at InterOP. They seemed to work. If they provided a way to have
user defined terminal types they would have a hot seller.
Brian Kaye
University of New Brunswick

On  Tue, 15 Jan 91 16:39:28 GMT  A1 dave rubin single
<polyof!drubin@NYU.EDU> writes:

> I am looking to purchase a terminal server that supports tn3270 for
> connecting to IBM Mainframes.  Do any such servers exist?  If not,
> have any manufacturers announced plans to support tn3270 in the
> future, and how soon?
>
> Please respond via E-mail .. thanks.
>
> --
> Dave Rubin
> Polytechnic University
> drubin@polyof.poly.edu

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 19:33:14 GMT
From:      mni@techops.cray.com (Michael Nittmann)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Bandwidth limits (was Re: TCP window size restriction)

Mea culpa!

Please!

RTT is under no control whatsoever neither by sender 
nor by receiver.
This holds also for the trivial "net" of two hosts.
Why:

Satellite: RTT is totally determined by the signal propagation.
Stationary orbit means about 80.000 km travel. With electronic 
delays this is then about 1 sec. ONLY THEN you could (but it
makes no sense for quantification!) say: 1 max window in the
net. But even that's no limitation if the receiver acks 
early so that the window slides and not concatenates end to end
(try to explain queuing theory inplain language).

Two hosts back to back. Take Sun WS: the ethernet card
of a Sun 3 gives about 4Mbit/s throughput. BUT: you do not
control memory accessibility, processor activity etc.
of the receiver. RTT may have a very big variance, big
enough to make talking of an "average" senseless (although
you can calculate one) since the average time may by
far be NOT the most frequent timelag occurring.
Take a disk at the receiver. It might be scattered
in free sectors. Then not PING RTT but receiver's I/O
determines RTT. RTT cannot be determined by taking some
TTL counts in seconds (who brings that up, TTL in 
TCP/IP is hops and should be internet diameter times
two to account for enough hops for the packet to 
propagate through the net on a fairly direct path).
And RTT does not determine or limit throughput
(early ack e.g.).
The case of one max. window in propagation on the
net is an interesting special case. 

By the way, I had to reply to the net 
because the original author was not reachable
since his path was not listed in nodes my mail
passes. Next time I will not reply to the net
if some obvious wrong posting is there. 


Could we please take this now off the list?
Please mail to me, not to the list.


Michael




And the disclaimer!!!!


:wq

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 20:00:26 GMT
From:      st@eniac.seas.upenn.edu (Stephen W. Thompson)
To:        comp.protocols.tcp-ip
Subject:   Gateway info for Novell LAN (Mac,PC) to campus ethernet TCP/IP

THE PROBLEM

Get a Novel LAN to talk to a wide-area ethernet through one
gateway, allowing full IP services to each node (Mac and IBM-PC) 
on the LAN. Do you know of a gateway that would accomplish this? 
Even better, do you have any *experience* with such a gateway?

DETAILS

We have a small Novel LAN of PC's which we are about to expand to
include more nodes and Macs as well as PC's.  At the same time we are about to
(finally) get access to the campus WAN via a single ethernet port.  (One is
cheaper than many, you see.)

Services we need: Telnet and FTP from all nodes simultaneously, full IP
services (though I'm weak on IP terminology and concepts, I think it's clear if
I say we would like to run X-Windowing application on LAN machines as servers
(?) with the clients (?) located on the campus WAN), sharing of printers (that 
would be useable by both Mac/PC), files on file servers of some sort.

What we do *not* need: Novel's IPX gatewayed across the WAN:  We don't want to
share our LAN, we just want to share the WAN.

Summary of Requirements:
- Resource sharing benefits of LAN
- World-connectivity benefits of WAN connection
- Low cost: One or very few connections to campus ethernet
- IP services
- World peace (while we're at it :-)

Thanks a bunch!  Lots of people have told us that this is a reasonable set of
desires, but that they don't know of the product(s) that can do it.

--
Stephen W. Thompson, University of Pennsylvania, 215-898-4585
Institute for Research on Higher Education, thompson@a1.quaker.upenn.edu (best)
                                            st@eniac.seas.upenn.edu (works)
         SMILE!                             PEW@PENNDRLS.BITNET (not preferred)

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 20:15:16 GMT
From:      sjg@melb.bull.oz.au (Simon J Gerraty)
To:        comp.protocols.tcp-ip
Subject:   Re: How to spool print jobs to term srv (ip address/port)

In <todd.663636475@premises1> todd@Quotron.COM (Todd_Booth) writes:
>My configuration is:
 
>Host   term_server
> |        |  |
> +--------+  printer
>  ethernet
 
>I can setup the terminal server to accept data sent to it's ip address
>at a given port and route that data to the printer.
 
>But I can't find any software to run at the host end that will spool
>printer data to a given ip address (term server) and port.  Has anyone
>done this before or know how?

Yes I have done it.  A little piece of software called rlpd.
Picture this:

spool_dir -> lpd -FIFO-> rlpd -Ethernet-> term_server -> printer

rlpd reads the printcap entry for a given remote printer and
creates a FIFO using the name of the "print_device" that lpd
will write to.  Each rlpd daemon can serve multiple remote
printers.  Rlpd talks telnet to the terminal server.

The advantage of the approach is that _none_ of the standard
spooling software needs to be touched, and users are completely
unaware of the interposition of rlpd.  It also make efficient
use of TCP sessions.

The disadvantage is that by using a FIFO between lpd and rlpd
there is always the possibility for data loss due to a system
crash or daemon being killed.  Depending on the UNIX
implementation a FIFO may buffer from 4-64k data - more than
enough for several small print jobs to be stuck in limbo just
waiting for the system to crash.  This is a serious risk so
don't use this method to print your account statements :-)

It is currently in use by one of our customers here to handle
about 200 remote printers scattered all over Australia.

Sorry the software is not PD.  You can either e-mail me for
details or write your own - it isn't difficult.
-- 
Simon J. Gerraty		<sjg@melb.bull.oz.au>

#include <disclaimer,_witty_comment>

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 20:30:36 GMT
From:      kannan@OAR.NET ("Kannan Varadhan")
To:        comp.protocols.tcp-ip
Subject:   more on ppp...a followup to my earlier message...



A few people have sent me mail saying that they were getting the
setsid() stuff, and that their code does have perror()
etc. and  that they are seeing the same problems.  Well, it turns out
that Karl Fox just put in a new version of ppp on tut the other day.
Please pick that up and try it out.  The stuff on tut.cis.ohio-state.edu
[128.146.8.60 if you don't know about things like DNS..and fie on you,
you ^%!@$#&^#@ for not using the DNS :-)] is....

	pub/ppp-sparc4.1.tar.Z		[The whole patched shebang
	pub/ppp-sparc4.1.shar.Z		[Just the patches, and K. Fox's kit.

The code fragments should look as follows....

valhalla ppp. rcsdiff -r1.1 -c ppp.c
===================================================================
RCS file: RCS/ppp.c,v
retrieving revision 1.1
diff -c -r1.1 ppp.c
*** /tmp/,RCSt1a03335   Wed Jan 16 15:22:18 1991
- --- ppp.c       Mon Dec 31 12:05:48 1990
***************
*** 105,110 ****
- --- 112,120 ----
  #endif
  int initfdflags;              /* Initial file descriptor flags */
  int pid;                      /* Our pid */
+ #ifdef sun
+ int   pgrpid;                 /* Process Group ID */
+ #endif
  char user[80];                        /* User name */


***************
*** 371,386 ****
      pid = getpid();
      if (debug)
        printf("Pid %d.\n", pid);
! /*    if (ioctl(fd, TIOCSPGRP, &pid) < 0) {
!       perror("ppp: ioctl(TIOCSPGRP)");
!       exit(1);
!     }*/
!     { int a;
!     if ((a=tcsetpgrp(fd, pid)) < 0) {
!       printf("ppp: errno=%d\n", errno);
        perror("ppp: tcsetpgrp()");
        exit(1);
!     }}

      /*
       * Compute mask of all interesting signals and install signal handlers
- --- 381,401 ----
      pid = getpid();
      if (debug)
        printf("Pid %d.\n", pid);
!
! # if defined(sun) && defined(SunOS) && SunOS >= 41
!     if ((pgrpid = setsid()) < 0) {
!       pgrpid = getpgrp (0);
!       }
!     if (tcsetpgrp(fd, pgrpid) < 0) {
        perror("ppp: tcsetpgrp()");
        exit(1);
!       }
! # else
!     if (ioctl(fd, TIOCSPGRP, &pid) < 0) {
!       perror("ppp: ioctl(TIOCSPGRP)");
!       exit(1);
!       }
! # endif

      /*
       * Compute mask of all interesting signals and install signal handlers
valhalla ppp.

FYI,


Kannan

-=-
Kannan Varadhan, Internet Engineer (OARNet),		+1 614 292 4137
Ohio Supercomputer Center, 1224, Kinnear Rd.,  Columbus, OH 43212

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 20:44:42 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Bandwidth limits (was Re: TCP window size restriction)

In article <12654151296.12.BILLW@mathom.cisco.com> BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes:
>The latter case sound pretty catastrophic, but the fragmentation
>problem seems less serious - putting together the wrong fragments
>should simply result in a TCP checksum error.

Well, do remember that the TCP checksum is only 16 bits, so you have one
chance in 65536 of getting a bad packet.  This becomes non-trivial if
you are exchanging millions of packets and fragmentation rears its ugly
head a lot.  (Which probably means you have other problems, but...)
-- 
If the Space Shuttle was the answer,   | Henry Spencer at U of Toronto Zoology
what was the question?                 |  henry@zoo.toronto.edu   utzoo!henry

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 21:03:12 GMT
From:      dunigan@THDSUN.EPM.ORNL.GOV (Tom Dunigan 576-2522)
To:        comp.protocols.tcp-ip
Subject:   What service broadcasts on UDP port 60000?

we're trying to figure out what service is broadcasting on
UDP port 60000.  It's coming from an SCO Xenix engine
with Lachman TCP/IP.
thanks

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 21:06:29 GMT
From:      ole@CSLI.STANFORD.EDU (Ole J. Jacobsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Dialup IP release

Craig Partridge explained Dialup IP in an article in the November 1989
(Vol 3, No. 11) of ConneXions--The Interoperability Report.

Ole

Ole J Jacobsen, Editor & Publisher ConneXions--The Interoperability Report 
Interop, Inc., 480 San Antonio Road, Suite 100, Mountain View, CA 94040, USA
Phone: (415) 941-3399  FAX: (415) 949-1779  Email: ole@csli.stanford.edu

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 21:09:14 GMT
From:      ronald@robobar.co.uk (Ronald S H Khoo)
To:        comp.dcom.modems,comp.protocols.tcp-ip
Subject:   Re: V32bis

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes in defence of the TB+:

> On the contrary, X terminals would benefit from a good asymmetric splitting
> of bandwidth.

But PEP doesn't give you split bandwidth, it gives you half duplex with
extremely high cost to turn the line around.  Now, if you had a
link-level protocol that reduced the number of turnrounds by letting
whole windows through before letting the other side speak, you might
win.  SLIP doesn't do this though, and my cursory glance at PPP doesn't
show such an option there either (though I'd be glad to be told that I'm
wrong).  Am I ? Does such a protocol exist ?

-- 
ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 91 22:04:11 GMT
From:      john@loverso.leom.ma.us (John Robert LoVerso)
To:        comp.protocols.tcp-ip
Subject:   Re: PPP on STREAMS

In article <1991Jan14.082326@max4.llnl.gov> scooper@aracmax1.llnl.gov writes:
> At Interop '90 there was a small "Solutions Showcase (tm) Demonstration"
> on PPP. [...] and Telebit, INTERACTIVE, and Xylogics communicating
> at 9.6K and 19.2K bps asynchronous.

This is slightly incorrect; Xylogics pulled out and did not show
PPP on the Annex.  The glossies were already printed, however.  In
the same way, I believe FTP was a late addition and did have PPP
running over PC/TCP.  Finally, there were several interoperability
problems between vendors.

../John [formerly of Xylogics]

-- 
John Robert LoVerso, Concurrent Computer Corp, loverso@westford.ccur.com
[to reach me, not the corporate puppet: john@loverso.leom.ma.us]

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 91 04:12:36 GMT
From:      cjohnson@somni.wpd.sgi.com (Chris Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Bandwidth limits (Closing? salvo)

It is always interesting to see the level of response two sentences
can generate.  I got a mailbox full from many Internet mavens and
maven wannabes.

I said (paraphrased slightly): 
	The data rate limit for TCP/IP isn't window size dependent.

The responses to this generally said "there is a window size bandwidth
limit", which in turn caused a flurry of "no there isn't a limit" notes.

I should have said:

	There are performance bottlenecks in TCP as specified in
	rfc793, but TCP options have been developed that address
	these problems.  As rfc1072 and rfc1185 point out, data
	rates over certain thresholds *require* extensions to
	rfc793.  To this extent, interoperability among vendors at
	data rates beyond the FDDI range is only possible if these
	TCP "options" become requirements, or if other mechanisms
	are developed and standardized that address the problems
	discussed in rfc1072 and  rfc1185.

	Note that these options are not mentioned in the host
	requirement doc, so as of today TCP has bandwidth limits
	in the FDDI range.  Certain implementations exceed these
	limits using the optional extensions to the base protocol.

Of course this will bother the mavens, too, but it is accurate.

I also said:
	The sixteen bit IP id field and the 16 bit max packet
	length limit a particular connection to 4GB/255 seconds
	or about 16MB/sec.

The responses to this were more entertaining (all paraphrased):

	Some suggested data to the contrary:
		> What about Famous Person at Acme Data Co who got
		> umpteen gigaunits per picoblip?

The point here is that ip ids in svr4 and BSD come from
	ip->ip_id = htons(ip_id++);
which is incorrect according to the IP spec.  So the high data rates
probably come from non-conforming IP implementations.  Perhaps the
designers decided that a subset of IP was all that people needed,
but that design decision never seems to get mentioned.  As data rates
go toward terabytes/sec, the above bug will get more severe.

	Some argued my choice of parameters:
		> No one uses a ttl of 255

Of course, using a smaller ttl will move the bottleneck, but that
has its limit.  Also, in reality very few media support 64k packets,
so the "real world" cases modify both the numerator and denominator
of the ratio.  Do your own calculations for your favorite numbers.
FDDI (4KB packets)  with a ttl of 30 yields a maximum of 8.9MB/sec.
Even less if you can't fill every packet to the brim.

	Higher level can detect it:
		> So what?  Mis-reassembled IP packets will be
		> detected by checksum failure, window range tests
		> or rfc1185 sequence wrap check.

The suggestion that TCP will detect the problem relaxes the IP
specification from general purpose routing and fragmentation, to
routing and fragmentation in the presence of higher layer fragment
assembly validation checks.  Of course IP implementations are
still broken, just not too broken for TCP.

	TCP should do routing:
		> TCP should use path mtu discovery and then
		> fragging is irrelevant.

This says that IP isn't broken because TCP should know about
routing/fragmentation tasks.  This is an appealing argument because
it addresses the actual flaw (that IP fragging is brain dead) but it
violates layering in a particularly violent manner.  And again, it
ignores the fact that other layers may be using IP's services.

	And the last catagory, the INET Jihad:
		> How dare you complain about items designed by
		> your betters.
		>
		> Don't you realize that tcp-ip is fighting the
		> forces of darkness and these petty complaints
		> just help OSI.
		>
		> These issues shouldn't be discussed in public
		> forums because naive users get confused.

The religous arguments were the most entertaining, but had the
least content.  

Here's what I should have said in my first message:
	There is another bottleneck at the IP layer that is
	unresolved as yet.  The spec in rfc791 *requires* that
	the (IPid, protocol, src host, dest host) quadruple is
	unique for a MPL.  At this time, most reference (SVR4 and
	BSD-reno) IP implementations DO NOT enforce this
	restriction, which may result in data corruption at the IP
	layer in rare cases at sufficiently high data rates.
	Some of these errors may be detected at the transport
	layer, but senarios can be defined in which application
	layers will receive stale or mangled data.

Finally, I think this discussion is overkill on an issue that
falls out on simple math from the protocol definition.  But
for some reason a single sentence was inadequate, so here is
a longer analysis.  As the summary says, facts is facts, so IP
has a data limit even if your implementation doesn't.  In
particular, if your IP implementation doesn't have a rate
limit, then it isn't 100% compliant with rfc791.

Keep those cards and letters coming in,
					cj*

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 91 05:31:00 GMT
From:      A01JRN1@NIU.BITNET (John Naples  753-1875, 815)
To:        comp.protocols.tcp-ip
Subject:   Re: centrally administered user authorization

>
>What's available to provide a centrally administered user authorization
>database? The goal is to allow a user to logon to any host in the network.
>Some bells such password expiration and accounting records would be nice.
>Thanks in advance.

We (Northern Illinois University) are asking the same question
right now.  We have not found any such products.  CA says they will
soon have a product to unite MVS, VM, and IBM PCs.  But it doesn't
look that good, and it does not address UNIX.  If you get any
answers we would appreciate knowing what they are.

John Naples, Northern Illinois University, A01JRN1@NIU.BITNET

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 91 06:17:18 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re:  When is a link saturated?


	    Tsui noted that priority queuing is especially useful in
	    international networks, where bandwidth is often most expensive.

    Wow!  That is a new one on me.  Can someone explain how ordering
    packets (but not discarding) can save bandwidth?

Well, reordering the packets will also affect which packets get dropped
when a queue becomes full.  If you give interactive (small) packets
priority, big packets are more likely to be discarded.  Bandwidth doesn't
increas, but packets per second does.  So does number of happy users.  This
is essentially the same argument as "the bandwidth is the same but the users
are happier" that someone else made.


    Assuming that the number of retransmissions aren't influenced, but
    merely that interactive applications observe smaller round-trip times,
    the total throughput should be the same...

Unfortunately, this is a bad assumption.  TCP is perhaps the best protocol
in this regard, since round trip timers and retransmission backoff have
been in the protocol since its inception.  Still, many TCP implementations
retransmit excessively in the presence of network congestion.  Almost every
other protocol is considerably worse, especially those that need bridged.

BillW
-------

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 91 12:55:59 GMT
From:      cpcahil@virtech.uucp (Conor P. Cahill)
To:        comp.dcom.modems,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.sysv386,fido.unix
Subject:   Re: dedicated line using 386/ix

In article <1991Jan15.173207.17446@nstar.rn.com> larry@nstar.rn.com (Larry Snyder) writes:
>V.32 was our original idea - but now that V.32bis is out - we
>are thinking about using V.32bis which should increase the throughput.

V.32bis is definately the way to go.  Not only do you get potentially
higher throughput (14.4kb) but you also get a MUCH MUCH better retrain
technology which should alleviate much of the v.32 dropped line problems.


We have 10 v.32 modems and I won't buy another one because of the problems
we have with dropped lines (or pauses for as much as 45 seconds while the
modems retrain).  The next modems that we buy MUST support v.32 bis.

-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 91 12:57:45 GMT
From:      fiamass@fiamass.ie (fiamass)
To:        comp.protocols.tcp-ip
Subject:   select() call weirdness


We are having a problem with the select() system call on a Sun Sparc 4/65
running SunOS 4.1.  We have a non blocking socket which we use to issue 
a connect().  This call returns EINPROGRESS as per the documentation.  The 
documentation states that under these circumstatances a select() call for 
write on that socket can be done to determine when the socket is fully
connected. Now here is our problem, we make a select() call which 
always seems to return telling me 
that the socket is now connected. So on I go and issue a write() which
causes the program to bomb out!  It is as if the write call does not return.
Here us the code. Has anyone any ideas?

#include <stdio.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/time.h>
#include <errno.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>

main()
{
char			hostname[128];
struct 		sockaddr_in     sockaddr_in_struct;  
int	      sockid;
struct 		sockaddr_in server;
int retval,length,a,b,c;
char x;
struct fd_set readfds,writefds,exceptfds;
struct timeval timeout;
struct hostent *hp,*gethostbyname();

/* Get  a socket */
	sockid	= 		socket(AF_INET,SOCK_STREAM,0);

/* make in NONBLOCKING */
	x=1;
	if(ioctl(sockid,FIONBIO,&x)==-1)
			printf("Cannot unblock sock socket");
	server.sin_family = AF_INET;

/* fill in server details */	
	hp = gethostbyname ("server");
	if(hp==0)
		perror("gethostbyname");
	
	(void)bcopy((char *)hp->h_addr,(char *)&server.sin_addr,hp->h_length);
/* set up the servers port number */
	server.sin_port = (unsigned short)htons(1395);

/* connect up the socket */
/* this call returns with EINPROGRESS */	
	if(connect(sockid,(struct sockaddr *)&server,sizeof(server))==-1)
		perror("Connect returns ");

/* set up the select call */
	timeout.tv_sec=0;
	timeout.tv_usec=0;
	FD_ZERO(&writefds);
	FD_SET(sockid,&writefds);
	select(FD_SETSIZE,(fd_set *)NULL,&writefds,(fd_set *)NULL,&timeout);

	/* now see if we can legally write in this socket */
	if(FD_ISSET(sockid,&writefds)){
		printf("Select says OK to write\n");
		/* we get as far as here and then we are bombed back to SUNOS*/
		if(write(sockid,"abcdefghij",10) == -1){
			perror("Write failed !!");
			printf("Explain that one !!\n");
      }
    }
 printf ("This line never gets printed because the write() call never returns");
}

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 91 14:41:25 GMT
From:      jcurran@SH.CS.NET (John Curran)
To:        comp.protocols.tcp-ip
Subject:   Dialup IP 2.0 software location

Here's the right locations:

bbn.com: pub/dialup2.0.tar.Z
uunet.uu.net: networking/dialupip2.0.tar.Z

If anyone has problems getting these, let me know.
/John

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 91 15:00:42 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re:  When is a link saturated?


    You're overlooking a point here:  the *hosts* are just as involved
    in this process -- they *must* use proper type-of-service labelling
    of their packets (as per Host Req.) for this to work.

Note that Assigned Numbers actually specifies the TOS values.  In terms of
installed base, V2.05 of PC/TCP (out since 10/90) conforms to RFC 1060 on
TOS for Telnet, FTP, SMTP, Rlogin and DNS lookups.  So do programs which use
high-level Telnet, Rlogin & FTP libraries from v2.05 of our Developer's Kit.

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

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 91 17:05:53 GMT
From:      kseshadr@quasar.intel.com (Kishore Seshadri)
To:        comp.protocols.tcp-ip
Subject:   Re: When is a link saturated?

Christian Huitema writes:
 > 
 > A promising scheme, which I heard several time, is to manage one queue per
 > source host. The idea here is to give an even share of the network to every
 > station; it is also an incentive to implement decent end to end flow controls
 > (e.g. slow start) as the rogue TCP which use very long queues will observe very
 > long transit delays and thus very poor performance, while the correct TCP will
 > work normally. I dont know whether cisco or others plan to implement that.
 > 

This may not work well, considering that there are always hosts on a
network that legitimately send and receive more network traffic than
others. A fileserver for example may appear to be a network pig compared
to a workstation...as might a mailserver. It seems to me that we would
have to think up schemes that are somewhat more sophisticated. This
scheme that you describe sounds uncomfortably close to circuit switching
techniques that are so dear to our phone companies ;-)

Using the priority parameter in the datagram header is probably a much
better approach. I much prefer to have the communicating hosts try and
prioritize their own communications. Applications that have a genuine
need for high priority service should be able to provide hints to
entities between source and destination, requesting higher priority.

Kishore Seshadri

Kishore Seshadri,(speaking for myself)       <kseshadr@mipos3.intel.com>
Intel Corporation                            <..!intelca!mipos3!kseshadr>
"When the only tool you own is a hammer, every problem begins to resemble
 a nail" -Abraham Maslow

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 91 18:06:13 GMT
From:      ejm@ejmmips.NOC.Vitalink.COM (Erik J. Murrey)
To:        comp.dcom.modems,comp.protocols.tcp-ip
Subject:   Re: V32bis

In article <1991Jan16.210914.18482@robobar.co.uk>, ronald@robobar.co.uk
(Ronald S H Khoo) writes:
> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes in defence of the TB+:
> 
> > On the contrary, X terminals would benefit from a good asymmetric splitting
> > of bandwidth.
> 
> But PEP doesn't give you split bandwidth, it gives you half duplex with
> extremely high cost to turn the line around.  Now, if you had a
> link-level protocol that reduced the number of turnrounds by letting
> whole windows through before letting the other side speak, you might
> win.  SLIP doesn't do this though, and my cursory glance at PPP doesn't
> show such an option there either (though I'd be glad to be told that I'm
> wrong).  Am I ? Does such a protocol exist ?
> 

Both SLIP and PPP only look as far as the IP header for clues on
delivery.  Even this may be considered too much of a bleed into the
network layer when a point-to-point data-link is involved. Both Van
Jacobson's Compressed SLIP and his extensions to PPP look as far as
the TCP header to determine compressability.

If SLIP or PPP were to provide TCP window optimization over the
data-link, then it would have to really dig into both the TCP header
and the TCP options to determine window size/status, etc.

While sometimes these optimizations are necessary to give a product an
edge in the market, I usually shy away from code that is *too* smart.

I tend to think that better optimization of IP over half-duplex links
can be done with smarter queuing algorithms coupled with starvation
prevention measures.  On the local machine, this may actually give the
feeling that entire windows are being sent at once, since all the
segments may be queued in one shot from the TCP code.

---
Erik J. Murrey
Vitalink Communications NOC
ejm@NOC.Vitalink.COM	...!uunet!NOC.Vitalink.COM!ejm

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 91 18:38:31 GMT
From:      kline@ux1.cso.uiuc.edu (Charley Kline)
To:        comp.protocols.tcp-ip
Subject:   Lantronix ETS terminal servers

Does anyone else out there have an EPS-4 or ETS-8 little terminal
server from Lantronix? It seemed like just the thing for my small
(two-line) dedicated serial-over-TCP application, and since I've gotten
it, I've found it to be a nice little box except for its performance.
It doesn't seem to be able to even keep up with ONE 4800 bps serial
line without issuing frequent flow control.  I had certainly hoped for
better than this.

Has anyone else noticed this performance problem? Am I doing something
wrong?

________________________________________________________________________
Charley Kline, KB9FFK, PP-ASEL                          c-kline@uiuc.edu
University of Illinois Computing Services            Packet: kb9ffk@w9yh
1304 W. Springfield Ave, Urbana IL  61801                 (217) 333-3339

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 91 18:44:42 GMT
From:      dnb@meshugge.media.mit.edu (David N. Blank)
To:        comp.protocols.tcp-ip
Subject:   Re: phone number to get off LOTUS Marketplace: Households

> If you want to get off the database, you can call LOTUS customer
> service at (800) 225-5800 and asked to be removed.

I just called and received a message which said that this number was
incorrect (it actually said "if you are calling to have your name
removed...", so there apparently are quite a number of people
calling).  The recording mentioned that the correct number is:
         *  1-800-688-8320  *
  
              Peace,
                dNb

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 91 20:05:06 GMT
From:      cec@cup.portal.com (Cerafin E Castillo)
To:        comp.protocols.tcp-ip,comp.dcom.modems
Subject:   Re: Dialup IP release

Does this Dial-up IP program contain CSLIP?  Any plans for a PPP
version?

If CSLIP (ie Van Jacobson Header Compression) is included does it
allow auto-recognition of SLIP and CSLIP tokens?  Can auto-recognition
be turned off, force CSLIP only, or disable CSLIP?

Thanks in advance for the info.

===============================================================================
Cerafin E. Castillo                       ||      //\\  ||\\  ||
Network Consultant                        ||     //__\\ || \\ ||  Los Altos
Los Altos Networks                        ||    // ---\\||  \\||  Networks
340 Second St. #6                         ||___//      \ |   \ |
Los Altos, CA  94022
(415) 941-8031      UUCP:     {apple,sun,uunet}!portal!cup.portal.com!cec
                INTERNET:     cec@cup.portal.com

                      "...No hay mal que por bien no venga..."
===============================================================================

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 91 20:12:23 GMT
From:      tsuchiya@THUMPER.BELLCORE.COM (Paul Tsuchiya)
To:        comp.protocols.tcp-ip
Subject:   Re: An INTERESTING Problem


A couple of days ago Tracy Mallory mentioned that
I had a method of assigning subnet numbers prevents
one from having to determine in advance where the
subnet/host boundary goes.  Well, I do, and it has
been submitted to become an internet draft, shortly
after which it will be an rfc.

Anyway, if people are interested, I have made it
available via anonymous ftp on thumper.bellcore.com:subnet.
I'd love any improvements you might suggest.

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 91 21:19:10 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Want 8-bit/256 character clean TELNET session -- is it possible?


  I want to dial in to a Xylogics Annex IIe terminal server and then
connect to a application server on a machine on our network listening on
port FOO.  I want that connection to be 8-bit/256 character clean.  I.e.
completely transparent.

  The Annex knows how to RLOGIN and TELNET.

  RLOGIN is out because there's no way to connect up to anything except
an RLOGIN daemon on TCP port 513.

  With TELNET I can connect up to any TCP port I want to, but so far I
can't see how to negotiate an 8-bit/256 character clean channel.  Is it
possible to do this?  Do I need to write an RFC suggesting this?

Casey

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 91 21:57:17 GMT
From:      smiles@ferrari.nmc.ed.ray.com (Kevin Ruddy)
To:        comp.protocols.tcp-ip
Subject:   Mac telnet solutions

I know of NCSA Telnet for the Mac, and I understand there's a Stanford
solution, too.  Are there any others?  I'm interested in commercial
solutions also.

Thanks in advance,
Kevin Ruddy
smiles@ferrari.nmc.ed.ray.com

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 91 22:16:58 GMT
From:      dricejb@drilex.UUCP (Craig Jackson drilex1)
To:        comp.protocols.tcp-ip
Subject:   Curiosity about Class B vs Class C

It's looking like it's time to get some real internet addresses around
here, and I have a curiosity about whether to try to get a Class B
and subnet it, vs a bunch of Class Cs.

It seems to me that in choosing between a subnetted class B vs a bunch of
class Cs, the 'cost' will be the same within one's own net.  ('cost' being
size of router packets, etc.)  The real advantages of a class B only
show up when you connect your net to a larger internet.  In addition,
the additional 'costs' of the class Cs are borne by the rest of the
internet, rather than by the owner of the class Cs.  (Assuming that
both the class B and the nest of class Cs would have one gateway to
the given internet.)

Am I correct?  If I think that the chances on our joining an internet outside
of our company are slim and none, but think I need quite a few nets, is
there any reason to work extra to get a class B?
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 91 23:36:53 GMT
From:      ktaylor@supernet.dallas.haus.com (Kurt Taylor)
To:        comp.protocols.tcp-ip
Subject:   SNMP Network Management

I am sorry if this is a subject that has been beat to death, but...

Could someone please point me in the direction of any information
about SNMP ? Specifically, I am looking for a good general overview.
It can be in any form (Magazine article, FTPable, e-mail, listserv,
etc...).

Thanks in advance,
Kurt Taylor

-- 
  +--------+      Kurt Taylor --> ktaylor@supernet.haus.com 
  | HARRIS |      Harris Adacom Corporation
  | ADACOM |      PO Box 809022, Dallas, Tx 75380-9022
  +--------+      Disclaimer type thing.  Blah. Blah. Blah.

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 91 23:48:29 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.dcom.modems,comp.protocols.tcp-ip
Subject:   Re: V32bis

In article <1991Jan16.210914.18482@robobar.co.uk>, ronald@robobar.co.uk (Ronald S H Khoo) writes:
> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes in defence of the TB+:
> 
> > On the contrary, X terminals would benefit from a good asymmetric splitting
> > of bandwidth.
> 
> But PEP doesn't give you split bandwidth, it gives you half duplex with
> extremely high cost to turn the line around. ...



I was trying to say is that a magical way to automatically and dynamically
allocate bandwidth between the two directions would be better than any
fixed allocation, including 50/50.  Whether this magic would consist of
devoting 100% of the bandwidth to one direction for X% of the time and 100%
of the bandwidth to the other direction for (100-X-Z)% of the time
(ie.  what is often called "half duplex") is an separate issue.  It may be
that at the low speeds and analog phone lines being discussed, no such
magic is possible, or that the magic would cost too many bits computed as
[sum (wasted bandwidth*wasted time)].  I've not been initiated into the
right kinds of wizardry to know.

It is obvious that if you must fix the allocation between the two
directions (if the system including modems cannot change this allocation as
traffic or other conditions warrent) and if your traffic is "general," then
50/50 is the best general purpose answer (e.g. v.32), provided 50% of the
total is gives usable performance.  It seems obvious that an old fashioned,
half-duplex 2400 b/s modem with would support X traffic less badly than a
1200 b/s full duplex modem, despite the long turn-around times of such
old hdx modems.

At medium and high speed, things tend to be more dynamic.  Imagine how slow
ethernet would be if the ~10MHz were permanently partitioned into rx and tx
allocations for each station.  (Common, commercially available, relatively
low cost workstations move >1MByte/sec through TCP/IP/ethernet.)


Sheesh!  I didn't realize I was so mumble-mouthed to be repeatedly
misunderstood on such an obvious point.

Vernon Schryver,   vjs@sgi.com

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 91 01:44:33 GMT
From:      cec@cup.portal.com (Cerafin E Castillo)
To:        comp.dcom.modems,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Dial-up IP and Voice on the same line?

I have heard of a 56 Kbps DSU/CSU application available from Republic
Telecom (?) that will do Voice and Data over the same 56 Kbps line.
Has anyone tried this product?  Does it work?  Any reason why I wouldn't
want to do SLIP/CSLIP/PPP and Voice over the same 56 Kbps link?

Any observations would be greatly appreciated.

===============================================================================
Cerafin E. Castillo                       ||      //\\  ||\\  ||
Network Consultant                        ||     //__\\ || \\ ||  Los Altos
Los Altos Networks                        ||    // ---\\||  \\||  Networks
340 Second St. #6                         ||___//      \ |   \ |
Los Altos, CA  94022
(415) 941-8031      UUCP:     {apple,sun,uunet}!portal!cup.portal.com!cec
                INTERNET:     cec@cup.portal.com

                      "...No hay mal que por bien no venga..."
===============================================================================

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 91 05:26:11 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.protocols.tcp-ip
Subject:   ethernet over 1000" of twisted pair?

Is there any technology available for running ethernet over
twisted pair for a stretch of 1000 feet or more?
-- 
Ken Mandelberg      | km@mathcs.emory.edu          PREFERRED
Emory University    | {rutgers,gatech}!emory!km    UUCP 
Dept of Math and CS | km@emory.bitnet              NON-DOMAIN BITNET  
Atlanta, GA 30322   | Phone: Voice (404) 727-7963, FAX 727-5611

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 91 10:26:12 GMT
From:      ronald@integow.uucp (Ronald Wopereis)
To:        alt.sources.wanted,bit.listserv.aix-l,bit.listserv.ibm-nets,bit.listserv.ibmtcp-l,bit.listserv.tn3270-l,comp.protocols.tcp-ip,comp.unix.aix
Subject:   RE: UNIX to AS/400 , telnet , tn3270, 5250 ?

: Folks,
: 
: I am looking for a connection to make between a UNIX box ( Motorola, Sun
: Sparc ) and an IBM AS/400 over TCP/IP.
: 
: I have the tn3270 program, but from what I've heard, I need a different
: protocol to talk to the IBM AS/400, which is said to be the 5250 protocol.
: 
: 
: Questions that I have are :
: 
: 	
:	(1) Is there a program available ( freeware or commercial
:		package ? ) I saw Rabbit software offers the
:		RabbitPLUS 3270 (TM) package, but can I talk to
:		the AS/400 with this protocol ?
:	
:	(2) Does anyone out there have any experience in connecting
:		these two machines ?
:
:Thank you all who've read this far.
:-- 
:UUCP: ..!uunet!mcsun!hp4nl!integow!ronald  or  ronald@integow.uucp 
:Ronald Wopereis, Consultancy Manager, Integrity Software Consultants, 
:         Pelmolenlaan 16, 3447 GW Woerden, Netherlands,
:            tel +31 3480-30131, fax +31 3480-30182
:

Amongst several responses ( thank you all ) there was a direct telephone
call from IBM in the US to the Netherlands in order to provide an answer
to this question. What a service! ( Thank you, Mark B. )

The answer is following ( please correct me if I'm wrong, Mark ) :

	(1) The AS/400 fully supports the 3270 protocol. This means
		that using the tn3270 program enables you to connect
		your Unix terminal to the AS/400.
	
	(2) For the problem of different function keys on the Unix
		terminal : One of the CL-commands on the AS/400 named
		"CHGKBDMAP" takes care of it. 
	
	(3) MI-TECH ( hope I spelled this correctly ) - I think they are
		located in Texas - recently annnounced a TN5250 program
		or package ( about two months ago )
	
	(4) IBM is working on getting the 5250 protocol into an RFC.


Ron.
-- 
UUCP: ..!uunet!mcsun!hp4nl!integow!ronald  or  ronald@integow.uucp 
Ronald Wopereis, Consultancy Manager, Integrity Software Consultants, 
         Pelmolenlaan 16, 3447 GW Woerden, Netherlands,
            tel +31 3480-30131, fax +31 3480-30182

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 91 12:00:21 GMT
From:      cliffb@isavax.isa.com (cliff bedore*)
To:        comp.protocols.tcp-ip
Subject:   Re: What service broadcasts on UDP port 60000?

In article <9101162103.AA12082@thdsun.EPM.ORNL.GOV> dunigan@THDSUN.EPM.ORNL.GOV (Tom Dunigan 576-2522) writes:
>we're trying to figure out what service is broadcasting on
>UDP port 60000.  It's coming from an SCO Xenix engine
>with Lachman TCP/IP.
>thanks

What I've been told is that SCO is broadcasting their license number so that
if another host hears its license number it will "shut down" tcp in some
manner.  Its apparently a copy protection scheme.

Cliff

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 91 14:24:25 GMT
From:      hubcap@hubcap.clemson.edu (System Janitor)
To:        comp.protocols.tcp-ip
Subject:   port 20 (FTP-DATA)

howdy -

A brief look at RFCs 1010 and 959 leads me to believe that all these 
seemingly hung connections to port 20 on my machine are probably ftp
connections that failed somewhere during the initial (or closing ?) 
hand-shaking.

I'm guessing this probably indicates some network connectivity problem between 
``here and there'' and is really nothing for me, as system janitor of
this machine, to worry about... or is there?

tcp        0    250  130.127.8.1.20         XXX.XX.X.XXX.47585     CLOSING
tcp        0    214  130.127.8.1.20         XXX.XX.X.XXX.47586     CLOSING
tcp        0    250  130.127.8.1.20         XXX.XX.X.XXX.47587     CLOSING
tcp        0    214  130.127.8.1.20         XXX.XX.X.XXX.47341     CLOSING
tcp        0     25  130.127.8.1.20         XXX.XX.X.XXX.47342     CLOSING
tcp        0    250  130.127.8.1.20         XXX.XX.X.XXX.47343     CLOSING
tcp        0    427  130.127.8.1.20         XXX.XX.X.XXX.43574     CLOSING
tcp        0    373  130.127.8.1.20         XXX.XX.X.XXX.43575     CLOSING
tcp        0    427  130.127.8.1.20         XXX.XX.X.XXX.43576     CLOSING

-Mike

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 91 15:34:35 GMT
From:      esanborn@SPARTA.SPARTACUS.COM (Edward Sanborn)
To:        comp.protocols.tcp-ip
Subject:   subscription


Please take me off the mailing list.   Thanks!

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 91 15:57:37 GMT
From:      rlg@desktalk.com (Richard L. Gralnik)
To:        comp.protocols.tcp-ip
Subject:   Getting deleted from Lotus' Consumer Database

Hi folks,
There was a phone number published here recently which you could call to
have Lotus remove your name from their database list.  I called that 
number (long distance from here!) and was directed to dial a new number.
This number has an answering machine which asks for your name and address
so Lotus can send you a 'name removal kit'.

The number is

(800) 688-8320

Isn't Lotus wonderful.  They include your name without asking permission,
then make you fill out a bunch of paperwork to get your name removed.
(Note: I would NOT give them your Soc. Sec. number).

Richard
(rlg@desktalk.com)

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 91 16:34:44 GMT
From:      rgoldstone@OAVAX.CSUCHICO.EDU (Robin Goldstone)
To:        comp.protocols.tcp-ip
Subject:   Re: Mac telnet solutions

In article <9101172157.AA27711@ferrari.nmc.ed.ray.com>, 
smiles@ferrari.nmc.ed.ray.com (Kevin Ruddy) writes:
>I know of NCSA Telnet for the Mac, and I understand there's a Stanford
>solution, too.  Are there any others?  I'm interested in commercial
>solutions also.

Synergy Software just announced new releases of VersaTerm and VersaTerm PRO
that will support TCP/IP through the communications toolbox.  They will be 
distributed with MacTCP.  VersaTerm is around $90, VTP is several hundred
dollars.  The new versions (VT 4.5, VTP 3.5) are not yet available but I saw
them at MacWorld.  Should be available in about 1 month.  I have been using
VersaTerm for several years and IMHO it does the best job of VT100 emulation
of any comm software I have used.

Synergy Software: (215) 779-0522
***********************************************************************
Robin Goldstone, California State University, Chico  Computing Services
rgoldstone@oavax.csuchico.edu

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 91 17:56:12 GMT
From:      dan@lclark.UUCP (Dan Revel)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   How do I configure a SLIP connection (VAX/750 4.3bsd)

OK, our VAX is on its last leg, but I still would like to squeeze
a little more service out of it by setting up a SLIP connection
between it and a Xylogics AnnexIIe terminal server to connect to
our campus ethernet.  The Xylogics end seems pretty clear... but
what do I need to do at the VAX end (750, vanilla 4.3 bsd unix)

I tried: 

# slattach /dev/tty00 9600
ioctl (TIOCSETD): No such device

and also:

# ifconfig tty00 inet lclark annex31
ioctl (SIOCGIFFLAGS): no such interface

(lclark and annex31 are defined in /etc/hosts)

My kernel is config'd with the INET option.  Do I need to add a
pseudo-device ether?  What else do I need to do?

Thanks,
Dan

Note:
This is a reposting with a wider distribution (na vs. pnw)
and crossposting to comp.protocols.tcp-ip.

-- 
dan@lclark.bitnet					SM 0 A9F4
tektronix!reed!lclark!dan				G 0

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 91 18:43:38 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: Want 8-bit/256 character clean TELNET session -- is it possible?


  Well, from cruising through the various TELNET RFCs, it look like it's
impossible to establish an 8-bit/256 character clean *and* efficient
channel.  Moreover, it appears to be impossible to do this automatically
from the server.

  Even if you enable TELNET BINARY mode and set tesc to UNDEFINED (which
I only presume will work, not having had a chance to test it), the client
(in the Annex) is forced to constantly scan for IAC (the TELNET command
escape) in both the inbound and outbout data streams.  I suppose that
this isn't much load on the Annex, but it sure would be nice just to be
able to say ``open host port'' from the Annex CLI (Command Line
Interface) and have the Annex open a TCP connection to the indicated host
and port and then step out of the way.

  More seriously, it doesn't appear to be possible for the server to
negotiate away the client ESCAPE processing; primarily because ESCAPE
processing isn't part of the TELNET protocol.  ESCAPE processing is a
client function.  It sounds to me as if an intelligent client should
automatically turn off ESCAPE processing if a server requests BINARY
mode, but, unfortunately, that's not even recommended by the standards as
far as I can see.

  (sigh) I think I'm screwed.

Casey

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 91 18:53:04 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Curiosity about Class B vs Class C

In article <20839@drilex.UUCP> dricejb@drilex.UUCP (Craig Jackson drilex1) writes:
>It's looking like it's time to get some real internet addresses around
>here, and I have a curiosity about whether to try to get a Class B
>and subnet it, vs a bunch of Class Cs.
 
>Am I correct?  If I think that the chances on our joining an internet outside
>of our company are slim and none, but think I need quite a few nets, is
>there any reason to work extra to get a class B?

Your description of the routing overhead in the two approaches is correct.
An advantage of class C networks over a subnetted class B net is that most
TCP/IP software will default the subnet mask automatically if you don't
specify it.

Of course, if you aren't ever going to connect your network to an outside
internet, then you don't even have to get an officially-registered network
number; you can even give yourself a class A network if you want!  Also,
you say "work extra to get a class B"; my understanding is that it should
be easier to get a single class B network number than a bunch of class C's,
because they assume that you'll be connecting to the Internet and they
don't want to bloat the routing tables.  We were given a class B network
last year so that we could consolidate about a half-dozen class C networks.

But if you want to leave the possibility open, and don't want to have to
reassign addresses to all your hosts (which, by the way, is tedious, but
not really as hard as it is often made out to be -- due to the
aforementioned consolidation, over the last six months we've changed the
addresses of most hosts on our net (about 400 Unix systems and at least 60
Macs), and changed many of the Suns twice), then getting official network
numbers is a good idea.

Subnetting a class B makes some network management and administration tasks
easier.  You get to decide how many bits to allocate to subnet number; the
NIC probably won't give you 254 class C's, but you can probably use eight
bits of a class B as the subnet number.  Since you control the subnet
numbers, you can attach semantics; for instance, on our network, subnets
1-15 contain hosts directly accessible from the outside networks, subnets
16-127 are for administrative and research computers, and subnets 128-254
are for development computers, and our router packet filters can easily
recognize these blocks of addresses using bitmasks.  This also makes it
easier to recognize and remember your network numbers, as they are
effectively only two or three digits long (the two-octet class B prefix
will quickly become automatic).  On the other hand, if you get class C
nets, the network numbers will be pretty arbitrary and may not even be
consecutive (especially if you get more networks later on).
--
Barry Margolin, Thinking Machines Corp.

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

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 91 18:54:10 GMT
From:      guy@b11.ingr.com (Guy Streeter)
To:        comp.protocols.tcp-ip
Subject:   Re: Problems w/ PPP and setsid

mclay@vato.ae.utexas.edu (Robert McLay) writes:

>When I use PPP over a serial line between a sun4/330 and a sun 4/20
>both running sunOS 4.1, I get the following error message:
 
>ppp: setsid(): Not owner.
 
>and the connection over the modem hangs up.
 [...]
>Here is what pppstart looks like:
 
>#!/bin/sh
>/usr/bin/mesg n
>stty -tostop hupcl
>exec /usr/local/etc/ppp -p 128.83.152.29:

Take the 'exec' out.  When ppp is compiled to use setsid() it should
not be exec-ed.  "Not Owner" is this particular case apparently means
"Already Owner", and why it is an error is beyond my ken, but removing
the 'exec' fixes it.

--
Guy Streeter,
streeter@ingr.com
...uunet!ingr!b11!guy!guy

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 91 23:12:40 GMT
From:      anthony@NMS.HLS.COM (Anthony Chung)
To:        comp.protocols.tcp-ip
Subject:   TCP Urgent flag with TELNET DATA MARK



In Telnet Specs, DATA MARK should be sent with TCP URGENT flag set.
I found SUN's implementation does not send TCP URGENT with TELNET DATA
MARK all the times.  Is it required to send DATA MARK with TCP Urgent?

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 91 23:35:58 GMT
From:      swansonc@acc.stolaf.edu (Chris Swanson, St. Olaf College)
To:        comp.protocols.tcp-ip
Subject:   PPP (Again:()


I was wondering if anyone out there could enlighten me as to what PPP
is and where I can get it.  What kind of pros and cons does it have
with slip and dialup ip?

A few people replied yesterday, but due to a slip (no pun intended) of
the fingers, I blew away all of my mail from the last 2 days before I
got a chance to read it.  Sorry.

E-mail a reply if you would.

	-Chris

--
Chris Swanson, Chem/CS/Pre-med Undergrad, St. Olaf College, Northfield,MN 55057
	INTERNET:  swansonc@acc.stolaf.edu	UUCP: swansonc@stolaf
    	AT&T:	   Work: (507)-645-6845		Home: (507)-663-6424
	I would deny this reality, but that wouldn't pay the bills...

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 91 00:10:23 GMT
From:      paulc@rchland.iinus1.ibm.com (Paul Chmielewski)
To:        comp.protocols.tcp-ip
Subject:   Re: UNIX to AS/400 , telnet , tn3270, 5250 ?

>   I have the tn3270 program, but from what I've heard, I need a different
>   protocol to talk to the IBM AS/400, which is said to be the 5250 protocol.

You can use tn3270 to talk to the IBM AS/400.  The AS/400 Telnet server will
convert the 3270 data stream to 5250, which is the native data stream language
on the AS/400.

> IBM has apparently developed a 5250-over-Telnet scheme, which may or may not
> resemble current 3270-over-Telnet practice.  I am not aware of any movement
> to publish this as a standard, but maybe I haven't asked in the right places.

We do plan on publishing the 5250-over-Telnet scheme.  It should be made
available "very soon".

 Paul Chmielewski
 <paulc@rchland.iinus1.ibm.com>

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 91 14:12:06 GMT
From:      urlichs@smurf.sub.org (Matthias Urlichs)
To:        comp.protocols.tcp-ip
Subject:   Re: What service broadcasts on UDP port 60000?

In comp.protocols.tcp-ip, article <9101162103.AA12082@thdsun.EPM.ORNL.GOV>,
  dunigan@THDSUN.EPM.ORNL.GOV (Tom Dunigan 576-2522) writes:
< we're trying to figure out what service is broadcasting on
< UDP port 60000.  It's coming from an SCO Xenix engine
< with Lachman TCP/IP.

It looks like they are trying to verify the uniqueness of their serial number.

Nothing you can do about it, I'm afraid...

-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de     /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330)   \o)/

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 91 22:45:22 GMT
From:      aggarwal@NISC.JVNC.NET (Vikas Aggarwal)
To:        comp.protocols.tcp-ip
Subject:   Protocol field in PPP packets


Maybe this has been discussed before or maybe its too obvious, but if
I construe things correctly, every PPP packet has a "protocol" field
which identifies the packet (IP, CSLIP, DECnet, etc.).

Unless a number of protocol connections are established concurrently over
one link, isn't that an antithesis of what CSLIP is all about (redundant
information after the initial setup) ?? Or maybe I *am* reading the RFC
with too many protocols in my fuzzy fuzz !!


 -vikas
 vikas@jvnc.net						(609) 258-2403
--------------------------------------------------------------------------

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 91 04:01:30 GMT
From:      srg@quick.com (Spencer Garrett)
To:        comp.protocols.tcp-ip
Subject:   Re: When is a link saturated?

-> I don't understand why the "remember the first exchange" is necessary. 
-> Both telnet and rlogin use a reserved port number that appears in either
-> the source or destination TCP port fields on *every* packet that is
-> routed for the entire session.

Alas, no.  A server is free to answer the connection request
with a different port number, and they commonly do.  (The reason
for this eludes me.  It is permitted by the RFC's, but not
required or particularly encouraged.)

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 91 04:18:45 GMT
From:      bob@netlabs.com (Bob Rench)
To:        comp.protocols.tcp-ip
Subject:   SCO/Lachman port 60000


Someone recently asked about a service using port 60000 on SCO Unix running
Lachman TCP.  Evidently, this seems to be some type of copy protection
scheme.  If you buy a single-user copy of TCP, and try to run it on more
than one machine, one of them will freeze up.  I forget what the error
message is.  The workaround is to buy a multi-user copy license.


Bob Rench
10920 Wilshire Blvd., # 1103
Los Angeles, Ca.,  90024
(213) 824-2500
(213) 443-9740 - FAX

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The opinions expressed herein are mine!  You can't have them!
Besides, I can barely speak for myself, much less a company like NetLabs.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 91 08:19:07 GMT
From:      ronnie@crystel.UUCP (Ron Schnell)
To:        comp.protocols.tcp-ip
Subject:   Looking for special SLIP software

Is there any software which will work well on systems which use
SLIP through one of the commercial SLIP access services?  The problem
is that when we login, the remote machine prints out the IP
address you are assigned, which changes every time.  So we end up
using "tip", doing a "~!" running slattach, then going back and
killing tip.  I would like to automate this.

Thanks,
#Ron

(Please reply to ronnie@eddie.mit.edu)

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 91 14:39:52 GMT
From:      reschly@BRL.MIL ("Robert J. Reschly Jr.")
To:        comp.protocols.tcp-ip
Subject:   Re: Curiosity about Class B vs Class C


      Craig,

   Barry covered things pretty well.  The only other issue which comes
to mind is that many IPs derived from BSD code allow you to set a
"subnets are local" flag.  Setting this flag causes the code to generate
MTU sized datagrams rather than 576 octet datagrams for all subnet
destinations.  In most subnetted environments, this is a significant
win.

				Later,
				    Bob 
   --------
IP: reschly@BRL.MIL   UUCP: ...!{{cmcl2,nlm-mcs,husc6}!adm,smoke}!reschly
U.S. Army Ballistic Research Lab. / Systems Eng. & Concepts Analysis Div. /
Networking & Systems Dev. Team / Aberdeen Proving Grounds, MD  21005-5066 /
ATTN: SLCBR-SE-A (Reschly) //   (301) 278-6808   FAX:-5075   DSN:298-

****  For a good time, call: (303) 499-7111.   Seriously!  ****

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 01:57:59 GMT
From:      ericd@sco.COM (Sharky the Lanshark)
To:        comp.protocols.tcp-ip
Subject:   Re: What service broadcasts on UDP port 60000?


In article <i1kbh2.=28@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:
>< we're trying to figure out what service is broadcasting on
>< UDP port 60000.  It's coming from an SCO Xenix engine
>< with Lachman TCP/IP.
>It looks like they are trying to verify the uniqueness of their serial number.

Correct..

>Nothing you can do about it, I'm afraid...S

Close, it is possible to obtain a patch that will reduce how often 
the Copy Protection Daemon (CPD) bradcasts to the network.

Details below:


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Eric Davis                      () INTERNET -=> ericd@sco.COM
Technical Support Engineer II   () UUCP     -=> {uunet|sun|att|ucsc}!sco!ericd
(Lanshark Support Team)         () VOX      -=> US + 408 425 7222
                                () FAX      -=> US + 408 427 5443
                                () TWX      -=> 910-598-4510 sco sacz
				() HOME     -=> ericd@bumby.santa-cruz.ca.US
The Santa Cruz Operation, Inc.  ()=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
399 Encinal Street              () "We are the people our parents warned us
Santa Cruz, California 95061    ()  about" -Jimmy Buffett
attn: ericd                     () #include <legal/network/disclamer.h>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Periodic network traffic on port 60000 causing unwanted network load.

KEYWORDS:  cpd daemon port 60000 network broadcast traffic unwanted load sls lng248 

RELEASE:  SCO TCP/IP Release 1.0.1 for SCO XENIX

PROBLEM: The copy protection daemon, cpd, periodically checks the network
	 for copy protection violations.  Unfortunately, this places an
	 unwelcome load on the network. 

SOLUTION: Support Level Supplement (SLS) lng248, installs a new cpd daemon 
	  that checks for copy protection violations less often.
	  This SLS is only for SCO TCP/IP Release 1.0.1.

	  Note that the same problem occurs with the cpd daemon for SCO 
	  TCP/IP Release 1.1.1 under SCO UNIX System V/386 and for the 
	  SCO TCP/IP included with Open Desktop Release 1.0.0. For these 
	  releases, SLS lng227 addresses the cpd problem.
	

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 02:51:06 GMT
From:      slimick@unix.cis.pitt.edu (John C Slimick)
To:        comp.protocols.tcp-ip
Subject:   WIN/3B Router Table


I am slowly getting WIN/3B to able to talk
on the internet, but all has not gone well.

Tonight's question has to do with the router table.
When I first boot up, and look into the router table
(the one that /usr/etc/route changes) I see lots of
routing information. Within the two minute life of such information
it's still there, but after two minutes the table essentially
empties. The reason that this is significant is that
I tried to modify the WIN/3B startup script to add the
address of my local gateway; the gateway was already 
in the table, and thus was rejected. So I wait two minutes
and manually add it to the now almost empty table.

What am I missing here?

Why am I not collecting router information after the initial
two minutes?

john slimick
university of pittsburgh at bradford
bradford pa
slimick@unix.cis.pitt.edu

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 05:57:24 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Want 8-bit/256 character clean TELNET session -- is it possible?

I have actually written a spec for the "telnet `don't telnet anymore'"
option, which allows a system to volunteer that it will never send
any more telnet command or negotiations.  The idea behind this was
to allow hosts/terminal servers that don't care about negotiations
after the initial setup phase to be able to stop looking for them,
and gain the efficiency that you are talking about.

This RFC has been up before the IETF telnet working group, on and off
again.  We can't seem to decide whether the potential usefullness of
the option outweighs the fact that it's such a disgusting kludge.

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

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 07:53:12 GMT
From:      ronald@robobar.co.uk (Ronald S H Khoo)
To:        comp.protocols.tcp-ip
Subject:   Re: What service broadcasts on UDP port 60000?

urlichs@smurf.sub.org (Matthias Urlichs) writes:

> < we're trying to figure out what service is broadcasting on
> < UDP port 60000.  It's coming from an SCO Xenix engine
> < with Lachman TCP/IP.
 
> It looks like they are trying to verify the uniqueness of their serial number.
> Nothing you can do about it, I'm afraid...

Depends on what you mean by "do about it".  You can't avoid running /etc/cpd,
the CoPyrightDaemon which broadcasts on udp.60000, but you can get
a version of cpd that only does it at startup.  Someone probably informed
SCO that the broadcasts make IP over pieces of wet string rather less
useable.

Support Level Suppement lng227 applies to SCO Unix TCP/IP and lng248
applies to SCO Xenix TCP 1.0.1 (the release version).

Both are available for anon UUCP from sosco or scolon.  Obviously you
can get them from SCO Support as well...

Disclaimer: I haven't actually tried them, though.

-- 
Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 09:10:19 GMT
From:      prc@erbe.se (Robert Claeson)
To:        comp.protocols.tcp-ip
Subject:   Re: Want 8-bit/256 character clean TELNET session -- is it possible?

In article <89746@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey Leedom) writes:

>  Even if you enable TELNET BINARY mode and set tesc to UNDEFINED (which
>I only presume will work, not having had a chance to test it), the client
>(in the Annex) is forced to constantly scan for IAC (the TELNET command
>escape) in both the inbound and outbout data streams.  I suppose that
>this isn't much load on the Annex, but it sure would be nice just to be
>able to say ``open host port'' from the Annex CLI (Command Line
>Interface) and have the Annex open a TCP connection to the indicated host
>and port and then step out of the way.

The "-r" flag to the Annex telnet command will open a raw TCP connection
without the telnet protocol.

Usage:

telnet -r host port

-- 
Robert Claeson                  |Reasonable mailers: rclaeson@erbe.se
ERBE DATA AB                    |      Dumb mailers: rclaeson%erbe.se@sunet.se
Jakobsberg, Sweden              |  Perverse mailers: rclaeson%erbe.se@encore.com
Any opinions expressed herein definitely belongs to me and not to my employer.

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 09:44:48 GMT
From:      tom@rsp.UUCP (Thomas Ruf)
To:        comp.protocols.tcp-ip
Subject:   Re: What service broadcasts on UDP port 60000?

dunigan@THDSUN.EPM.ORNL.GOV (Tom Dunigan 576-2522) writes:

>we're trying to figure out what service is broadcasting on
>UDP port 60000.  It's coming from an SCO Xenix engine
>with Lachman TCP/IP.
>thanks
The "service" in question is their copy protection scheme.

Thomas
-- 
Thomas Ruf	tom@rsp.de	Schneider & Koch GmbH	Schneider & Koch, Inc
{uunet,mcvax}!unido!rsp!tom	Germany			Palo Alto

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 10:58:44 GMT
From:      ajp@hpopd.pwd.hp.com (Andy Pearce)
To:        comp.protocols.tcp-ip
Subject:   Re: rfi: VMS TCP/IP products

Earlier this month I posted a request for information on products that
supply TCP/IP for VMS systems wanting to connect to IEEE 802.3
standard networks.  In this summary, I've tried to steer away from
product comparisons, but I have summarised the opinions expressed
in the responses.

Thanks to everyone who responded to the request.  I had a total of 28
responses from users of various VMS TCP/IP solutions, as well as
from suppliers.

The general consensus was that TGV Multinet is the most popular product 
around right now (recommended by over half of those who expressed a
preference).  As well as TCP/IP services it has an NFS server and
client option available, and implements Sun's RPC interface.  The
service and support are highly acclaimed.  No-one complained about it.
There is a good review of Multinet in Dec10, 1990 Digital review.

A little under a quarter of the preferees said they were quite
satisfied with Wollongong's product - WIN/TCP.  But there were also
complaints about its reliability (most from those who had switched to
Multinet).  As well as TCP/IP it also has NFS server and client
components, and it's RPC interface complies with the HP/Apollo NCS 
standard being adopted by OSF.

NRC Fusion product was mentioned by a number of people who had tried
it, but nobody expressed a firm preference.  It's apparently good, but
has or had SMTP bugs, and many respondents preferred Multinet.  Its
RCP interface also complies with NCS.

DEC has its own TCP/IP product called "VMS/Ultrix", "Ultrix connection", 
more commonly known as "UCX".  As well as TCP/IP there is an NFS server
available, but no NFS client.  It also has an RPC interface which
fully complies with the OSF NCS.  Some users complained about lack of 
features, installation, and reliability.  Distributors claim many of 
these problems have been solved in the latest version.

CMU-TEK TCP/IP was recommended by a few users.  This is from a group
at Carnegie Mellon University, is cheap and offers good support.

Rockwell CMC has TCP/IP Ethernet, and a TCP/IP for VMS Ethernet
interface card.  I had no user responses for this product.

Process Software Corp do TCPWare for VMS.  As well as TCP/IP this has 
NFS server and client, and implements Sun's RPC interface.  Again, no 
user responses.

There is an Excelan EXOS ethernet board available for single processor
machines, together with TCP/IP and NFS software.  No user response for
these products.  Novell took over Excelan's line of networking products 
and now support them.

DECnet for HPUX by Control Data Corporation gives you DECnet on an
HP9000, and may be what you need if you're just connecting a few
HP9000's into a VAX/VMS shop running DECnet.

HP's NS/VAX is not recommended for TCP/IP networking requirements.  
It provided NS and telnet between VMS and HP using an HP proprietary 
networking protocol (not TCP/IP).



Disclaimer:  The above information is what was given to me - I'm just
             passing it on.  If any of it is incorrect then please
             post corrections.  Also, if I've missed out a product
             that you can recommend, I'm sure people would like to
             know.  

--ajp

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 12:34:49 GMT
From:      scoggin@delmarva.UUCP (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   SNMP Network Management

The BEST book on the subject is The Simple Book by Marshall T. Rose (1990).
Marshall Rose is one of the heavy duty implementers in both the TCP/IP and 
OSI worlds.  Not only that, but he can write!  (An unusual combination)

Highly recommended.  Also, if you're in the market for an interesting book
on OSI, he wrote one entitled "The Open Book".

----------------------------------------------------------------------
John K. Scoggin, Jr.	
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		Fax:	(302) 451-5321
500 N. Wakefield Drive			Email:	uunet!delmarva!scoggin
Newark, DE  19714	                        delmarva!scoggin@uunet.UU.NET
"Never underestimate the bandwidth of a station wagon load of magnetic
 tapes screaming down the interstate!"			

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 13:29:27 GMT
From:      gd@aprm (Gary Dunn)
To:        comp.protocols.tcp-ip
Subject:   SCO TCP/IP copy protection

Text: 

When I first saw this in the group I thought it an unfortunate rumor,
but the note from "Sharky" tells me its true.

That SCO should build copy protection into their TCP/IP is an
abomination.  PC users fought for years to rid commercial software of
this pest, and won.

I had considered SCO to be the most desireable UNIX on a PC i386
platform, mostly due to wide acceptance in the marketplace, but if this
is how they treat their customers I won't go near it.
 
Gary Dunn, USARPAC DCSRM IMO                 |
Ft. Shafter LAN: aprm%gd               _   _ |
DDN: aprm%gd@shafter-emh2.army.mil    /.\ /.\|
Work phone:  (808) 438-2716           \_/|\_/
FAX: (808) 438-8954                      |
                                        /
 
        Democracy is based upon the conviction
        that there are extraordinary possibilities
        in ordinary people.
                  Harry Emerson Fosdick

 --- End of Message -----------

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 14:15:30 GMT
From:      jstewart@ccs.carleton.ca (John Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: When is a link saturated?

In article <1991Jan20.040130.18339@quick.com> srg@quick.com (Spencer Garrett) writes:
>-> I don't understand why the "remember the first exchange" is necessary. 
>-> Both telnet and rlogin use a reserved port number that appears in either
>-> the source or destination TCP port fields on *every* packet that is
>-> routed for the entire session.
>
>Alas, no.  A server is free to answer the connection request
>with a different port number, and they commonly do.  (The reason
>for this eludes me.  It is permitted by the RFC's, but not
>required or particularly encouraged.)

The main reason for doing so is to facilitate multiple sessions.  For example
if 10 people telnet to a machine, each user will get their own telnetd 
process communicating to them via a unique set of ports.  Now imagine how
difficult this would be to do if you could only have one process running 
connected to the well known telnet port.
-- 
---
Artificial Intelligence: What some programmers produce.
Artificial Stupidity:    What the rest of us produce.

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 14:36:42 GMT
From:      larryp@sco.COM (Larry Philps)
To:        comp.protocols.tcp-ip
Subject:   Re: What service broadcasts on UDP port 60000?

In <1991Jan18.120021.21189@isavax.isa.com> cliffb@isavax.isa.com (cliff bedore*) writes:

> In article <9101162103.AA12082@thdsun.EPM.ORNL.GOV> dunigan@THDSUN.EPM.ORNL.GOV (Tom Dunigan 576-2522) writes:
> >we're trying to figure out what service is broadcasting on
> >UDP port 60000.  It's coming from an SCO Xenix engine
> >with Lachman TCP/IP.
> >thanks
> 
> What I've been told is that SCO is broadcasting their license number so that
> if another host hears its license number it will "shut down" tcp in some
> manner.  Its apparently a copy protection scheme.

It is the networking copyright daemon, /etc/cpd.  It is indeed
broadcasting serial numbers.  Early versions did shut down networking
if somebody broadcast a duplicate serial number.  For some reason
that was not popular :-)  Anyway, newer versions just print nasty
messages when that happens.  Networking does not shut down.

---
Larry Philps,	 SCO Canada, Inc (Formerly: HCR Corporation)
Postman:  130 Bloor St. West, 10th floor, Toronto, Ontario.  M5S 1N5
InterNet: larryp@sco.COM  or larryp%scocan@uunet.uu.net
UUCP:	 {uunet,utcsri,sco}!scocan!larryp
Phone:	 (416) 922-1937
Fax:	 (416) 922-8397

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 15:34:18 GMT
From:      kre@cs.mu.OZ.AU (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Redirects, and multiple subnets on a cable

I sent a comment to Paul Tsuchiya wrt his internet draft
(draft-tsuchiya-subnetnos-00.txt) on subnet number allocation
policies.

This doesn't touch on the main subject of his draft, but a
side issue he mentions.

Paul says (in mail to me) ...

	Could you put your message on all of tcp-ip, so we can see what
	other people have to say about it?

So, here it is ...

	In there you say (wrt two subnets on one cable) ...

	   In fact, this is not such a bad solution,
	   because assuming that the gateway is capable of recognizing multiple
	   subnet numbers on the same subnet, the gateway will simply send the
	   host an ICMP Redirect [4], and subsequent packets will go directly to
	   the host [1].

	I don't think that can be true can it?  That would require the ICMP
	redirect to contain an ethernet address.  The sending host is in no
	doubt of the destination's IP address, sending a redirect that contains
	that address can do no more than confuse it, if its routing table has
	it believe that to reach that address it must route through a gateway.

	Oh - do you mean send the host a redirect, containing its own address
	as the gateway?  I guess that might work, assuming that the host's
	software understands the BSD type convention "if I am the gateway,
	I send directly out on my ethernet", if not, almost anything might
	happen.

	If that's it, I think I'd be more explicit about it.

To provide a little context - this is related to a cable being used
to carry two subnets, with a router somewhere on the cable configured
to forward between the two - and perhaps send redirects to hosts sending
through the router, when, with a little more intelligence, the host would
be able to send directly to the destination.

In a reply to that message, Paul indicated that the first of my two
scenarios was the one he intended, with the idea that on receiving a
redirect, (containing the hosts IP address as the gateway to send
through) the host receiving the redirect would not look inside it (much),
but would simply ARP for the "gateway" address drom the ICMP, and
end up sending directly to the destination.

Personally, I would expect that a host receiving a redirect like that
(if any gateway sent one) would simply ignore it - as a defence against
bogus redirects.

Anyway - comments?

kre

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 16:27:41 GMT
From:      mni@techops.cray.com (Michael Nittmann)
To:        comp.protocols.tcp-ip
Subject:   WS Query

Hi netfolks,

does anybody have interoperability experiences
(good, flames, rubbish) for a

	Sony NEWS Workstation?

Please, mail to me to keep the list free, I promise I shall
summary to the list end of next week.

michael

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 16:40:02 GMT
From:      cnolan@vax1.tcd.ie
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   NETWATCH won't link with packet.lib, help!

In article <7824@umd5.umd.edu>, dzoey@terminus.umd.edu (Joe Herman) writes:
> In article <1991Jan9.180145.2211@blister.Solbourne.COM> patrick@blister.Solbourne.COM (Patrick Bowman) writes:
>>I'm looking for an Ethernet line monitor program that runs on an IBM
>>PC and works through a standard Ethernet card (3Com, WD, etc.).  I
>>know that they exist  -  I've spoken to people who claim to have seen
>>them in operation.
> 
> The old PCIP distribution (available from husc6.harvard.edu) contains
> a simple ethernet monitor (netwatch) that displays the packets on an
> ethernet in real time.  It lacks much that professional ethernet
> monitors give you (performance, many many stats, traffic generation) but
> has the advantage of being free and in the public domain.  I believe
> that PCIP will now work with packet drivers.
> 
> I used this for a couple of years to debug some code I was writing and it
> was invaluable.
> 
> 				Joe Herman
> 				U. of Md.
> 
> dzoey@terminus.umd.edu
> 
> -- 
> "Everything is wonderful until you know something about it."
-- 

Ok, I got the PCIP distribution .tar (via BITFTP) and I merrily typed make all.
Of course I wanted it to run on packet drivers, so then I read the docs and
proceeded to compile more exe's using packet.lib.  This is fine for progs like
ping, telnet etc.  These run perfectly.  But I can't get NETWATCH to compile.
The one proram I wanted.  Can anyone advise?

Here is the link line from the makefile ...

link netwatch,dnetwatc/noi/noe,nul,h19 netwatch enetwatc net packet  task pc;

and here are the errors I get ...

_pproc in file(s):
 NETWATCH.LIB(display.c)
_pkts in file(s):
 NETWATCH.LIB(display.c)
_npackets in file(s):
 NETWATCH.LIB(time.c) NETWATCH.LIB(display.c) NETWATCH.OBJ(netwatch.c)
_prcv in file(s):
 NETWATCH.LIB(display.c)

Has anyone suddessfully got netwatch running over packet drivers?

Thanks ...

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

             
       	 	Conor Nolan			Phone:	772941 (X1741)
           	Microelectronics Dept.		Fax:	772442
            	Trinity College			
	      	Dublin 2			cnolan@mee.tcd.ie
  	     	IRELAND				ampere::cnolan
            

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

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 17:06:25 GMT
From:      ken@dali.cc.gatech.edu (Ken Seefried iii)
To:        comp.protocols.tcp-ip
Subject:   sources of info on SNMP

-----

I'm interested in getting more (electronic) information on
SNMP.  There doesn't seem to be a newsgroup, and the only
mailing list I can find a reference to in one for the MIT
SNMP development kit.  Where else might be an appropriate
place to discuss SNMP?

--
	ken seefried iii	"A sneer, a snarl, a whip that
	ken@dali.gatech.edu	 stings...these are a few of
				 my favorite things..."

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 17:58:54 GMT
From:      mann@star.enet.dec.com (Bruce Mann ZK1-3/J35 DTN 381-1298  21-Jan-1991 1257)
To:        comp.protocols.tcp-ip
Subject:   TELNET versus LAT

>But could a protocol be designed that had the advantages of LAT
>(multiple streams in one packet, rate limiting, etc.) that ran over a
>network protocol (such as DECnet routing without NSP), or had adaptive
>timeouts?  

	Yes. The LAT protocol encompases a number of features, but the
session aggregation feature is independent of the LAT being built
directly on the datalink layer of Ethernet. 
 
>Indeed, despite implementation problems, in some ways CTERM (the
>DECnet virtual terminal protocol) is a better protocol, since it can
>dynamically switch between local and remote echo, even in a screen
>editor.  Of course, the application has to be well written to gain the
>advantages of the CTERM protocol.
 
	LAT makes no such effort at these optimizations. CTERM, TELNET,
and/or VTP could be run over LAT without modifications to LAT. In fact,
LAT is designed to be extensible to do this. Achieving these benefits
however (local echo for instance) often come at the expense of application 
transparency without sufficient compensation in the form of increased 
performance/efficiency.

>Unfortunately, with LAT proprietary, the standards bodies won't get to
>learn from it in designing future protocols.  It would be nice if the
>ISO virtual terminal protocols could have had some of these advantages.
 
	To my knowledge, all useful protocols start out being proprietary,
and evolve into "open" status as they become more widely used. LAT is
certainly in this transition now.

	By the way, while I do agree all protocols can be routed (layer 3),
I do not agree all protocols should be routed. The routing layer has 
obvious benefits, but also introduces some obvious problems. For example,
if every terminal should have its own IP address, why shouldn't every file ?
Where should the line be drawn ? 

								Bruce Mann

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 18:01:52 GMT
From:      sharon@asylum.SF.CA.US (Sharon Fisher)
To:        comp.os.os2.misc,comp.protocols.tcp-ip
Subject:   LM/X

I'm working on a story for Unix World about LAN Manager/X, or LAN
Manager for Unix.  How many implementations of it are there?  Is
anybody actually using it?  I'd be interested in hearing from users or
vendors.  For now, I'd like to ask people to email me or post, rather
than call, because I don't have a firm assignment yet; I need to do a
little research and then do a proposal.  Thanks...

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 18:45:57 GMT
From:      nrd@redwood22.cray.com (Neal Dalton)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   Re: bootp daemon source wanted (TCP/IP)


In article <1991Jan10.114159.23536@resam.dk>, peter@resam.dk (Peter Pedersen) writes:
|> 
|> We are looking for the source to the server process "bootd" for booting
|> a diskless client using the bootp-protocol on a TCP/IP network.
|> The source should run on a UNIX system V preferable release 4 or 3.2, but other
|> version will also be appreciated.

This looks like what we would want for booting a sun off a YMS.

Neal  /\    /   _     /   \|||/                   Neal Dalton
     /  \  / _  _\   /   /     \                  Cray Research, inc
    /    \/_</_(_/\_/   (  o o  )                 655-F Lone Oak Dr.
                         \  ^  /                  Eagan, MN 55121
                          \ 0 /                 
Internet: nrd@cray.com     \_/                    Fax:   (612) 683-5599
    uucp: uunet!cray!nrd                          Phone: (612) 683-5607

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 18:47:16 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: When is a link saturated?

In article <1991Jan20.040130.18339@quick.com> srg@quick.com (Spencer Garrett) writes:
>-> I don't understand why the "remember the first exchange" is necessary. 
>-> Both telnet and rlogin use a reserved port number that appears in either
>-> the source or destination TCP port fields on *every* packet that is
>-> routed for the entire session.
>Alas, no.  A server is free to answer the connection request
>with a different port number, and they commonly do.

Either I misunderstand completely, or the above response is just plain
wrong.  If a server were to respond with a different port number, how would
the client's system tell which server sent the response?  The original
poster was correct.

Quick TCP lesson: When a client sends a TCP datagram to a server, the
source port is generally an arbitrary port chosen for that connection, and
the destination port is the server's well-known port.  Datagrams from the
server to that client will have the same port numbers, except the roles
will be reversed (the source port will be the well-known port, the
destination port will be the client's arbitrary source port).  This rule,
plus a similar rule for the IP addresses, is what permits a datagram to be
associated with a particular connection.  A connection is identified by the
4-tuple <local-address, local-port, foreign-address, foreign-port>, so all
datagrams in a connection must include the same four values (the sense of
"local" and "foreign" changes for each direction, though).

--
Barry Margolin, Thinking Machines Corp.

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

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 18:47:37 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP Urgent flag with TELNET DATA MARK


	From tcp-ip-RELAY@NIC.DDN.MIL Sun Jan 20 10:49:59 1991
	From: anthony@nms.hls.com (Anthony Chung)
	Subject: TCP Urgent flag with TELNET DATA MARK
	To: tcp-ip@nic.ddn.mil
	Date: Fri, 18 Jan 91 16:12:40 PDT
	X-Mailer: ELM [version 2.2 PL0]



	In Telnet Specs, DATA MARK should be sent with TCP URGENT flag set.
	I found SUN's implementation does not send TCP URGENT with TELNET DATA
	MARK all the times.  Is it required to send DATA MARK with TCP Urgent?

Anthony,

The original Telnet spec (RFC-874 is pretty clear that it is required.
In fact, use of the Data Mark is defined only when sent with as TCP
urgent data.  The Data Mark is defined as "The data stream portion of a
Synch" (RFC-874 p14), and "A Synch signal consists of a TCP Urgent
notification, coupled with the TELNET command DATA MARK" (ibid, p.
9).   The Host Requirements RFC-1123, section 3.2.4, is intended to
reinforce this requirement.

Bob Braden

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 19:46:58 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: sources of info on SNMP

In article <20012@hydra.gatech.EDU> ken@dali.cc.gatech.edu (Ken Seefried iii) writes:
>Where else might be an appropriate place to discuss SNMP?

There's a mailing list, snmp@nisc.psi.net.  Send mail to
snmp-request@nisc.psi.net to be added.
--
Barry Margolin, Thinking Machines Corp.

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

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 19:52:00 GMT
From:      rinehart@aedc-vax.af.mil ("Kathy Rinehart c60191 x3899")
To:        comp.protocols.tcp-ip
Subject:   CMU SNMP and/or opinions

Greetings to all, 

	I am looking for a public domain SNMP package. I understand 
Carnegie-Mellon has written a package, but I am not sure how or where to look 
for it.  If there are any other public domain packages available, I am not 
aware of them.  

	(1)   Are there any others available?

	(2)   Where would I find CMU SNMP, or any others?  Could I do an 
	      anonymous FTP and get them, or is some other method required?

	(3)   Are there any phone numbers of developers, administrators, etc. 
	      who may be familiar with this package?  Are there periodic 
	      updates?  [Basically, I am asking if this package resembles 
	      NCSA Telnet in any manner regarding telephone support, and if so 
	      how?}

	(4)   Does anyone have any opinions they would like to share, caveats 
	      to pass on, etc.?

	
	Thank you in advance for any opinions/advice/pointers you can provide.


							Kathy Rinehart
							Rinehart@AEDC-VAX.AF.MIL

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 20:05:59 GMT
From:      wayne@ultra.com (Wayne Hathaway)
To:        comp.protocols.tcp-ip
Subject:   Question on TCP use of IP TOS

Can some expert out there please explain the relationship between IP
type of service (TOS) and TCP connection establishment?  In particular,

1) Host A does a LISTEN() without specifying an IP TOS.  Host B does a
   CONNECT(TOS=THROUGHPUT).  When host A sends segments to host B over
   this connection, what TOS should it use? 

2) Host A does a LISTEN(TOS=DELAY).  Host B does the same
   CONNECT(TOS=THROUGHPUT).  When host A sends segments to host B over
   this connection, what TOS should it use? 

Another way of asking this is "Is TOS somehow negotiated during
connection establishment, or does each end use what it wants
independent of the other?"

Finally, for data transfer it would seem best for the end sending the
data to say TOS=THROUGHPUT and the end sending the ACKs to say
TOS=DELAY; is this typically done?

Thanx much.

    Wayne Hathaway               domain: wayne@Ultra.COM
    Ultra Network Technologies     uucp: ...!ames!ultra!wayne
    101 Daggett Drive             phone: 408-922-0100 x132
    San Jose, CA 95134           direct: Hey, you!

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 20:32:05 GMT
From:      scoggin@delmarva.UUCP (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   SNMP Books

The Simple Book by Dr. Marshall T. Rose is by far the best publication on the
topic of SNMP.  It is published by Prentice-Hall, ISBN 0-13-812611-9.  Dr Rose
is well known as an implementor in both Internet and OSI circles and is an
accomplished author.

By the way, if you are in the market for a readable OSI book (which won't
tell you how great it's GOING to be), by all means read his book entitled
The Open Book.

----------------------------------------------------------------------
John K. Scoggin, Jr.	
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		Fax:	(302) 451-5321
500 N. Wakefield Drive			Email:	uunet!delmarva!scoggin
Newark, DE  19714	                        delmarva!scoggin@uunet.UU.NET
"Never underestimate the bandwidth of a station wagon load of magnetic
 tapes screaming down the interstate!"			

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 21:19:27 GMT
From:      wright@hsi86.hsi.com (Gary Wright)
To:        comp.windows.x,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   X and RPC libraries: Can they co-exist?


Has anyone tried to integrate RPC mechanisms within the X toolkit
event loop programming model?  I am looking specifically for anyone who
has experience with Sun's ONC system or Apollo/HP/OSF's NCS RPC mechanisms
with any X toolkit.  It doesn't seem to me to be a straight forward problem
since both types of libraries (X & RPC) make certain assumptions about blocking
on sockets reads and neither was designed with the other in mind.

Thanks in advance for any pointers.
-- 
Gary Wright                                                 ...!uunet!hsi!wright
3M Health Information Systems					  wright@hsi.com

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 21:20:24 GMT
From:      raj@hpindwa.cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: rfi: VMS TCP/IP products

Since corrections were solicited ;-)

>HP's NS/VAX is not recommended for TCP/IP networking requirements.  
>It provided NS and telnet between VMS and HP using an HP proprietary 
>networking protocol (not TCP/IP).

This is incorrect - TCP/IP *IS* the protocol used by NS/VAX and NS
anything else HP. What *is* nonstandard about it is its use of the
Probe protocol for NAME->IP and IP->LAN address resolution. At the
time of its introduction, Probe was the only thing going on HP3000s.
The other point of non-standardness is it's use (to the 3K's at least)
of what is sometimes refered to as 802.HP encapsulation for IP
packets. NS pre-dates the birth of SNAP, and uses the IEEE assigned
802.2 sap for IP (it also is really early in the development of ARP,
hence the use of Probe...). The rest of the world went with SNAP, so
our use of a 'standard' standard became percieved as being
non-standard ;-)

more after the signature for those interested...
rick jones
___   _  ___
|__) /_\  |    Richard Anders Jones   | MPE/XL Networking Engineer
| \_/   \_/    Hewlett-Packard  Co.   | But is IS TCP/IP - Honest! ;-)
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply


$further developments

Since MPE/V V-Delta5, and MPE/XL Release 2.2, the 3000s have supported
Ethernet encapsulation in addition to 802.3/HP. ARP has also been
added. 

One other common misconception is that 3000s cannot communicate with
the rest of the world because the interface to TCP is NetIPC. They
forget the meaning of the word "interface" and assume it is the same
as "protocol." There is no reason why a NetIPC application cannot
communicate with a BSD Sockets application. I know of at *least* two
examples of this. The first is FTP/XL (shipped for Release 2.2 and
later). The second I cannot mention here but it is along similiar
lines.

$ return to normal programming

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 21:24:25 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject:   Xircom has worst performance in PC Magazine tests

The Xircom Pocket LAN Adapter had the worst performance of three pocket
lan adapters in a PC Magazine review, published in the February 12, 1991
issue.

	Adapter		mbps
	p.LAN		1.1
	D-Link		1.07
	Xircom		0.95

Please don't buy Xircom products.  They used some of my software in
violation of its copyright.  Write for details...

--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  FAX 315-268-7600
It's better to get mugged than to live a life of fear -- Freeman Dyson
I joined the League for Programming Freedom, and I hope you'll join too.

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 21:32:56 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: Want 8-bit/256 character clean TELNET session -- is it possible?

| From: prc@erbe.se (Robert Claeson)
| 
| The "-r" flag to the Annex telnet command will open a raw TCP connection
| without the telnet protocol.

  Someone else pointed that out to me in a private response.  I had seen
the switch and had initially thought ``yes!'' But was discouraged almost
immediately when I saw all the stuff about local line editing, etc. and
realized that the connection was anything but raw.  Fortunately the
person who pointed out the Annex raw ``telnet'' mode told me that I
needed to do:

	stty -break -lbreak		# allow BREAKs to be passed through
	stty iflow none oflow none	# disable XON/XOFF processing
	stty attn undef			# disable "attention" character
	telnet -r host port		# ``TELNET'' ``raw'' to port@host
	^]toggle crmod			# turn off CRLF mapping
	^]mode remote_echo		# turn off local echoing
	^]set escape undef		# turn off escape processing

Whew!  As I mentioned in a response to him (and Xylogics), I felt that
"-r" should be renamed "-l" for local line editing, etc., and that a new
"-r" should be developed (or better yet just add a command called "tcp"
since this really has absolutely nothing to do with the TELNET protocol)
that did much of the above seven lines.  (Although I don't think I would
have my proposed "tcp" command automatically disable BREAK processing
since there's really nothing I can think of to map BREAKs to in a raw TCP
connection and it would be nice to have *some* method of breaking the
connection and returning to the Annex CLI (Command Line Interpreter.)
I'm also hesitant to have it do anything about flow control, but I can
see strong arguments for disabling in-band flow control.)

  I guess I just don't see the problem with having terminal servers offer
a command like my proposed "tcp" command above.  It's certainly within
the domain of a terminal server's function in life (offering EIA-232 /
network interconnectivity.)

  As far as Bill Westfield's proposal for a DONT_TELNET TELNET option, I
think I have to agree that it's too much of a kludge.  TELNET was and is
designed for *terminal* interactions with translations going on to
convert different systems' CRLF models, etc.  I think it makes much more
sense to simply offer a TCP interconnect command in terminal servers and
other systems needing it.  *BUT*, if such an option is proposed, I hope
that it recommends that any TELNET client implementing such an option
should strive to the best of it's ability to be fully 8-bit / 256
character transparent.  I.e. local client escape processing, in-band flow
control and other in-band signals should all be disabled, etc.  Otherwise
we'll have a bunch of different TELNET clients which offer varying
implementations of DONT_TELNET ``cleanliness'' and no one will ever have
confidence that such a connection can truly be trusted.

Casey

Casey

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 21:57:16 GMT
From:      george@na.excelan.com (George Powers)
To:        comp.protocols.tcp-ip
Subject:   Re: select() call weirdness

In article <9101171257.AA13517@fiamass.ie> fiamass@fiamass.ie (fiamass) writes:
>
>We are having a problem with the select() system call on a Sun Sparc 4/65
>running SunOS 4.1.  We have a non blocking socket which we use to issue 
>a connect().  This call returns EINPROGRESS as per the documentation.  The 
>documentation states that under these circumstatances a select() call for 
>write on that socket can be done to determine when the socket is fully
>connected. Now here is our problem, we make a select() call which 
>always seems to return telling me 
>that the socket is now connected. So on I go and issue a write() which
>causes the program to bomb out!  It is as if the write call does not return.
>Here us the code. Has anyone any ideas?

This question deals in an aspect of socket programming that seems
to be frequently misunderstood, so I am posting my response:

I am not sure exactly why your program fails, but your code does
not conform to standard practice in using select.

One problem is that you assume that select completion means that the
socket is in the next expected state.  Owing to the nature of select's
implementation, you must treat it as meaning that the socket might be
in the expected state, but then again it might not be.  It may have
suffered an error, or it may just be a false alarm.  You should retry
the connect operation after each select returns until connect returns
errno==EISCONN.  Then try the write operation.

Also, your select specifies a zero wait time, which means that in this
example the connection is probably not established when you try the
write.  You should probably wait indefinitely.

These remarks pertain to operations besides connect.  When you select
for writing, you should be prepared for write to return EWOULDBLOCK,
or to write only part of the amount requested.  You may not observe
these things in practice, but they can happen on some systems in
certain circumstances, without violating the operations as documented.

--
UUCP: {ames,sun,apple,mtxinu,cae780,sco}!novell!george  George Powers
Internet: george@novell.com 
--

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 23:05:20 GMT
From:      david@twg.com (David S. Herron)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS for Mac...

In article <D751258AF9DF80094B@vaxsar.bitnet> BIWINE@VAXSAR.VASSAR.EDU (Bill Wine) writes:
>>Hello, all:   Does anybody knows of a program to access NFS servers from
>>              a Mac. PDD/Shareware if possible... I have been looking all
>>              FTP sites, and the only thing i have found are NNTP readers..
>I am not aware of a program that does this, but the GatorBox from Cayman
>lets a Mac access NFS servers as if they were Appleshare volumes.
>
>Bill Wine
>biwine@vassar.edu

TWG has NFS client software for Mac's.  Led to an interesting conversation
when the guy who'd been doing it proudly told me he had file systems mounted
from two different remote systems, and I was not impressed.  See, it was
(more-or-less) the "first time" that had been done on a MacIntosh while I
had been doing it for years on Unix machines ...  ;-)

Anyway.. MacPathway is the product.  Contact sales at (415) 962-7202.
-- 
<- David Herron, an MMDF & WIN/MHS guy, <david@twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu>
<-
<-	MS-DOS ... The ultimate computer virus.

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 23:30:00 GMT
From:      TAYBENGH@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   keeping the link, is it good?


Hi,
  Did anybody read the book "keeping the link"? It is a book that deal with
Ethernet installation and Management. Is it worth to buy? I knew there is a
review of this book in ConneXtion, however, I do not subscribe to it. Could
anybody gives some opinions about this book?
  Thanks a lot. Sorry for abusing the net, if I am.

- Beng Hang (email: taybengh@nusdiscs)

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 23:30:41 GMT
From:      ejm@ejmmips.NOC.Vitalink.COM (Erik J. Murrey)
To:        comp.protocols.tcp-ip
Subject:   Re: Redirects, and multiple subnets on a cable


In article <6490@munnari.oz.au>, kre@cs.mu.OZ.AU (Robert Elz) writes:
> 	In there you say (wrt two subnets on one cable) ...
> 
> 	   In fact, this is not such a bad solution,
> 	   because assuming that the gateway is capable of recognizing multiple
> 	   subnet numbers on the same subnet, the gateway will simply send the
> 	   host an ICMP Redirect [4], and subsequent packets will go directly to
> 	   the host [1].
> 
> 	I don't think that can be true can it?  That would require the ICMP
> 	redirect to contain an ethernet address.  The sending host is in no
> 	doubt of the destination's IP address, sending a redirect that contains
> 	that address can do no more than confuse it, if its routing table has
> 	it believe that to reach that address it must route through a gateway.
> 
> 	Oh - do you mean send the host a redirect, containing its own address
> 	as the gateway?  I guess that might work, assuming that the host's
> 	software understands the BSD type convention "if I am the gateway,
> 	I send directly out on my ethernet", if not, almost anything might
> 	happen.
> 
> 	If that's it, I think I'd be more explicit about it.
> 


Actually, using two subnets on a cable is very common when more than
one link-layer protocol is being used.  (i.e. Ethernet v2 and
802.3/SNAP)  In this case, an ICMP isn't even practical since we don't
have a way to specify link-layer information in an ICMP message.

In cases where the subnets share the same frame type, it is still
impractical to send ICMP's since the "offending" host will know
nothing about host specified in the ICMP redirect.  Most IP
implementations based on the 4.3Tahoe stack only allow one IP address
per interface.  Maybe the interface handling code could be extended to
support multiple addresses per protocol?

---
Erik J. Murrey
Vitalink Communications NOC
ejm@NOC.Vitalink.COM	...!uunet!NOC.Vitalink.COM!ejm

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 91 23:55:42 GMT
From:      ejm@ejmmips.NOC.Vitalink.COM (Erik J. Murrey)
To:        comp.protocols.tcp-ip
Subject:   Re: When is a link saturated?

In article <1991Jan21.141530.7031@ccs.carleton.ca>,
jstewart@ccs.carleton.ca (John Stewart) writes:
> In article <1991Jan20.040130.18339@quick.com> srg@quick.com (Spencer
 Garrett) writes:
> >-> I don't understand why the "remember the first exchange" is necessary. 
> >-> Both telnet and rlogin use a reserved port number that appears in either
> >-> the source or destination TCP port fields on *every* packet that is
> >-> routed for the entire session.
> >
> >Alas, no.  A server is free to answer the connection request
> >with a different port number, and they commonly do.  (The reason
> >for this eludes me.  It is permitted by the RFC's, but not
> >required or particularly encouraged.)
> 
> The main reason for doing so is to facilitate multiple sessions.  For example
> if 10 people telnet to a machine, each user will get their own telnetd 
> process communicating to them via a unique set of ports.  Now imagine how
> difficult this would be to do if you could only have one process running 
> connected to the well known telnet port.
> -- 

Wait a minute.  On most BSD implementations, "inetd" spawns a separate
rlogind or telnetd process for each incoming telnet or rlogin session
requested.  The processes share the same local port number (23 or 513)
since TCP/IP allows them to do so.  (The connection is still unique
based on (source ip address, source TCP port, dest ip address, dest TCP port)

I will quote from RFC 854 (telnet)
"  The TELNET TCP connection is established between the user's port U
   and the server's port L.  The server listens on its well known port L
   for such connections.  Since a TCP connection is full duplex and
   identified by the pair of ports, the server can engage in many
   simultaneous connections involving its port L and different user
   ports U.
"

A netstat -n on all of the machines I can access show port 23 or 513
as the host's local port for incoming or foreign port for outgoing
telnet/rlogin sessions.

This allows a router to look at the source/dest TCP port to determine
whether this is a rlogin or telnet session.

---
Erik J. Murrey
Vitalink Communications NOC
ejm@NOC.Vitalink.COM	...!uunet!NOC.Vitalink.COM!ejm

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 02:17:34 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: Want 8-bit/256 character clean TELNET session -- is it possible?

| From: casey@gauss.llnl.gov (Casey Leedom)
| 
| [To use Annex ``raw telnet'' mode]:
| 
| 	stty -break -lbreak		# allow BREAKs to be passed through
| 	stty iflow none oflow none	# disable XON/XOFF processing
| 	stty attn undef			# disable "attention" character
| 	telnet -r host port		# ``TELNET'' ``raw'' to port@host
| 	^]toggle crmod			# turn off CRLF mapping
| 	^]mode remote_echo		# turn off local echoing
| 	^]set escape undef		# turn off escape processing

  Opps!  I shouldn't have done that from memory.  It's really closer to:

	stty -break -lbreak		# allow BREAKs to be passed through
	stty iflow none oflow none	# disable XON/XOFF processing
	stty attn undef			# disable "attention" character
	telnet -r host port		# ``TELNET'' ``raw'' to port@host
	^]toggle crlf			# turn off CRLF mapping
	^]mode character remote_echo	# turn off local echoing
	^]set escape U			# turn off escape processing

Further, I should note that this assumes that the current escape
character, inherited from the tesc stty setting, is set to the default
``^].''

  Oh, one other note, doing ``stty iflow none oflow none'' is also wrong
because flow control may be set to eia which you don't want to turn off.

Casey

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 03:12:42 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Want 8-bit/256 character clean TELNET session -- is it possible?

If what you want is the ability to connect to an arbitrary remote host/port
and send binary data fast, why is Telnet in the picture at all?  Just use
the standard system API for TCP and blast away.  Telnet is intended for
virtual terminal support, and isn't designed for bulk data transfer.  If
the widget you're hacking doesn't have a TCP API, where are you getting the
data you want to send from in the first place?

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

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 03:21:56 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: TELNET versus LAT

In article <9101211758.AA24806@decpa.pa.dec.com> mann@star.enet.dec.com (Bruce Mann ZK1-3/J35 DTN 381-1298  21-Jan-1991 1257) writes:
>	To my knowledge, all useful protocols start out being proprietary,
>and evolve into "open" status as they become more widely used. LAT is
>certainly in this transition now.

The standard protocols in the TCP/IP suite have never, to my knowledge,
been proprietary.  Working up the protocol hierarchy, all of
IP-Ethernet-encapsulation, IP, TCP, and the application protocols TELNET,
FTP, SMTP, and SNMP were developed openly.  The BSD R-protocols were
developed privately by Berkeley, but the source has always been available,
and some of them have reasonable protocol descriptions in the manual
entries.  Similarly for X Windows and MIT/DEC.  Sun made the specification
of the NFS protocol available pretty soon after their workstations that use
it became popular.

LAT has been around for at least five years.  When will this "transition"
take place, i.e. when will DEC publish the protocol specification in the
open literature?

>	By the way, while I do agree all protocols can be routed (layer 3),
>I do not agree all protocols should be routed. The routing layer has 
>obvious benefits, but also introduces some obvious problems. For example,
>if every terminal should have its own IP address, why shouldn't every file ?
>Where should the line be drawn ? 

It's generally not necessary to include routing in a high-level protocol
when it normally uses a lower-level protocol that is already routed.

--
Barry Margolin, Thinking Machines Corp.

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

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 05:52:55 GMT
From:      gds@oahu.cs.ucla.edu (Greg Skinner)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   connecting Appleshare networks to the Internet and/or Bitnet

Please reply to the address in the "Reply-To" field, not me.  Thanks.

  Do you know anything about connecting into the bitnet/internet system?  If
someone in the music department wanted to do this with a macintosh, how would
he go about it.  Also, Is there software support for that sort of thing?

  What I'm trying to figure out is whether or not a Appleshare network, using
a mail program within iself (MSmail?) would be able to attach itself to the
net for message exchange with other schools.  Also, if any specific software
would be needed (such as a specific mail server other than MSmail).

                          -jim

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 09:45:04 GMT
From:      mni@techops.cray.com (Michael Nittmann)
To:        comp.protocols.tcp-ip
Subject:   Re: When is a link saturated?

... and the multiple ports, not only reserved well known ports,
show, how the tcp layer does the session management.
If you look at it this way , that tcp not only
provides for the transport service but also the 
session management, then this port arithmetic 
should be somewhat more understandable.

michael
.

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 11:10:16 GMT
From:      sjaak@cca.vu.nl (Jacques Schuurman)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP Network Management

scoggin@delmarva.UUCP (John Scoggin) writes:

| The BEST book on the subject is The Simple Book by Marshall T. Rose (1990).
| Marshall Rose is one of the heavy duty implementers in both the TCP/IP and 
| OSI worlds.  Not only that, but he can write!  (An unusual combination)

Fully agreed.  To add a bit of info:  The Simple Book has been published by
Prentice Hall, ISBN 0-13-812611-9

sjaak

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 13:51:21 GMT
From:      BDK@unb.CA
To:        comp.protocols.tcp-ip
Subject:   Re: LM/X

Please post to the list. There are many of us interested.


On  Mon, 21 Jan 91 18:01:52 GMT  Sharon Fisher <asylum!sharon@DECWRL.
DEC.COM> writes:

> I'm working on a story for Unix World about LAN Manager/X, or LAN
> Manager for Unix.  How many implementations of it are there?  Is
> anybody actually using it?  I'd be interested in hearing from users or
> vendors.  For now, I'd like to ask people to email me or post, rather
> than call, because I don't have a firm assignment yet; I need to do a
> little research and then do a proposal.  Thanks...

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 14:18:09 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: When is a link saturated?


    >Alas, no.  A server is free to answer the connection request
    >with a different port number, and they commonly do.  (The reason
    >for this eludes me.  It is permitted by the RFC's, but not
    >required or particularly encouraged.)
    
    The main reason for doing so is to facilitate multiple sessions.  For
    example if 10 people telnet to a machine, each user will get their own
    telnetd process communicating to them via a unique set of ports.  Now
    imagine how difficult this would be to do if you could only have one
    process running connected to the well known telnet port.

I'm sorry, you're both badly misinformed.  All Telnet connections share
a common well-known port number (23) on the server for the life of the
connection (Rlogin servers do the same with port 513).  The uniqueness
of the individual connections is based on the remote host IP address and
remote TCP port values, and the TCP API has to allow multiple processes
on a single local port number.  The client's originating port is usually
randomly assigned a unique value by the client's TCP, so that it can
tell its various connections apart as well.

You may have gotten Telnet (RFC 854, over TCP) confused with TFTP (RFC
783? over UDP), which does have server-side port-switching as part of
the connection startup.

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

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 14:55:19 GMT
From:      mni@techops.cray.com (Michael Nittmann)
To:        comp.protocols.tcp-ip
Subject:   Interoperability Query

Hallo,

question: does anybody have experiences with the following
TCP/IP side of product:

	Interactive UNIX	for 368 PCs (and 468),
by Danet?

I promise to summarize to the net. 

Thanks in advance

michael

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 15:28:26 GMT
From:      morrison@thucydides.cs.uiuc.edu (Vance Morrison)
To:        comp.dcom.lans,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   PCbridge 1.2 beta testers needed


			      Call for Beta-Testers for PCBridge

I have just completed the next version (1.2) of PCBridge and now need
beta testers to help exercise the new features.

For those who don't know PCbridge is a simple but very useful piece of
software that can convert a IBM-PC with networking cards into an ethernet
bridge.  Thus it is possible to assemble for under $1000 a bridge that
has better performance than commercial bridges costing $2000 or more.

For those of you that are familiar with PCbridge here is a list of
new features.

	Support for the WD8003EBT, WD8013EBT Ethernet cards
	Support for the WD8003S, WD8013SH Starlan cards 
	The ability to do remote bridging via asynchronous serial lines
		at baud rates up to 57.6K baud.
	Support for three or 4 (or even higher!) way bridges.

The support for the WD8013EBT card is significant because it can double
throughput of the bridge (since it has a 16 bit data path), and its larger
buffers will insure that large, fast spurts of data (the kind file servers
tend to generate), will not be lost.  

The beta-test software is available on accuvax.nwu.edu (129.105.49.1)
in the directory pub/pcroute/bridge.  The files are called
pcbridge1.2b.tar.Z and pcbridge1.2b.src.tar.Z and are compressed TAR
archives.  

If you are going to beta-test this software please let me know.  Also
I am interested in any feedback on the software as well as the documentation.
So don't be shy.  Please send your feedback to morrison@accuvax.nwu.edu.

I have tested the software some myself, but unfortunately I only have 
WD8003E cards, so I really need people to test this code on the WD8003EBT
and WD8013EBT cards.  Because this code has never been tried before with
these cards, if it fails let me know IMMEDIATELY.  I have a simple testing
plan that should quickly pinpoint the problem and we can get any problem
you have fixed.

The remote bridge I have tested quite a bit myself, but I have not tested
it for long periods of time so anyone who can do some day or week long
testing could tell me valuable information.

I wanted to add support for a 56K synchronous board, but I have neither
the hardware or the information needed to write the code.  If anyone
out there wants this capability badly enough to invest a small amount
of hardware/money I could probably write it in about 2 weeks.

Those of you who also know/use PCroute, rest assured, your turn will come.
The beta version of PCroute 2.2 should be out very soon.  I basically just
need to write up/modify the documentation for the new version.

Vance Morrison

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 17:05:27 GMT
From:      rlstewart@eng.xyplex.com (Bob Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: TELNET versus LAT

> >But could a protocol be designed that had the advantages of LAT
> >(multiple streams in one packet, rate limiting, etc.) that ran over a
> >network protocol (such as DECnet routing without NSP), or had adaptive
> >timeouts?  
> 
> 	Yes. The LAT protocol encompases a number of features, but the
> session aggregation feature is independent of the LAT being built
> directly on the datalink layer of Ethernet. 

To run LAT over a typical routing layer breaks two of LATs implicit
assumptions:  the consistent timing and low message loss of a LAN.  LAT was
carefully designed to take significant advantage of fast LAN characteristics.
Specifically, it transmits data based on a collection timer, driven by the
connection initiator (terminal server), and expecting a quick, reliable reply
from the other end.  Although lost or slow messages will not cause LAT to
operate incorrectly, they will cause it to operate inefficiently.  The typical
example of such problems is LAT running over a remote bridge, which introduces
the propagation delay, and maybe the variable timing and loss, of a network
layer.

LAT is a good protocol within its design constraints.  When you change those
constraints, you end up with something little different from Telnet over
TCP.  You can optimize the number of messages in the latter case, by using
holddown timers, for example.  Or in the case of a proprietary protocol I
know, holding down level 4 messages a bit and concatenating them at level 3 if
they have the same destination.  Such approaches pick up some LAT efficiencies,
but you can't optimize away the inherant weaknesses of the underlying layers.

	Bob

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 17:18:42 GMT
From:      HAROLD@UGA.CC.UGA.EDU (Harold Pritchett)
To:        comp.protocols.tcp-ip
Subject:   Re: What service broadcasts on UDP port 60000?

>< we're trying to figure out what service is broadcasting on
>< UDP port 60000.  It's coming from an SCO Xenix engine
>< with Lachman TCP/IP.
>
>It looks like they are trying to verify the uniqueness of their serial number.
>
>Nothing you can do about it, I'm afraid...

There is always something you can do about it.  Send the software back and
refuse to ever do business with a company which resorts to this sort of
crap.  And be sure to let them know how you feel about this.

Harold

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 17:34:16 GMT
From:      rlg@STYX.DESKTALK.COM (Richard L. Gralnik)
To:        comp.protocols.tcp-ip
Subject:   An INTERESTING problem

Hi folks,

My thanks to everyone who responded to my request for comments on how to r
configure the IP addresses for a network consisting of a lot of subnets 
connected by routers over serial lines.  There were over 20 replies, most 
agreeing on unnumbered subnets as the way to go, although a few of you did
mention variable length subnet masks and OSPF routing updates as a more
sophisticated and just as workable approach.  I appreciate the live experience
a couple of you shared on attempts to implement the Class B offices linked
by subnetted Class C serial lines.  You justified our suspicions that 'here
there are monsters'.

I would have replied sooner, but my son was in the hospital unexpectedly for
a week with meningitis (he's ok now) so I was a bit back-logged.

Thanks again,
Richard Gralnik
(rlg@desktalk.com)

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 17:51:05 GMT
From:      dab@BERSERKLY.CRAY.COM (David Borman)
To:        comp.protocols.tcp-ip
Subject:   Re: Question on TCP use of IP TOS

Wayne Hathaway writes:

> Can some expert out there please explain the relationship between IP
> type of service (TOS) and TCP connection establishment?  In particular,
> 
> 1) Host A does a LISTEN() without specifying an IP TOS.  Host B does a
>    CONNECT(TOS=THROUGHPUT).  When host A sends segments to host B over
>    this connection, what TOS should it use? 
> 
> 2) Host A does a LISTEN(TOS=DELAY).  Host B does the same
>    CONNECT(TOS=THROUGHPUT).  When host A sends segments to host B over
>    this connection, what TOS should it use? 
> 
> Another way of asking this is "Is TOS somehow negotiated during
> connection establishment, or does each end use what it wants
> independent of the other?"

From RFC 1122, pg 107, 4.2.4.2:

	The TOS will be specified independently in each direction on
	the connection, so that the receiver application will
	specifify the TOS used ro ACK segments.

My implementation of TOS follows this statement. Each side of the connection
sets the TOS bits to what it wants; there is no automatic setting of
the TOS bits in the listener based on the TOS bits of the received
connect packet.

So, for #1, Host A sends packets with TOS=0.  For #2, host A sends
packets with TOS=DELAY.

> Finally, for data transfer it would seem best for the end sending the
> data to say TOS=THROUGHPUT and the end sending the ACKs to say
> TOS=DELAY; is this typically done?

My implementation does not do that.  For things like telnet & ftp,
both sides use the same TOS value for the connection.

Note that the area of TOS is one that is not clearly defined yet.
The Host Requirements group decided to start making hosts set the
TOS bits, to break the chicken and egg problem (you need both the
hosts and the routers involved for it to do anything).  The thing
to do now is start implementing and experimenting with it, and as
we gain experience with it, we can make new recommendations.

			-David Borman, dab@cray.com

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 18:37:08 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Want 8-bit/256 character clean TELNET session -- is it possible?

In article <89861@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey Leedom) writes:
>  I guess I just don't see the problem with having terminal servers offer
>a command like my proposed "tcp" command above.  It's certainly within
>the domain of a terminal server's function in life (offering EIA-232 /
>network interconnectivity.)

The CMC TranServer offers this feature. On the TranServer, there are
3 different commands to open sessions:

	TELNET host [session-name] [port]
	RLOGIN host [session-name] [port] ["as" user]
	OPEN   host port

The OPEN command is what you are asking for.

-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 19:10:59 GMT
From:      srg@quick.com (Spencer Garrett)
To:        comp.protocols.tcp-ip
Subject:   Re: When is a link saturated?

Someone else wrote:
-> >-> I don't understand why the "remember the first exchange" is necessary. 
-> >-> Both telnet and rlogin use a reserved port number that appears in either
-> >-> the source or destination TCP port fields on *every* packet that is
-> >-> routed for the entire session.
-> >
-> In article <1991Jan20.040130.18339@quick.com> I wrote:
-> >Alas, no.  A server is free to answer the connection request
-> >with a different port number, and they commonly do.  (The reason
-> >for this eludes me.  It is permitted by the RFC's, but not
-> >required or particularly encouraged.)
-> 
In article <1991Jan21.141530.7031@ccs.carleton.ca>,
	jstewart@ccs.carleton.ca (John Stewart) writes:
-> The main reason for doing so is to facilitate multiple sessions.  For example
-> if 10 people telnet to a machine, each user will get their own telnetd 
-> process communicating to them via a unique set of ports.  Now imagine how
-> difficult this would be to do if you could only have one process running 
-> connected to the well known telnet port.

Not so.  A "connection" is identified by both source and destination
addresses *and port numbers*, so as long as the originator of each
session grabs a unique port number all is well.  My own networking
code does not shift away from the original well-known-port, and
multiple sessions work just fine.  I think the reason BSD does shift
port numbers may have something to do with the notion of "priviledged
port numbers" being those less than some small fixed number (1024
as I recall).  They may have thought it would be easier to implement
some security features if neither end of a regular session used
a small port number.

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 19:13:57 GMT
From:      raj@hpindwa.cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Redirects, and multiple subnets on a cable


Instead of relying on redirects, why not use proxy-ARP? It would
probably be more robust in the face of various implementations. 

If those hosts that can use it, and the router routes for those who
can't, then all should be well. Or have I missed something?

rick jones
___   _  ___
|__) /_\  |    Richard Anders Jones   | This space undergoing
| \_/   \_/    Hewlett-Packard  Co.   | renovations - results soon ;-)
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 20:41:04 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Want 8-bit/256 character clean TELNET session -- is it possible?


    [Annex raw ``telnet'' mode requires:]

	stty -break -lbreak		# allow BREAKs to be passed through
	stty iflow none oflow none	# disable XON/XOFF processing
	stty attn undef			# disable "attention" character
	telnet -r host port		# ``TELNET'' ``raw'' to port@host
	^]toggle crmod			# turn off CRLF mapping
	^]mode remote_echo		# turn off local echoing
	^]set escape undef		# turn off escape processing


Whew!  A shining example of the superiority of a unix-compatible user
interface! :-)


    As far as Bill Westfield's proposal for a DONT_TELNET TELNET option, I
    think I have to agree that it's too much of a kludge.  TELNET was and is
    designed for *terminal* interactions with translations going on to
    convert different systems' CRLF models, etc.

Yes.  The point was that many hosts set all that up, perhaps completely
transparently, and then never do any further negotiation anyway.  These
systems would gain some efficiency in both the host and the terminal server.
In particular, I claimed that it would be much more likely to have kernal
based implementations if all they had tyo do was copy data back and forth.


    If such an option is proposed, I hope that it recommends that any
    TELNET client implementing such an option should strive to the best of
    it's ability to be fully 8-bit / 256 character transparent.  I.e.
    local client escape processing, in-band flow control and other in-band
    signals should all be disabled, etc.

Unfortunately, this brings up an interesting point - the user interface
connected to a protocol and the protocol itself should be divorced from one
another.  The ARPANet TACs used to turn off the escape characters when binary
mode was negotiated.  This prevented users from issuing all sorts of commands,
and they were not happy.  Doing this with "dont telnet" would be even more
dangerous - while a system can negotiate to turn binary mode off, once you
negotiate "don't telnet", it can never be turned on again...

Bill Westfield
cisco Systems.

-------

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 21:12:06 GMT
From:      Will@cup.portal.com (Will E Estes)
To:        comp.protocols.ibm,comp.protocols.tcp-ip,comp.sys.pyramid
Subject:   Want Opinions Of Mainframe Versus UNIX For Client-Server Applic

I would like some opinions and/or test results that would
give me a basis for comparing performance of a client server
application under one of two configurations.  In both
configurations the client side is a 386 PC running MS-DOS
and connecting to the host using a 2400 bps modem.

Configuration One:  Server is an IBM mainframe running
VM/CMS accessed through a protocol converter or,
alternately, accessed through a TCP/IP Ethernet and router
that supports asynchronous TCP/IP access.

Configuration Two:  Server is a multi-processor UNIX machine
(e.g., a Sequent S81 with 20 386 processors) accessed
through direct modem connections or, alternately, accessed
through a TCP/IP Ethernet and router that supports
asynchronous TCP/IP access.

The application is similar in concept to CompuServe's
Informatino Manager (CIM) or Connect Inc.'s Connect
software:  the user interface is on the PC and E-mail,
conferencing, and database engines are on the host side.
The protocol used to exchange messages between client-server
may be built from scratch (in the case of using protocol
converters or direct-connect modems) or based on something
standard like TCP (in the case of an Ethernet attachment to
the host).

I have been told that the application's performance is
likely to be poor under Configuration One if we use the
protocol converter, but no one has been able to quantify the
response time difference.  Does anyone have any opinions
regarding the four options?  (i.e., 1) IBM host w/protocol
converter, 2) IBM host w/Ethernet connection and asynch TCP
router, 3) UNIX host with direct modem connections, 4) UNIX
host w/Ethernet connection and asynch TCP router)

I'm also interested in anyone's thoughts on how asynch
TCP/IP (e.g., SLIP or PPP) is likely to perform over on a
2400 bps line in both configurations, and are there
preferred alternatives?

Thanks,
Will Estes             (apple!cup.portal.com!Will)

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 21:13:18 GMT
From:      barns@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re: Question on TCP use of IP TOS

Perhaps I can call myself at least a quasi-expert?  Well, nothing
says TOS is negotiated, except for the precedence, for which a
negotiation is clearly described in the protocol spec.  I think
one can reasonably infer that each end does what it wants with
the delay/throughput/reliability bits without regard to the other end.

You probably already know that Host Requirements (RFCs 1122/1123)
says to use TOS in accordance with recommendations in Assigned
Numbers.  If both ends did this, there should at least not be
randomness, and under current recommendations, I believe there
is no asymmetry.  However, setting low delay on naked ACKs was
discussed, and John Lekashman said it was a good thing and made
performance better for his (NASA?) situation.  The case in question
was a high-bandwidth satellite path and a low-bandwidth terrestrial
path.  RTT was a bottleneck and finagling the TOS in this way
allowed more data into the satellite pipe.  Or something like that.
I'd call it legal, possibly a desirable thing, but not common
practice in vanilla software as far as I know.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 21:55:15 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Question on TCP use of IP TOS


    Another way of asking this is "Is TOS somehow negotiated during
    connection establishment, or does each end use what it wants
    independent of the other?"
    
Current practice is to assign a TOS value to a given upper-layer protocol,
and use it for all packets (ack or data) related to that connection.  Thus,
there isn't really any negotiation.  One problem with using different TOS
values for two sides of a connection, or for acks vs. data, is that it
greatly increases the chance of asymmetric routing, which might affect RTT
estimation or even reachability.

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

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 22:45:50 GMT
From:      scoggin@delmarva.UUCP (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   ISI W-Notes

Does anyone know where (or if) I could obtain a copy (via email or snail-mail)
of USC/ISI W-note 28 by E. Cole entitled "PVP - A Packet Video Protocol"?  I
am also trying to track down the source for The Secure Data Network System
working group's documents.

Thanks in advance....

----------------------------------------------------------------------
John K. Scoggin, Jr.	
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		Fax:	(302) 451-5321
500 N. Wakefield Drive			Email:	uunet!delmarva!scoggin
Newark, DE  19714	                        delmarva!scoggin@uunet.UU.NET
"Never underestimate the bandwidth of a station wagon load of magnetic
 tapes screaming down the interstate!"			

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 22:55:35 GMT
From:      pte900@jatz.aarnet.edu.au (Peter Elford)
To:        comp.protocols.tcp-ip
Subject:   Re: CMU SNMP and/or opinions

In article <9101221513.AA00178@ucbvax.Berkeley.EDU>, rinehart@aedc-vax.af.mil ("Kathy Rinehart c60191 x3899") writes:
|> Greetings to all, 
|> 
|> 	I am looking for a public domain SNMP package. I understand 
|> Carnegie-Mellon has written a package, but I am not sure how or where to look 
|> for it.  If there are any other public domain packages available, I am not 
|> aware of them.  
|> 
|> 	(1)   Are there any others available?

MIT have done one as well.

|> 	(2)   Where would I find CMU SNMP, or any others?  Could I do an 
|> 	      anonymous FTP and get them, or is some other method required?

anonymous ftp to lancaster.andrew.cmu.edu. I can't check the file names,
directories, etc. because routing seems to have come a little unstuck in
the US at the moment (at least if you're coming from Australia!).

|> 	(3)   Are there any phone numbers of developers, administrators, etc. 
|> 	      who may be familiar with this package?  Are there periodic 
|> 	      updates?  [Basically, I am asking if this package resembles 
|> 	      NCSA Telnet in any manner regarding telephone support, and if so 
|> 	      how?}

They provide an e-mail address to which you can send queries, but like the
vast majority of public domain software packages, there is no telephone
support.

|> 	(4)   Does anyone have any opinions they would like to share, caveats 
|> 	      to pass on, etc.?

Well written code, lots of example (and useful) applications, widely used,
easy to write new applications of your own (ie. good/simple API), and it
can parse foreign MIBs.

Peter Elford,                           	e-mail: P.Elford@aarnet.edu.au
Network Co-ordinator,	 			phone: +61 6 249 3542
Australian Academic Research Network,		fax: +61 6 247 3425
c/o, Computer Services Centre,			post: PO Box 4
Australian National University			      Canberra 2601
Canberra, AUSTRALIA		

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 23:51:55 GMT
From:      karl@lvs.Eng.Sun.COM (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: TELNET versus LAT

In article <9101161700.AA19338@sonny.proteon.com> jas@proteon.com (John A. Shriver) writes:
>But could a protocol be designed that had the advantages of LAT
>(multiple streams in one packet, rate limiting, etc.) that ran over a
>network protocol (such as DECnet routing without NSP), or had adaptive
>timeouts?  I strongly suspect that the answer would be yes.

Yes, but -- DEC has a patent on LAT.  I suspect that some of their
lawyers may object to a new protocol that uses some of
dally-in-hope-of-more-data techniques embedded in LAT.

(Please don't flame me for DEC's patent.  Personally, I think that the
LAT idea wasn't novel at the time.  [For example, one of the reason
that municipal busses run on schedules is to get a full load of
passengers.  And the Nagle algorithms used in TCP/IP try to collect
reasonable payloads into packets before launching them into the
ether.]  But I'm not at the patent office.)

			--karl--

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 91 23:58:27 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: Want 8-bit/256 character clean TELNET session -- is it possible?

| From: jbvb@FTP.COM (James B. Van Bokkelen)
| 
| If what you want is the ability to connect to an arbitrary remote
| host/port and send binary data fast, why is Telnet in the picture at
| all?  Just use the standard system API for TCP and blast away.  Telnet is
| intended for virtual terminal support, and isn't designed for bulk data
| transfer.  If the widget you're hacking doesn't have a TCP API, where are
| you getting the data you want to send from in the first place?

  Because I'm dealing with a terminal server whose only connection
mechanisms are RLOGIN and TELNET (actually it also supports some
proprietary protocol but that's of no import.)

  I'm only trying to do it with telnet because that's what I've got.  My
feeling is that I fundamentally agree with you.  TELNET is for terminal
interaction.

| From: billw@mathom.cisco.com (William "Chops" Westfield)
| 
|     As far as Bill Westfield's proposal for a DONT_TELNET TELNET option, I
|     think I have to agree that it's too much of a kludge.  TELNET was and
|     is designed for *terminal* interactions with translations going on to
|     convert different systems' CRLF models, etc.
| 
| Yes.  The point was that many hosts set all that up, perhaps completely
| transparently, and then never do any further negotiation anyway.  These
| systems would gain some efficiency in both the host and the terminal
| server.  In particular, I claimed that it would be much more likely to
| have kernal based implementations if all they had to do was copy data
| back and forth.

  I don't think there's enough logic in the TELNET server side to really
provide much of an impediment to kernel implementation.  All it's got to
be able to do is acknowledge option processing and change it's behavior
in minor ways.

|     If such an option is proposed, I hope that it recommends
|     that any TELNET client implementing such an option should strive to
|     the best of it's ability to be fully 8-bit / 256 character
|     transparent.  I.e.  local client escape processing, in-band flow
|     control and other in-band signals should all be disabled, etc.
| 
| Unfortunately, this brings up an interesting point - the user interface
| connected to a protocol and the protocol itself should be divorced from
| one another.  The ARPANet TACs used to turn off the escape characters when
| binary mode was negotiated.  This prevented users from issuing all sorts
| of commands, and they were not happy.  Doing this with "dont telnet"
| would be even more dangerous - while a system can negotiate to turn
| binary mode off, once you negotiate "don't telnet", it can never be
| turned on again...

  But without such a recommendation the DONT_TELNET proposed option is
going to be useless for my purposes.  Yes, I know that I could have users
explicitly unset all the client interface garbage, but I'd spend the rest
my life explaining it over, and over, and over, ...  At the very least,
let's have a *REAL* BINARY mode that specifies that the channel should be
as clear as possible, including in-band client command escapes.

  In any case, I'm now convinced that TELNET is the wrong way to do what
I'm trying to do which is simply establish a clear TCP connection between
the Annex and a remote, non-TELNET server.  It appears that I may be able
to kludge the Annex's TELNET into letting me do it, but it's not going to
be pleasant.

  I will lobby Xylogics to support a new command to implement this.
Maybe if Xylogics implements this and the CMC TranServer already has it
(see Lars Poulsen's note), other terminal server manufacturers will
implement the same functionality and it'll become common.

Casey

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 91 01:09:42 GMT
From:      chris@Solbourne.COM (Chris Horne)
To:        comp.protocols.tcp-ip
Subject:   tcp bug causing poor "rcp" performance with SunOS 4.1

A customer of ours noticed something curious with rcp (tcp) performance
using OS/MP4.1, our derivative of SunOS 4.1.  He was monitoring the ethernet
with a sniffer. If the same rcp was repeated twice in a row (quickly) he 
noticed that the first rcp used large packets, and subsequent ones used small
packets.  

We were able to reproduce the problem between two sun machines running 
SunOS 4.1.

We have traced the problem down to the way the kernel routine 
netinet/tcp_input.c<tcp_input> deals with "options" when a new connection 
request is received in TCPS_TIME_WAIT state. What happens is that the 
"options" get applied to the old connection and freed, the need for a new 
connection is recognized, the old connection is closed, the new connection 
is established but the options have been freed and don't get applied.  
As a result we end up using the default t_maxseg that was assigned in 
tcp_newtcpcb (512).  For those of you with SunOS source (or BSD 4.3 
source) look at the handling of the variable "om" in tcp_input, with 
particular attention to what happens when "goto findpcb" occurs when the
packet had options (to set maxseg).

My inclination is to resolve this by:
	o	removing the "om = 0" after all calls to tcp_dooptions.
	o	removing the "(void) m_free(om);" from tcp_dooptions
		to leave the mbuf containing the options around for further
		processing.
	and	making sure that all returns from tcp_input have 
		a "if (om) m_free(om);".

I am not a tcp guru... 

Is this a well understood problem?  Is the problem really on the input side? 
Is there another patch that is available?

Thank you very much for your support..

-- 
| Christopher Horne,	MTS OS Group
| UUNET: chris@Solbourne.COM
| DDD: 	(303)678-4320 or (303)772-3400 x320
| FAX:	(303)678-4716
| USPS: Solbourne Computer, Inc., 1900 Pike Rd, Longmont Co, 80501



-- 
-- 
| Christopher Horne,	MTS OS Group
| UUNET: chris@Solbourne.COM
| DDD: 	(303)678-4320 or (303)772-3400 x320

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 91 01:54:56 GMT
From:      rauscher@remus.rutgers.edu (Rich Rauscher)
To:        comp.sys.mac.comm,comp.sys.mac.wanted,comp.protocols.tcp-ip,comp.protocols.appletalk
Subject:   SLIP on MacTCP


Does anybody out there know if there exists or will exist a version
of MacTCP that will run over a SLIP connection? Excuse me if this
has already been covered, as I do not read all of these news groups
that often.    
Thanks,
-Rich
-- 
-------------
rauscher@rutgers.edu                RPO 5997 PO 5063, New Brunswick, NJ 08903
rauscher@PISCES                          Shakespeare learns Discrete Math:
{backbone site}!rutgers!rauscher                (2B | not (2B)) <=> TRUE

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 91 02:23:35 GMT
From:      tcp-ip-RELAY@NIC.DDN.MIL
To:        comp.protocols.tcp-ip
Subject:   (none)

To: John Stewart
    <zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!news-server.csri.to
    ronto.edu!utgpu!cunews!jstewart@tut.cis.ohio-state.edu>
cc: tcp-ip@nic.ddn.mil, gwilliam
Subject: Re: When is a link saturated? 
In-reply-to: Your message of 21 Jan 91 14:15:30 +0000.
             <1991Jan21.141530.7031@ccs.carleton.ca> 
Date: Tue, 22 Jan 91 13:52:16 -0500
From: "George Williams" <gwilliam@sh>


    Date:    21 Jan 91 14:15:30 GMT
    From:    John Stewart <zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!news
	      -server.csri.toronto.edu!utgpu!cunews!jstewart@tut.cis.ohio-state
	      .edu>
    Subject: Re: When is a link saturated?

    In article <1991Jan20.040130.18339@quick.com> srg@quick.com (Spencer Garret
    t) writes:
    >-> I don't understand why the "remember the first exchange" is necessary. 
    >-> Both telnet and rlogin use a reserved port number that appears in eithe
 r
    >-> the source or destination TCP port fields on *every* packet that is
    >-> routed for the entire session.
    >
    >Alas, no.  A server is free to answer the connection request
    >with a different port number, and they commonly do.  (The reason
    >for this eludes me.  It is permitted by the RFC's, but not
    >required or particularly encouraged.)

    The main reason for doing so is to facilitate multiple sessions.For example
    if 10 people telnet to a machine, each user will get their own telnetd 
    process communicating to them via a unique set of ports.  Now imagine how
    difficult this would be to do if you could only have one process running 
    connected to the well known telnet port.
    -- 
    ---
    Artificial Intelligence: What some programmers produce.
    Artificial Stupidity:    What the rest of us produce.

>>> The above ( multiple sessions ) is certainly true. Additionally,
>>> it is worth noting based on past development efforts:
 
>>> () TCP, in lieu a formal session layer, allows flexibility that facilitates
>>>    not only 'one to many' but  also 'many to many' or 'many to one' address
>>>    mapping and resulting entity or process association. 
>>>
>>>    OSI does much the same but in an ostensibly more convulatuted fashion,
>>>    i.e. cum more overhead.
 
>>> () The above has proven helpful in many implementations that desire a high
>>>    degree of concurrency ( as noted above ) or paralellism of processing.
 
>>>    This has been true whether the implementation was running 'inetd' or
>>>    some other os-based process level dispatch that is network addressable.
 
>>> () It works because most, if not all, transport or application level inter-
>>>    faces to TCP ( I have seen ) use logical port assigments which permit 
>>>    loose association with a 'well known' ( reserved if you will ) network
>>>    port. 
 
>>>    Hope this helps to clarify or add further background to this
>>>    increasingly important area, Concurrency of processing in TCP based 
>>>    networks.(note: my observations are limited to TCP transport. UDP merits
>>>    a different discussion )

      George Williams

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 91 09:15:06 GMT
From:      srg@quick.com (Spencer Garrett)
To:        comp.protocols.tcp-ip
Subject:   Re: When is a link saturated?

-> In article <1991Jan20.040130.18339@quick.com> srg@quick.com (Spencer Garrett) writes:
-> >-> I don't understand why the "remember the first exchange" is necessary. 
-> >-> Both telnet and rlogin use a reserved port number that appears in either
-> >-> the source or destination TCP port fields on *every* packet that is
-> >-> routed for the entire session.
-> >Alas, no.  A server is free to answer the connection request
-> >with a different port number, and they commonly do.
-> 
In article <1991Jan21.184716.18820@Think.COM>, barmar@think.com (Barry Margolin) writes:
-> Either I misunderstand completely, or the above response is just plain
-> wrong.  If a server were to respond with a different port number, how would
-> the client's system tell which server sent the response?  The original
-> poster was correct.

My mistake.  The behavior I described is a part of the TFTP protocol,
not TCP or even UDP in general.  It is cleanly implementable, though.
All you need do is accept any foreign port number (and record the
one you accept) if the socket in question is in SYN_SENT state
and the incoming packet contains a proper SYN.  That being the case,
the socket moves into the ESTABLISHED state and all is well.
My tcp code is about to get a bit shorter.  :-)

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 91 13:49:35 GMT
From:      lodin@plains.NoDak.edu (Steve Lodin)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   D-Link Speed


I just received my D-Link LAN adapter.  Does anyone know what speed it is
capable of?  I didn't see anything in the magazine ad or the material
I received with it.

Thanks in advance...


Steven W. Lodin  
Advanced Instrumentation Engineering
Delco Electronics Corp

AT&T:    (317) 451-8722    GM: 8-322-8722
Domain:  lodin%koiasvr01.uucp@[iuvax.cs.indiana.edu or dynamo.ecn.purdue.edu]
  or     lodin@plains.nodak.edu
  or     swlodin@koess.gm.hac.com
UUCP:    [iuvax or pur-ee]!koiasvr01!lodin
GM:      LODIN, SW <KOESS::SWLODIN>

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 91 14:34:49 GMT
From:      fin@UNET.UNET.UMN.EDU ("Craig A. Finseth")
To:        comp.protocols.tcp-ip
Subject:   What service broadcasts on UDP port 60000?


   >< we're trying to figure out what service is broadcasting on
   >< UDP port 60000.  It's coming from an SCO Xenix engine
   >< with Lachman TCP/IP.
   >
   >It looks like they are trying to verify the uniqueness of their serial number.
   >
   >Nothing you can do about it, I'm afraid...

   There is always something you can do about it.  Send the software back and
   refuse to ever do business with a company which resorts to this sort of
   crap.  And be sure to let them know how you feel about this.

You can also point out that the larger the network, the more trouble
these schemes will cause.  Hence, they will alienate their largest
(potential) customer base: hardly good business practices!

(There is a long list of vendors whose products do not function here
because they were designed for "large" networks of 10-20 users: our
network has many thousands of hosts.  In one fell swoop, the vendors
have prevented themselves from selling thousands of copies.)

Craig A. Finseth			fin@unet.umn.edu [CAF13]
University Networking Services		+1 612 624 3375 desk
University of Minnesota			+1 612 625 0006 problems
130 Lind Hall, 207 Church St SE		+1 612 626 1002 FAX
Minneapolis MN 55455-0134, U.S.A.

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 91 15:51:26 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   RE: Redirects, and multiple subnets on a cable

To work efficiently in "multiple IP nets or subnets on one cable"
situations, you can't be discriminating about ICMP redirects.  This
opens up the possibility of bogus redirects taking a host off the
net.  Currently the world seems willing to accept the risk to get the
convenience.

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

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 91 16:39:20 GMT
From:      smiles@ferrari.nmc.ed.ray.com (Kevin Ruddy)
To:        comp.protocols.tcp-ip
Subject:   TCP broadcast or UDP reliability

I have a problem.

I have a server that needs to transmit high-volume data to sixty-four
clients on a dedicated network.  Broadcasting seems like the best solution,
because the server does not have the resources to transmit this data
sixty-four times.  Unfortunately, I need this data to be reliably received
by the clients.  I would have liked to use TCP, but I must go with a
broadcasting solution.

So I've been using UDP.  But when a client fails to receive a packet, how
and when do I decide to request a retransmit?  Is there a simple method of
doing this, without an inordinate amount of hassle?

Any help, any at all, will be greatly appreciated.  I have to implement some
kind of solution within the next three weeks.

Kevin Ruddy
smiles@ferrari.nmc.ed.ray.com

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 91 18:23:43 GMT
From:      cliff@garnet.berkeley.edu (Cliff Frost)
To:        comp.protocols.tcp-ip
Subject:   Re: When is a link saturated?

In article <1991Jan22.191059.5523@quick.com>, srg@quick.com (Spencer Garrett) writes:
|> ...
|> 
|> Not so.  A "connection" is identified by both source and destination
|> addresses *and port numbers*, so as long as the originator of each
|> session grabs a unique port number all is well.  My own networking
|> code does not shift away from the original well-known-port, and
|> multiple sessions work just fine.  I think the reason BSD does shift
|> port numbers may have something to do with the notion of "priviledged
|> port numbers" being those less than some small fixed number (1024
|> as I recall).  They may have thought it would be easier to implement
|> some security features if neither end of a regular session used
|> a small port number.

I think some details are missing and people are talking past eachother.
Here is my stab at making sense of what various folks are saying (comments
welcome):

I think for telnet sessions, the telnet well-known port will apear in every
packet.  This should make it possible for a device (bridge/router) to give
priority to telnet packets without maintaining per-connection information.

(Obviously, someone can set up a telnet server that listens to a different
port, and telnets to that port will not get the priority unless the device
maintains state.  Maybe this possibility is why someone claimed that it is
impossible to identify telnet connections merely by looking at packets in
isolation?)

For FTP the control connection is similarly identifiable.

For FTP the data connection can be, (and often?) is, negotiated away from
the well-known port.  This will make it difficult to give priority to ftp
data in the general case.

(Again, someone with control at both ends can play games with port numbers
to get around the priority scheme, but that same person can do this
whether or not the box in the middle maintains state.)

I think most TCP protocols are more like the telnet case than the ftp data
case, and the cisco scheme makes a lot of sense to me.

	Cliff Frost
	UC Berkeley (Computer Center, not related to BSD development)

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 91 18:47:43 GMT
From:      rlmeyering@biivax.dp.beckman.com
To:        comp.protocols.tcp-ip
Subject:   Multinet vs Wollongong whoose the best?

We currently use cmu/tek tcp/ip. We want to upgrade to a commercially supported
tcp/ip product for our vax network. We have heard that TGV and WOLLOGONG are
the two best packages. Does anyone have any personal experience to indicate
which of the two would be the best choice? Price is competive, Components
appear to be the same. Any comments on the SUPPORT provided by these vendors?

Any info would be appreciated.

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 91 18:52:47 GMT
From:      towfiq@FTP.COM (Mark Towfiq)
To:        comp.protocols.tcp-ip
Subject:   Re: select() call weirdness

In article <9101171257.AA13517@fiamass.ie> fiamass@fiamass.ie (fiamass) writes:

   We are having a problem with the select() system call on a Sun Sparc
   4/65 running SunOS 4.1.  We have a non blocking socket which we use to
   issue a connect().  This call returns EINPROGRESS as per the
   documentation.  The documentation states that under these
   circumstatances a select() call for write on that socket can be done
   to determine when the socket is fully connected. Now here is our
   problem, we make a select() call which always seems to return telling
   me that the socket is now connected. So on I go and issue a write()
   which causes the program to bomb out!  It is as if the write call does
   not return.  Has anyone any ideas?

First, the question here is what is the purpose of the select() call.
In my experience, select() is used in two situations: 1) you have more
than one socket/file descriptor which you want to perform operations
on, so you use select to find out which one is ready, perform the
operations, and come back to the select; 2) you have an operation
which you want to complete in a certain amount of time (for example
this is used in the name resolver code to send out a few UDP packets
to one nameserver, then another, and so on.  From your example it does
not seem to me that you need select for either of these reasons,
although perhaps that is just a test program.

I don't know for sure why on a Sun your code does not work, but I
would suggest some modifications to your code: 1) check the return
value of the select call, and use the information as provided by the
manual to decipher what the value might me.  If this doesn't work, try
2) using an actual timeout value, as another poster suggested.  If
this still doesn't work, then try 3) doing your connnect before making
the socket non-blocking.  If none of this works, someone is broken
somewhere.

Hope this helps,
Mark
--
Mark Towfiq, FTP Software, Inc.                                  towfiq@FTP.COM
Work No.: +1 617 246 0900			      Home No.: +1 617 488 2818

  "The Earth is but One Country, and Mankind its Citizens" -- Baha'u'llah

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 91 19:20:00 GMT
From:      sw0l+@ANDREW.CMU.EDU ("Steven L. Waldbusser")
To:        comp.protocols.tcp-ip
Subject:   Re: CMU SNMP and/or opinions


Excerpts from internet.tcp-ip: 21-Jan-91 CMU SNMP and/or opinions Kathy
R. c. x3899@aedc-v (955)

> 	I am looking for a public domain SNMP package. I understand 
> Carnegie-Mellon has written a package, but I am not sure how or where to look 
> for it.  If there are any other public domain packages available, I am not 
> aware of them.  


CMU SNMP is available for anonymous FTP from lancaster.andrew.cmu.edu in
the file pub/cmu-snmp1.0.tar (or get the newer beta version in
pub/snmp1.1b.tar).

There are two other public domain packages, MIT and ISODE:
MIT: allspice.lcs.mit.edu, file "pub/snmp/snmp.tar"
ISODE: uu.psi.com, file pilot/src/...

  The CMU code continues to be enhanced and updated.  There is no
mailing list of users (although I consider this occasionally), but there
are several hundred users, many of whom read the snmp mailing list (as I
do).  There is no telephone support.  If you need support of this level,
I'd suggest one of the many fine commercial packages such as the one
from SNMP Research.

  Predictably, my opinions about the CMU package are pretty high, so I
won't bother to comment.


Steve

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 91 21:45:57 GMT
From:      davidd@wolf.cs.washington.edu (David Doll)
To:        comp.protocols.tcp-ip
Subject:   communication between different machines

Hello, I'm running a "c" code program on a SUN 4/110 which asks for the user
to input some expression (like {{a,b},c} ) and then passes (through a pipe)
that to Mathematica which crunches away. Periodicaly during crunching, math
will need to send intermidate data to a DEC which is doing graphics. Now
the question is how to go from SUN to DEC? UNIX domain sockets I guess but
I'm having a hellofa time getting anything to fly - guess my lack of
experience in the area is showing :) Could anybody point me to any code?
This would be greatly appreicated. Sorry if this is the wrong news-group, I
didn't know where to turn. Thanks.



--
David Doll
Computer Science & Enginnering
University of Washington
Seattle, WA 98195
M/S: FR-35
davidd@cs.washington.edu

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 91 22:42:06 GMT
From:      rick@bnrunix.UUCP (Rick Johns)
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   PD TCP/IP and 802.2/802.3 software?


I am looking for public domain TCP/IP and 802.2 (Level 1)/ 802.3
software.  The idea is to run it on a custom 68020-based board. I
realize a certain amount of modification will be necessary.  I am not
looking for the full protocol set. I will be happy with the bare
minimum that will let me talk to socket-based programs on Unix.
Anything more will be a bonus.

Can anyone tell me if such software is available and where I can get a copy?
FTP sites are probably best. 

I am also looking for comments about quality of the software.  TIA.

rjohns@bnr.ca

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 91 23:45:32 GMT
From:      Will@cup.portal.com (Will E Estes)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   How Scalable Is 3172 Channel Attached To An IBM Host?

I need to get an idea for the maximum number of users that I can
get to connect to an IBM mainframe using TCP/IP.  I'm interested
in factors that limit performance (e.g., I'm assuming that probably
50% of the host CPUs time is going to be spent just running the
TCP connection for each user); I am particularly interested in 
any bottlenecks that would physically prevent more than a given number
of users from connecting.  I'm assuming that a single 3172 probably
supports a finite number of concurrent TCP connections to the IBM
host, but could you use multiple 3172s, or multiple gateways from
some other manufacturer, that would allow you get many hundreds of
concurrent connections?  Today I might only need a few hundred connections.
Over time this number might approach 1000 concurrently connected users,
so I need a scalable architecture.  Any thoughts on this are 
appreciated.

Thanks,
Will Estes        (apple!cup.portal.com!Will)

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 91 00:30:38 GMT
From:      dana@locus.com (Dana H. Myers)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject:   Re: Xircom has worst performance in PC Magazine tests

In article <NELSON.91Jan21132425@sun.clarkson.edu> nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) writes:
>The Xircom Pocket LAN Adapter had the worst performance of three pocket
>lan adapters in a PC Magazine review, published in the February 12, 1991
>issue.
>
>	Adapter		mbps
>	p.LAN		1.1
>	D-Link		1.07
>	Xircom		0.95
>
>Please don't buy Xircom products.  They used some of my software in
>violation of its copyright.  Write for details...

  While Russ may have a beef with Xircom over software copyright,
the performance of the Xircom adapter is within 85% of the best in this
comparison. I wouldn't call this bad performance.

-- 
 * Dana H. Myers KK6JQ 		| Views expressed here are	*
 * (213) 337-5136 		| mine and do not necessarily	*
 * dana@locus.com		| reflect those of my employer	*

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 91 02:03:18 GMT
From:      mra@srchtec.uucp (Michael Almond)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: How do I configure a SLIP connection (VAX/750 4.3bsd)

In article <1046@lclark.UUCP> dan@lclark.UUCP (Dan Revel) writes:
>I tried: 
>
># slattach /dev/tty00 9600
>ioctl (TIOCSETD): No such device

You need to configure the "pseudo-device sl" into your kernel.

-- 
Michael R. Almond (Georgia Tech Alumnus)           mra@srchtec.uucp (registered)
search technology, inc.				      mra%srchtec@salestech.com
4725 peachtree corners cir., suite 200		       emory!stiatl!srchtec!mra
norcross, georgia 30092					 (404) 441-1457 (office)

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 91 02:29:24 GMT
From:      kkc@pandora.cs.wayne.edu (Kwok K. Chan)
To:        comp.dcom.lans,comp.protocols.ibm,comp.protocols.misc,comp.protocols.tcp-ip,comp.misc
Subject:   Need TCP/IP and SNA convertor info.



I need HELP !

I am trying to form a connection between the TCP/IP Ethernet and
SNA gateway.

  ________                              ___________
  |      |  Ethernet   (  ??  )  SNA    |  SNA    |
  | SUNs |-------------(  ??  )---------| GateWay |
  |______|  TCP/IP     (  ??  )         |_________|
                                             |
                                             |
                                        _____|____
                                        |   FEP  |
                                        |________|
                                             |
                                             |
                                        _____|_____
                                        |   IBM   |
                                        |MainFrame|
                                        |_________|

I have tried to find out if there is any existing product 
(device, board, .. ) which can do that protocol conversion.
But I have no luck so far.

Any netter have the similar experience or know anything 
about that. Please email me:  kkc@cs.wayne.edu

Thank you very much.

--
***************************************************************************
No signature yet
***************************************************************************

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 91 04:24:45 GMT
From:      jc@minya.UUCP (John Chambers)
To:        comp.protocols.tcp-ip
Subject:   Re: inet_ntoa()

In article <9101111551.AA02933@taipan.coral.com>, greene@coral.com (Jeremy Greene) writes:
> 
> The Sun man pages has the following definition:
>     char *inet_ntoa( ipAddr )
>     struct in_addr ipAddr;
> which use to work, instead of
>     char *inet_ntoa( ipAddr )
>     struct in_addr *ipAddr
> which now works. Has anyone else had this problem?

Yeah; it bit me a couple months ago, while working on some SNMP agents
that had to be coded portably across a set of machines that included
Suns, DECstations, HPs, Convexes, ...

I solved the problem by replacing all the calls on inet_ntoa with a
routine that I spent about 3 minutes writing.  It's easy to do, it's
portable, and it took me far less time to write it than it did to 
diagnose the problem caused by this @#*&$@ variability in inet_ntoa.

(Grumble.  Gripe.  Why do they do this to us?  Do they think that there
is a need of makework, so that programmers will still have jobs? ;-)

Actually, it was benificial, too.  I added a length parameter (which
is always 4 where inet_ntoa was used).  The routine works just fine 
in converting ASN.1 object ids to dotted-decimal notation.  Consider
it one small step in replacing TCP/IP with OSI.  Enough snafus like
this, and it'll all be OSI...

-- 
All opinions Copyright (c) 1991 by John Chambers.  Inquire for licensing at:
Home: 1-617-484-6393 
Work: 1-508-486-5475
Uucp: ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc 

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 91 05:05:31 GMT
From:      mco@slimer.UUCP (Mark C. Otto)
To:        comp.os.os2.misc,comp.protocols.tcp-ip
Subject:   Re: LM/X

In article <13285@asylum.SF.CA.US> sharon@asylum.SF.CA.US (Sharon Fisher) writes:
>I'm working on a story for Unix World about LAN Manager/X, or LAN
>Manager for Unix.  How many implementations of it are there?  Is
>anybody actually using it?  I'd be interested in hearing from users or
>vendors.  ... [rest deleted] ...

I use it every day.  I use LM/X (by Hewlett-Packard) on my HP 9000/375
workstation and access it from my HP RS20C personal computer under OS/2
version 1.2 with Lan Manager 2.0.  I can also run MS-DOS 4.01 and get at
the LM/X server via HP Officeshare (wonderful stuff, this backward
compatability).  What would you like to know?  Oh, by the way, ignore
the Orgganization line and my .sig, since Versatile Systems no longer
exists; I work for Hewlett-Packard, but not for the division that makes
LM/X so I think I can remain objective.  Be that as it may, I sysop the
375 and have a group of approximately 10 R&D engineers and support personnel
that share the drives and printer offered up through LM/X and have had *NO*
problems and *NO* maintenance hassles ever since I installed it almost a
year ago.  It seems to be a fine well-designed product in keeping with
the high quality of workstation software (as compared to that of the PC
world) in general.  What else would you like to know?
 


-- 
Mark C. Otto   EMail: mco@slimer, {teemc | hpftc}!slimer!mco
Voice: 1-313-441-4264    USnail: 5133 Heather #208, Dearborn, MI. 48126
Quote: "Yeah. Right. Kermit my a*s." - Mark C. Otto, '90

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 91 05:20:49 GMT
From:      mcg@violet.berkeley.edu (Michael C. Greenspon)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.appletalk,comp.sys.mac.system
Subject:   MacTCP port of RPC/XDR?

We're wondering if anyone has ported RPC to run with MacTCP under the Mac OS.
We need at least the client-side implementation in order to call a compute
server using RPC.

Please respond directly if you know of such a port or would be interested/able
to advise on how to modify the public domain code to work with MacTCP.

Thanks, --Michael

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 91 11:24:00 GMT
From:      LAWRENCE%cmu.unige.ch@PUCC.PRINCETON.EDU ("Graham Lawrence ", CMU Geneva)
To:        comp.protocols.tcp-ip
Subject:   Subscription


Please take me off the mailing list. Thanks!

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 91 13:35:23 GMT
From:      niklas@appli.se (Niklas Hallqvist)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: Another PCNFS & PKTD.SYS problem

fks@vaxeline.COM (Frances Selkirk) writes:

>In article <1261@appli.se> niklas@appli.se (Niklas Hallqvist) writes:
>>I've installed the Packet driver compatibility kit for PCNFS because
>>I thought I'd be able to run PCNFS through it, but still allowing other
>>software to use the Ethernet adapter I'm using (3C503).  Specifically
>>I want to be able to use WinQVTnet under Windows 3.  Well, at this
>>point I get error 10, TYPE_INUSE.  It seems that only one software
>>package at a time can get the TCP/IP-packets coming in, regardless of
>>TCP port. 
 
>That is correct. The packet driver sorts packets by type, sending all
>IP packets to the IP stack, and packets of other types to their respective
>stacks. Once one IP stack has "registered" with the packet driver, another
>IP stack cannot use it, however, a product based on another protocol type, 
>such as Netware (IPX), can use it.

Ok, so does anyone know if there is a possibility to redirect the packet
driver's packets to another IP stack temporarily?  This problem can't be
rediscovered very seldom, I think, so maybe someone solved it before?
A possible way would be to have a 'push' & 'pop' executables, who operated
on a registration stack.  Only the registration on top of the stack would
get the IP packets.  Then one could have a .bat file saying something like:

push IP
telbin
pop IP

when one wanted to start telbin, and PC/NFS had control over the packetdriver.
Of course NFS wouldn't be accessible from within telbin.  How does this sound?

-- 
Niklas Hallqvist	Phone: +46-(0)31-40 75 00
Applitron Datasystem	Fax:   +46-(0)31-83 39 50
Molndalsvagen 95	Email: niklas@appli.se
S-412 63  GOTEBORG, Sweden     mcsun!sunic!chalmers!appli!niklas

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 91 13:36:20 GMT
From:      scoggin@DELMARVA.DELMARVA.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   SCO UNIX cpd

I agree that the cpd daemon is a nuisance.  Does anyone know what happens if
you remove it from the rc startup scripts?  I've bought four copies of SCO
Open DeskTop (in fact, we were in the developer program) - have never cheated
them out of a dime.  Four machines - four copies.  But the traffic is an
annoyance, and I do have a strong aversion to these childish protection schemes.
(In fact, I have never soiled one of my systems with Lotus 123, for the same
reason!)

If anyone has tried this, I would be interested in the results.

----------------------------------------------------------------------
John K. Scoggin, Jr.	
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		Fax:	(302) 451-5321
500 N. Wakefield Drive			Email:	uunet!delmarva!scoggin
Newark, DE  19714	                        delmarva!scoggin@uunet.UU.NET
"Never underestimate the bandwidth of a station wagon load of magnetic
 tapes screaming down the interstate!"			

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 91 15:09:33 GMT
From:      pwoollar@crc.ac.uk (Peter Woollard x3296)
To:        comp.protocols.tcp-ip
Subject:   OS/2 via Ethernet to Suns?


We would like to connect a Pc running OS/2 to a Sun file server running SunOs 4.0.3 
via Ethernet. Does anyone know of the existance of software to do this?

I have tried many companies, but have only had minimal information, so I thought that I would try the News.

Thanks for any help,

Peter Woollard

Computing Services Section,		 Janet:       P.Woollard@UK.AC.CRC
MRC-Clinical Research Centre,		 Elsewhere:   P.Woollard@CRC.AC.UK
Watford Rd, HARROW, Middx, HA1 3UJ, U.K. EARN/Bitnet: P.Woollard%CRC@UKACRL
Tel 081-869 3296    Fax 081-423 1275     Usenet: ...!mcsun!ukc!mrccrc!P.Woollard

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 91 16:13:05 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: When is a link saturated?


    For FTP the data connection can be, (and often?) is, negotiated away from
    the well-known port.  This will make it difficult to give priority to ftp
    data in the general case.
    
There exist FTP servers which won't initiate data connections to clients
unless the client's port is 20 (the well known FTP data port).  Thus, most
Internet-tested implementations can be expected to be identifiable.

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

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 91 16:18:43 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Changing TCP port (was Re: When is a link saturated?)

In article <1991Jan23.091506.9399@quick.com> srg@quick.com (Spencer Garrett) writes:
>In article <1991Jan21.184716.18820@Think.COM>, barmar@think.com (Barry Margolin) writes:
>-> Either I misunderstand completely, or the above response is just plain
>-> wrong.  If a server were to respond with a different port number, how would
>-> the client's system tell which server sent the response?  The original
>-> poster was correct.
>My mistake.  The behavior I described is a part of the TFTP protocol,
>not TCP or even UDP in general.  It is cleanly implementable, though.
>All you need do is accept any foreign port number (and record the
>one you accept) if the socket in question is in SYN_SENT state
>and the incoming packet contains a proper SYN.  That being the case,
>the socket moves into the ESTABLISHED state and all is well.

This won't work in general.  First of all, the client system might use the
same local port for connections to different servers on the remote machine;
when there are multiple connections in SYN-SENT with the same local port,
the foreign port is used to distinguish them.  Also, if a local port is
reused for a later connection to a different server on the same host, and a
delayed SYN response from the first server were received, it would look
like the response to the new SYN.  However, I expect that if TCP were
allowed to pull the above stunt then we could simply require that the
3-tuple <local-address, local-port, foreign-address> be kept unique for at
least 2MSL (many TCP implementations simply step through the local ports
for every active open, so this would happen naturally).

Something like this could be added to TCP using the option mechanism.  The
original SYN could include an option indicating willingness to accept an
alternate port from the server.  The SYN response could include an option
specifying the port to be used for further segments.  We could call the
option "NCP-ICP", since I think this was the Initial Connection Protocol of
the original Arpanet Host-to-Host protocol (frequently called "NCP").
--
Barry Margolin, Thinking Machines Corp.

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

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 91 16:44:00 GMT
From:      WARD@CC.UMontreal.CA
To:        comp.protocols.tcp-ip
Subject:   Re: LM/X

> Date: Mon, 21 Jan 91 18:01:52 GMT
> From: Sharon Fisher <asylum!sharon@DECWRL.DEC.COM>
> 
> I'm working on a story for Unix World about LAN Manager/X, or LAN
> Manager for Unix.  How many implementations of it are there?  Is
> anybody actually using it?  I'd be interested in hearing from users or
> vendors.  For now, I'd like to ask people to email me or post, rather
> than call, because I don't have a firm assignment yet; I need to do a
> little research and then do a proposal.  Thanks...

Last summer, we tested HP LAN Manager and HP LM/X (on a HP 9000) and
found that solution very interesting. We now have one lab of 20 PCs
running LAN Manager and connected to an LM/X server (HP 9000) where
are stored WINDOWS 3.0, LOTUS, WORD PERFECT and even DOS. The lab
is connected to the campus network so that we can upgrade the server
from the network. We can also run LAN Manager on a PC not on the same
subnet.

BTW, anyone one the net is running LAN Manager/packet driver combination ?
We would like to do so (and then use NCSA Telnet with LAN Manager).
We are also interested in adding a mail service in this configuration.
Any experience someone ?

Patrick Ward                       e-mail : Ward@CC.UMontreal.CA
Services informatiques             voice  : (514)343-6111 ext.5259
Universite de Montreal             fax    : (514)343-2155
2900 boul. Edouard Montpetit
Montreal, Quebec, H3C 3J7, CANADA

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 91 17:54:30 GMT
From:      davy@ERG.SRI.COM
To:        comp.protocols.tcp-ip
Subject:   NFSWATCH 3.0 now available.


NFSWATCH Version 3.0 is now available for anonymous FTP from the host

	ftp.erg.sri.com		(128.18.4.39)

in the file "pub/nfswatch3.0.tar.Z".  We do not have UUCP access.  Please
do not ask me to mail you a copy; I don't have time.  I'm sure that the
various archive sites (sun-spots, osu-cis, etc.) will pick it up in the
next few days...

The README file is enclosed below.

								January, 1991

This is NFSWATCH Version 3.0.  It lets you monitor NFS requests to any
given machine, or the entire local network.  It only monitors NFS
client traffic (NFS requests), it does not (and cannot) monitor the
return traffic from the server in response to those requests.

There have been many changes since NFSWATCH 2.0:

	- The "-allif" option allows NFSWATCH to read packets from all
	  configured network interfaces, instead of only a single
	  interface.

	- The '[' and ']' commands have been added to "scroll" the
	  bottom part of the display, which when displaying client
	  names can be longer than the number of lines you have.

	- The 'p' command changes the display to show NFS procedures
	  and the percentages of each.

	- A real help screen has been added to replace the single-line
	  help.

	- The per-client table for recording statistics is now hashed, for
	  better speed.

	- NFSWATCH now compiles and runs on Ultrix 4.1.

	- When Ultrix 4.2 comes out, the code is present to allow
	  capture of "packets to self" (the machine NFSWATCH is
	  running on), so the "pfcopyall" program will no longer be
	  needed.

	- There is a bug in the NIT driver under pre-4.1 SunOS which
	  will make NFSWATCH not classify packets properly (they all
	  end up as "other").  The #ifdefs intended to avoid this in
	  version 2.0 have been fixed.

	- NFSWATCH now attempts to intuit the byte order in the file
	  handle, so that machines with opposite-order bytes from the
	  one NFSWATCH is running on can still be decoded.  Since file
	  handles are opaque, this is better than nothing, but not by
	  much.

NFSWATCH has been tested on the following architectures:

	Sun-3 SunOS 4.1
	Sun-4 SunOS 4.1

	DEC VAX   Ultrix 4.0, 4.1
	DEC RISC  Ultrix 4.0, 4.1

To compile NFSWATCH, just type "make".  On SunOS systems, it needs to
either be run as root, or made setuid root (this is safe; it setuids
itself back after opening the NIT device).  On Ultrix systems, it does
not need to be setuid root or run as root, but the super-user has to
enable promiscuous mode operation using pfconfig(8).

On pre-4.2 Ultrix systems, the enclosed "pfcopyall" program can be
used to change the value of this variable in the kernel so that you
can see packets from the host you are running on.  Otherwise, these
packets will not be included in the output of NFSWATCH.

You can redistribute this program as much as you want.  All we ask is
that you ive credit where credit is due.  If you make modifications or
bug fixes, please send them to us so they can be incorporated into the
next release.

Dave Curry					Jeff Mogul
SRI International				Digital Equipment Corp.
333 Ravenswood Avenue				Western Research Laboratory
Menlo Park, CA 94025				100 Hamilton Avenue
davy@erg.sri.com				Palo Alto, CA 94301
						mogul@decwrl.dec.com

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 91 20:29:05 GMT
From:      rlg@desktalk.com (Richard L. Gralnik)
To:        comp.protocols.tcp-ip
Subject:   (none)


Lotus,  Equifax  cancel  shipment  of  Lotus MarketPlace:Households
    CAMBRIDGE, Mass.--(BUSINESS WIRE)--Lotus Development Corp. and
Equifax Inc. Wednesday announced the cancellation of Lotus
MarketPlace: Households, a CD-ROM database product of names,
addresses, and marketing information on 120 million U.S.  consumers
originally scheduled for shipment in March.
    The companies said the decision to cancel the product came after
an assessment of the public concerns and misunderstanding of the
product, and the substantial, unexpected additional costs required to
fully address consumer privacy issues.
    Lotus also announced that it will discontinue shipment of Lotus
MarketPlace: Business, a database of information on seven million
U.S.  businesses that began shipping in October 1990.
    "Unfortunately, Lotus MarketPlace: Households is at the apex of
an emotional firestorm of public concern about consumer privacy.
While we believe that the actual data content and controls built into
the product preserved consumer privacy, we couldn't ignore the high
level of consumer concern," said Jim Manzi, Lotus' president and
chief executive officer.  "After examining all of the issues we have
decided that the cost and complexity of educating consumers about the
issue is beyond the scope of Lotus as a software provider."
    "Technology is radically changing the way we work and, more
importantly, how we use information," said Manzi.  "Balancing the
advantages of easier access to information with the individual's
right to privacy is only the first of many new issues our industry
will grapple with in the coming years."
    C.B.  (Jack) Rogers, Jr., president and chief executive officer
of Equifax, which provides the data in MarketPlace, said: "Equifax
has made several key investments in consumer-oriented initiatives,
including our sponsorship of a national survey of consumer attitudes
on privacy.  The major survey finding was that consumers are willing
to make trade-offs for the use of their personal information when
they clearly understand the benefits.  Despite our significant
consumer education efforts, consumer misperceptions about this new
product offered through this distribution channel persist."
    In developing Lotus MarketPlace: Households, Lotus and Equifax
implemented a number of privacy-related controls that exceeded
traditional direct-marketing industry practices.  These practices
were the result of extensive research of the consumer privacy issue
prior to product development, including testing the product concept
with several consumer focus groups and counsel from a nationally
recognized consumer-privacy expert.  The practices included:
    o Limiting the data.  Specifically excluded from the product were
      telephone numbers and individual personal data such as actual
      income, credit data, and purchase history;
    o Offering the data only to legitimate businesses, through a
      controlled purchase process;
    o Educating and advising users about the proper legal and ethical
      responsibilities for list usage; and
    o Providing several Lotus- and Equifax-funded options for
      consumers to have their names removed from the database.
    "We developed MarketPlace in response to a perceived need and
real market opportunity.  MarketPlace is an innovative tool for small
businesses, who are often shut out of sophisticated direct marketing
because of its cost or complexity," said Manzi.  "The market for
tools like MarketPlace is a viable one.  At the same time, the
product is not part of our core business, and Lotus would be
ill-served by a prolonged battle over consumer privacy."
    Rogers added: "Equifax is a technology leader and, equally
important, a pioneer in the area of consumer privacy protection in
the information industry.  While we remain committed to using the
most sophisticated technology available, we are equally committed to
maintaining the delicate balance between legitimate information needs
of business and consumers' privacy concerns."
    The Lotus MarketPlace product family was a suite of CD-ROM
(compact-disc, read-only memory) database tools that used the Apple
Macintosh personal computer to make it easy for businesses to find
new customers.

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 91 23:27:51 GMT
From:      kathleen@VENERA.ISI.EDU (Kathleen McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   RE: ISI W-Notes


John,

Yes, Jon Postel has copies of W-Notes and I will make a copy of W-Note 28
and send it to you via snail mail.

--Kathleen

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 91 08:19:21 GMT
From:      jlk@siesoft.co.uk (Jim Kissel)
To:        comp.protocols.tcp-ip
Subject:   Re: OS/2 via Ethernet to Suns?

In article <473@carbon.crc.ac.uk> pwoollar@crc.ac.uk (Peter Woollard x3296) writes:
>
>We would like to connect a Pc running OS/2 to a Sun file server running SunOs 4.0.3 
>via Ethernet. Does anyone know of the existance of software to do this?
>

Try TCP/IP for OS/2 from IBM.  Program number 5798-RXW  Part # 66F5612
If you use this you will also require IBM's EE and Communication Manager.
The package has about everything you could want for TCP.

RIP,FTP,SNMP,SMTP,RCP,RSH,NFS.........

I haven't evaluated it yet, but the manuals indicate a complete package.
-------------------------------------------------------------------------------
Jim Kissel                            Telephone +44 344 863 222
Siemens Nixdorf Information Systems                 344 850 461 (Direct line)
Systems Development Group             Fax       +44 344 850 452
Siemens Nixdorf House                 Domain     jlk@siesoft.co.uk
Oldbury, Bracknell, Berkshire                    j.kissel@xopen.co.uk
RG12 4FZ  Great Britain               UUCP       ....{ukc,athen}!siesoft!jlk
-------------------------------------------------------------------------------

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 91 08:55:40 GMT
From:      girard@kestrel.my.bull.fr (Francois Girard)
To:        comp.protocols.tcp-ip
Subject:   package on UNIX SCO.


I am looking for anyone who has any information/experience regarding
the packaging of any software on UNIX SCO.

I would like to know what are the files used bye "sysadmsh" ?
                     What is the content of the file "/perms/soft" ?
		     And all that is necessary to build a package .

Thanks in advance for your help,

F.G.
girard@my.bull.fr

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 91 09:21:23 GMT
From:      lucio@proxima.UUCP (Lucio de Re)
To:        comp.protocols.tcp-ip
Subject:   Re: What service broadcasts on UDP port 60000?

In article <13743@scorn.sco.COM> ericd@sco.COM (Sharky the Lanshark) writes:
>
>In article <i1kbh2.=28@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:
>>< we're trying to figure out what service is broadcasting on
>>< UDP port 60000.  It's coming from an SCO Xenix engine
>>< with Lachman TCP/IP.
>>It looks like they are trying to verify the uniqueness of their serial number.
>
>Correct..
>
>>Nothing you can do about it, I'm afraid...S
>
>Close, it is possible to obtain a patch that will reduce how often 
>the Copy Protection Daemon (CPD) bradcasts to the network.
>
>SOLUTION: Support Level Supplement (SLS) lng248, installs a new cpd daemon 
>	  that checks for copy protection violations less often.
>	  This SLS is only for SCO TCP/IP Release 1.0.1.

Any reason one can't merely unload the cpd (kill -9)?

Lucio de Re                               ...uunet!ddsw1!proxima!lucio
-------------------- plan to throw THIS one away -- lucio@proxima.UUCP

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 91 10:17:29 GMT
From:      zawada@cs.qmw.ac.uk (Simpson)
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Re: PD TCP/IP and 802.2/802.3 software?

An implementation of TCP is available on fish disk 225 for the
Amiga (68000 based). It should require only minor modification to work
on a 68020. I don't actually use it so I can't vouch as to the
quality of the software, but the source is included in the zoo
archive. It seems to provide compatibility to ARPA RFC-793 if
that means anything.


The package provides IP, UCMP, TCP,UDP, mail program, ARP, FTP
and Telnet.

All the source to the protocols and the applications is provide.


It Can be obtained from

ux1.cso.uiuc.EDU

by anonymous ftp.

The file is,       amiga/fish/ff225/AmigaTCP.zoo

A list of files contained in the archive...

Zoo:  AmigaTCP/.info -- extracted
Zoo:  AmigaTCP/POSTER -- extracted
Zoo:  AmigaTCP/POSTER2 -- extracted
Zoo:  AmigaTCP/bin/net -- extracted
Zoo:  AmigaTCP/bin/telnetp -- extracted
Zoo:  AmigaTCP/src/amiga.c -- extracted
Zoo:  AmigaTCP/src/amiga.h -- extracted
Zoo:  AmigaTCP/src/amigadev.c -- extracted
Zoo:  AmigaTCP/src/arp.c -- extracted
Zoo:  AmigaTCP/src/arp.h -- extracted
Zoo:  AmigaTCP/src/ax25.c -- extracted
Zoo:  AmigaTCP/src/ax25.h -- extracted
Zoo:  AmigaTCP/src/cmdparse.c -- extracted
Zoo:  AmigaTCP/src/cmdparse.h -- extracted
Zoo:  AmigaTCP/src/devstub.asm -- extracted
Zoo:  AmigaTCP/src/ether.c -- extracted
Zoo:  AmigaTCP/src/ether.h -- extracted
Zoo:  AmigaTCP/src/ftp.c -- extracted
Zoo:  AmigaTCP/src/ftp.h -- extracted
Zoo:  AmigaTCP/src/ftpcli.c -- extracted
Zoo:  AmigaTCP/src/ftpserv.c -- extracted
Zoo:  AmigaTCP/src/functions.h -- extracted
Zoo:  AmigaTCP/src/hexload.c -- extracted
Zoo:  AmigaTCP/src/icmp.c -- extracted
Zoo:  AmigaTCP/src/icmp.h -- extracted
Zoo:  AmigaTCP/src/iface.h -- extracted
Zoo:  AmigaTCP/src/inetdev.h -- extracted
Zoo:  AmigaTCP/src/inetlib.h -- extracted
Zoo:  AmigaTCP/src/internet.h -- extracted
Zoo:  AmigaTCP/src/ip.c -- extracted
Zoo:  AmigaTCP/src/ip.h -- extracted
Zoo:  AmigaTCP/src/iproute.c -- extracted
Zoo:  AmigaTCP/src/machdep.h -- extracted
Zoo:  AmigaTCP/src/main.c -- extracted
Zoo:  AmigaTCP/src/makefile -- extracted
Zoo:  AmigaTCP/src/mbuf.c -- extracted
Zoo:  AmigaTCP/src/mbuf.h -- extracted
Zoo:  AmigaTCP/src/misc.c -- extracted
Zoo:  AmigaTCP/src/netrom.c -- extracted
Zoo:  AmigaTCP/src/netrom.h -- extracted
Zoo:  AmigaTCP/src/netuser.c -- extracted
Zoo:  AmigaTCP/src/netuser.h -- extracted
Zoo:  AmigaTCP/src/newtelnetp.c -- extracted
Zoo:  AmigaTCP/src/session.h -- extracted
Zoo:  AmigaTCP/src/slip.c -- extracted
Zoo:  AmigaTCP/src/slip.h -- extracted
Zoo:  AmigaTCP/src/smisc.c -- extracted
Zoo:  AmigaTCP/src/smtp.h -- extracted
Zoo:  AmigaTCP/src/smtpcli.c -- extracted
Zoo:  AmigaTCP/src/smtpserv.c -- extracted
Zoo:  AmigaTCP/src/tcp.h -- extracted
Zoo:  AmigaTCP/src/tcpin.c -- extracted
Zoo:  AmigaTCP/src/tcpout.c -- extracted
Zoo:  AmigaTCP/src/tcpsubr.c -- extracted
Zoo:  AmigaTCP/src/tcptimer.c -- extracted
Zoo:  AmigaTCP/src/tcpuser.c -- extracted
Zoo:  AmigaTCP/src/telnet.c -- extracted
Zoo:  AmigaTCP/src/telnet.h -- extracted
Zoo:  AmigaTCP/src/telnetp.c -- extracted
Zoo:  AmigaTCP/src/timer.c -- extracted
Zoo:  AmigaTCP/src/timer.h -- extracted
Zoo:  AmigaTCP/src/tnserv.c -- extracted
Zoo:  AmigaTCP/src/trace.h -- extracted
Zoo:  AmigaTCP/src/ttydriv.c -- extracted
Zoo:  AmigaTCP/src/udp.c -- extracted
Zoo:  AmigaTCP/src/udp.h -- extracted
Zoo:  AmigaTCP/src/version.c -- extracted
Zoo:  AmigaTCP/userman.doc -- extracted
Zoo:  AmigaTCP/userman.doc.info -- extracted

                 ZAWIE   

Mark Simpson                                        Snail Mail:

Internet:  zawada%cs.qmw.ac.uk@nsfnet-relay.ac.uk | Computer Science Dept
JANET:     zawada@uk.ac.qmw.cs                    | QMW, University of London
       /                                          | Mile End Road
      /                                           | London E1 4NS
    \/                                            | United Kingdom   
--
Mark Simpson                                        Snail Mail:

Internet:  zawada%cs.qmw.ac.uk@nsfnet-relay.ac.uk | Computer Science Dept
JANET:     zawada@uk.ac.qmw.cs                    | QMW, University of London
       /                                          | Mile End Road
      /                                           | London E1 4NS
    \/                                            | United Kingdom

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 91 14:03:27 GMT
From:      backman@vaxeline.COM (Larry Backman)
To:        comp.protocols.tcp-ip
Subject:   Re: OS/2 via Ethernet to Suns?

In article <473@carbon.crc.ac.uk> pwoollar@crc.ac.uk (Peter Woollard x3296) writes:
>
>We would like to connect a Pc running OS/2 to a Sun file server running SunOs 4.0.3 
>via Ethernet. Does anyone know of the existance of software to do this?
>
>I have tried many companies, but have only had minimal information, so I thought that I would try the News.
>



At the current time the onlyOS/2 TCP products that I know of that support
NFS are IBM's TCP/IP V1.1 & our PCTCP for OS/2 V1.1.  IBM's is a shipping
product, while FTP Softwares product is in beta.

If you are only looking for file transfer, then 3COM, Ungerman-Bass,
Wollongong, Essex Software, and probably some others that I have ommitted,
will provide FTP to and from your Sun.



				Larry Backman
				backman@ftp.com

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 91 18:27:26 GMT
From:      amanda@visix.com (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS for Mac...

InterCon Systems Corp. also sells a Macintosh NFS client product called
"NFS/Share."  For more information, contact them at +1 703 709 9890.

Disclaimer: I used to work for InterCon, but I am not involved with this
product except as a happy user.
-- 
Amanda Walker <amanda@visix.com>
Visix Software Inc.
--
Entropy requires no maintenance.

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 91 19:48:09 GMT
From:      MAB@CORNELLC.CIT.CORNELL.EDU (Mark Bodenstein)
To:        comp.protocols.tcp-ip
Subject:   Re: How Scalable Is 3172 Channel Attached To An IBM Host?

On 23 Jan 91 23:45:32 GMT you said:
>I need to get an idea for the maximum number of users that I can
>get to connect to an IBM mainframe using TCP/IP.  ...

We currently have about 200 users connecting to one of our IBM mainframes
using version 1 of the IBM VM TCP/IP software and one 8232 front end
processor.  The CPU used is perhaps 5% of a 3090J processor.  This same
8232 supports perhaps 350 megabytes per day (approx 50,000 files) sent
via the VMNET (RSCS over TCP/IP) protocol, plus various other services
(e.g. SMTP, FTP, and a campus information service.)

> ...                           I am particularly interested in
>any bottlenecks that would physically prevent more than a given number
>of users from connecting.

Our current configuration will support up to around 300 telnet connections,
based on the virtual memory available to the server, the amount it uses
per connection, and the other uses here of TCP.  The next version of the
IBM software, currently available but not yet in production here, increases
this limit to around 2000 with a 370 mode service virtual machine, and I
believe to around 4096 (the current operating system limit for this kind of
login) with an XA mode service virtual machine (this latter capability has
been announced on the network but not yet distributed, as far as I know.)

>                           I'm assuming that a single 3172 probably
>supports a finite number of concurrent TCP connections to the IBM
>host, but could you use multiple 3172s, or multiple gateways from
>some other manufacturer, that would allow you get many hundreds of
>concurrent connections?

A 3172 is about an order of magnitude better performer than the 8232
which I mentioned that we use.  It should not be the limitation on
number of users connected within the ranges we're discussing, for
ordinary terminal sessions.

>                         Today I might only need a few hundred connections.
>Over time this number might approach 1000 concurrently connected users,
>so I need a scalable architecture.  Any thoughts on this are
>appreciated.

You should be able to do this with the current technology.

Mark Bodenstein  (mab@cornellc.cit.cornell.edu; 607-255-8059)
Cornell University

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 91 04:27:28 GMT
From:      mra@srchtec.searchtech.com (Michael Almond)
To:        comp.protocols.tcp-ip
Subject:   uucp over TCP/IP

We are in the process of setuping our site to connect with PSINet over a
SL/IP connection.  Does anyone know how to do UUCP exchanges using
TCP/IP?

I would assume it is possible using telnet or rlogin maybe.

Thanks.

-- 
Michael R. Almond (Georgia Tech Alumnus)           mra@srchtec.uucp (registered)
search technology, inc.				      mra%srchtec@salestech.com
4725 peachtree corners cir., suite 200		       emory!stiatl!srchtec!mra
norcross, georgia 30092					 (404) 441-1457 (office)

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 91 06:10:59 GMT
From:      rock@rancho.uucp (Rock Kent)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   NCSA Telnet Mods for META Terminal???

I recently started using NCSA Telnet 2.3b11 and really appreciate the
improvements in keyboard mapping over the 2.3b9 I was using.  

I would like, however, to remap the alt-alpha characters to their
meta- versions (ascii code + 128) in order to work with GNUemacs as a
meta- terminal.  NCSA Telnet, though, traps all alt-alpha keys before
they reach the mapping interface.  

Has anyone modified NCSA Telnet to use some key other than alt- to
invoke the telnet commands?  It seems to me that perhaps alt+leftshift
would make an acceptible combination for invoking the telnet commands
and would still allow redefinition of all alt-key combinations.

Thanks for help or hints.

***************************************************************************
*Rock Kent    rock@rancho.uucp        POB 8964, Rancho Santa Fe, CA. 92067*
***************************************************************************

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 91 19:06:08 GMT
From:      rob@disk.UUCP (Rob Miracle)
To:        comp.os.os2.misc,comp.protocols.tcp-ip
Subject:   Re: LM/X

In article <2576@slimer.UUCP>, mco@slimer.UUCP (Mark C. Otto) writes:
> In article <13285@asylum.SF.CA.US> sharon@asylum.SF.CA.US (Sharon Fisher) writes:
> >I'm working on a story for Unix World about LAN Manager/X, or LAN
> >Manager for Unix.  How many implementations of it are there?  Is
> >anybody actually using it?  I'd be interested in hearing from users or
> >vendors.  ... [rest deleted] ...
> 
> I use it every day.  I use LM/X (by Hewlett-Packard) on my HP 9000/375
[rest deleted]

Also, AT&T has a Unix based Lan Manager product called StarGROUP 3.3 and 3.4.
This version works fairly well, though I am still learning some of its
'features'.  They have support for Unix Servers and DOS, half an operating 
system (OS/2), and Macintosh (w/ 3.4).  

We are just migrating toward using it.  We have a "test" 3.3 server up.  We
are installing two LANs based on it now and have three more that will arrive
around the first of Feburary.  

By the By, I work for the University of Louisville, Computing &
Telecommunications Department in LAN support.  Our "news" has been down for a
while so I am posting it from here.

Rob Miracle

-- 
##   Rob Miracle     ## Call DISK (Multi-User Unix)   (502) 968-5401   1200-8N1
##   rob@disk.uucp   ## Available through Starlink!   Louisville, KY   24 Hours

"Egos are for those who need a mental crutch."  -- Anton Devious

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 91 19:52:27 GMT
From:      mpd@anomaly.SBS.COM (Michael P. Deignan)
To:        comp.protocols.tcp-ip
Subject:   Re: SCO TCP/IP copy protection

gd@aprm (Gary Dunn) writes:

>That SCO should build copy protection into their TCP/IP is an
>abomination.  PC users fought for years to rid commercial software of
>this pest, and won.

I believe that SCO's "copy protection" is nothing more than insuring that
multiple serialized copies do not talk to one another. IE: You can't
hook up two machines w/ the same serial number.

In case you didn't know, other vendors, like Novell, do the same thing.
Try hooking up two SFT 2.1+ fileservers and see what type of nasty
messages you get... /8^)

MD
-- 
--  Michael P. Deignan                      / They're not "bombs". 
--  Domain: mpd@anomaly.sbs.com            /  They're "gifts".
--    UUCP: ...!uunet!rayssd!anomaly!mpd  /   "Gifts From Above".
-- Telebit: +1 401 455 0347              /

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 91 08:22:42 GMT
From:      jhagen@arrester.caltech.edu (Jeffrey P. Hagen)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Problem w/ PC to Sun telnet


Our group has a PC clone with an Excelan EXOS 205T ethernet board installed, 
running Excelan EXOS 8051-01 rel. 3.2.3 TCP-IP software.  The system seems
to run correctly in that it will FTP to any type of host system; VAX, Sun,
etc.  However, in attempting to TELNET to a Sun system, one gets a "Connected
to..." message, but no login prompt.  We've tried connecting to all sorts of
combinations of VAX/UNIX and Sun/UNIX systems, and only the Sun/UNIX
combination refuses to offer a login prompt.  These same systems allow FTP
perfectly.  Again, we've tried Sun SPARCs, 386's, all with the same result.
If anyone could offer a suggestion, it would be most appreciated, as we seem
to run into a brick wall.  Feel free to post or e-mail as you see fit.  Thanks.


jhagen@arrester.caltech.edu
jhagen@jpl-pds.jpl.nasa.gov

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 91 16:16:58 GMT
From:      wilker@gauss.math.purdue.edu (Clarence Wilkerson)
To:        comp.protocols.tcp-ip
Subject:   Re: SCO TCP/IP copy protection


 SUN had some scheme like this for PC-NFS. It would seem
to me that the only legitimate gripe is how it screws
up the network.
.
Clarence Wilkerson

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 91 17:46:43 GMT
From:      jacob@gore.com (Jacob Gore)
To:        comp.protocols.tcp-ip
Subject:   Re: SCO TCP/IP copy protection

/ comp.protocols.tcp-ip / mpd@anomaly.SBS.COM (Michael P. Deignan)
/ Jan 26, 1991 /
>I believe that SCO's "copy protection" is nothing more than insuring that
>multiple serialized copies do not talk to one another. IE: You can't
>hook up two machines w/ the same serial number.

Which is still a pain in the neck for the legitimate user: if you have a
hundred machines, you need to keep a hundred sets of floppies for the times
when the software on one of the machines needs to restored, and then you
need to find the right set of floppies.

It is still copy protection in all its glory: make the life of your paying
customers miserable forever so that you can give a determined pirate a few
days of work before they crack it.

It is still crippleware.

It is still better to go to another vendor.

Jacob
--
Jacob Gore		Jacob@Gore.Com			boulder!gore!jacob

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 91 22:23:10 GMT
From:      rlg@BIOBIO.DESKTALK.COM (Richard L. Gralnik)
To:        comp.protocols.tcp-ip
Subject:   copy protection

Fellow networkers,

While I agree that copy protection can make life less than fun for an
administrator trying to make sure he/she restores the correct unique
set of floppies on a trashed machine, I don't understand why people 
feel the vendor has no right to protect their (usually considerable)
investment in product development from rip-off artists.  And note that
that term includes offices where everyone passes a copy around as much
as people who take the floppies home overnight to make one for their 
personal use.  

I'm not pointing fingers.  Probably everyone has done it at some time.
But the fact remains, if you didn't pay for it, and it isn't freebie
public domain software, then you stole it.  Trying to make the vendor
into the bad guy is a poor attempt at self-justification/rationalization.

If you want to live on share-ware go ahead, but to say that people 
should boycott a company that tries to keep you from making unauthorized 
copies of their software is like saying you shouldn't go to the 
supermarket because they prosecute shoplifters.

Richard
(rlg@desktalk.com)

p.s. Tops also implements a networked serial number comparison scheme.  

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 91 03:35:44 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: Want 8-bit/256 character clean TELNET session -- is it possible?


| From: quest!ssb@cs.umn.edu (Scott Sheldon Bertilson)
| Date: 26 Jan 91 04:30:47 CST (Sat)
| 
|   I haven't been following this discussion very well, but I sometimes
| fiddle with inter-machine UUCP connections where the client makes a raw
| TCP connection (typically directly from "uucico") to the "rlogin" port on
| the remote system.  If you begin your login sequence with 3 (or is it 4)
| null characters, "rlogind" can sometimes be fooled into assuming that you
| didn't send local username, remote username, or terminal/speed and hand
| you off to "login".  This is all I've had to do to get a clean enough
| connection that will allow "uucico" to run the "g" protocol
| successfully.  I have the impression that you might have to use TELNET,
| but thought I'd mention this for what it's worth.
| 
|   I just experimented a little more with this and am disappointed to have
| to say that a SunOS-4.1 and a SCO ODT system didn't like cooperate.  I
| get "rlogind: permission denied" when I send a null byte...can't figure
| out why it would say that.
| 
|   I also sometimes do "rlogin host -e -8" if I want to fiddle with
| something like SLIP when I'm dialed into a non-SLIP-capable host.

  Actually I should have included more information.  I want two things:

    1.	A fully transparent connection.

    2.	No other daemon other than my program on the other end of the
	connection.

The first condition is because my application requires an 8-bit clear
path.  The second condition is because if I either rlogin or telnet into
the remote machine and then start up my server, the remote server and the
rlogin or telnet daemons thrash when data is being transmitted or
received by the application server.  Every time the application server
transmits data, the CPU has to immediately context switch to the rlogin
or telnet daemon.  The same process happens for received data.  In
addition to the totally synchronized context switch thrashing which goes
on, the data is copied multiple times back and forth to the kernel.  This
has a significant impact on performance.

Casey

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 91 09:39:18 GMT
From:      martino@logitek.co.uk (Martin O'Nions)
To:        comp.os.os2.misc,comp.protocols.tcp-ip
Subject:   Re: LM/X

sharon@asylum.SF.CA.US (Sharon Fisher) writes:

>I'm working on a story for Unix World about LAN Manager/X, or LAN
>Manager for Unix.  How many implementations of it are there?  Is
>anybody actually using it?  I'd be interested in hearing from users or
>vendors.  For now, I'd like to ask people to email me or post, rather
>than call, because I don't have a firm assignment yet; I need to do a
>little research and then do a proposal.  Thanks...

So far as I am aware, there are a number of players committed to LM/X, but
rather fewer shipping. Hewlett-Packard have implementations for their 9000
series, and I believe for SCO Unix. SCO have pledged a native implementation
for Q191, and already ship the client side as part of their Open Desktop
system (LM/X is a part of the ODT spec.). Data General, Altos, and NCR have
all stated that they will have LM/X in their portfolio, but I have no info
as to when, although I understand that most implementations are planned to
appear this year.

For any one looking for a good reference on the LM/X system, I strongly
recommend reading chapter 8 of Unix Networking (Kochan & Wood - Hayden Books).
This goes into some depth on the history and structure of LM/X, including
a description of the ESMB structure. You also get discussions on UUCP, TCP/IP,
RFS, NFS, X, News and god knows what else, but that can be considered incidental

to this posting........

As to usage, whilst we don't actually use LM/X in the normal course of business,
we did test the SCO client against 3Com's Lan Manager. This used the 3Com
RFC NetBIOS protocol interface, as SCO don't yet ship NetBEUI/DLC support,
and it did work within certain limitations (we couldn't get it to run over
bridges, as there are no datagram forwarding or name service handlers with
either SCO or 3Com at this time - see RFC1001 for more details, or mail me
and I'll post a summary).

If other people have more info., PLEASE POST! I need more info too....

Martin

--
DISCLAIMER: All My Own Work (Unless stated otherwise)
--------------------------------------------------------------------------
Martin O'Nions            Logitek Group Support      martino@logitek.co.uk
--------------------------------------------------------------------------
         Down the drinking well / Which the plumber built her
             Aunt Mathilda fell / - We should buy a filter....
         (Harry Graham - Ruthless Rhymes for Heartless Homes)

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 91 10:28:22 GMT
From:      mni@techops.cray.com (Michael Nittmann)
To:        comp.protocols.tcp-ip
Subject:   NEWS WS Summary

I asked on the list about Sony NEWS_WS. I had one some days
on my desk for evaluation . 

My impressions:
Keyboard: that was a bad joke. I am not shure if that was the
keyboard that is going normally with the NEWS station. The
layout is absolutely weird, there is a "key" that sits at
the normal slash position that does not work at all (my right
pinky smashed against it every what so often). That needs
some time for getting used.
Screen: flat screen with what seems a convex image surface.
slight noise (probably due to long cable) good resolution.
Performance: about 7600 integer and 7900 floating dhrystones.
That is very very good.
Software (X,...): I saw no problems but did not do special
tcp/ip things (like own sockets , raw, nfs tests).
I did not test the kernel for the pipe type file in 
mounted FS bug. (most kernels will crash if you request a
pipe type file in a mounted FS , and that in a loop so that 
error messages are blocked out).

Following are replies on my query from the list (summarized as
is, headers taken out onl).

Thanks a lot for all that replied. I personally consider that
WS as a good deal, although in Europe the price is probably
much higher than in the US which does not make it a price
performance killer over here. 

Michael



------------ follows summary of replies ------------------


In article <9101211627.AA01428@techops.cray.com> you write:
>Hi netfolks,
>
>does anybody have interoperability experiences
>(good, flames, rubbish) for a
>
>	Sony NEWS Workstation?
>
>Please, mail to me to keep the list free, I promise I shall
>summary to the list end of next week.
>
>michael

I played with the Sony for a couple of weeks.  I was impressed by it.
It had all the trappings of a really good piece of Sony consumer
audio/video equipment.  We had a unit with only 4 MB of memory, so it
was sluggish at times while it paged stuff, but it was clear that more
memory would make the problem go away.

It does a very faithful implementation of 4.3 BSD which was nice to
see.  The NFS implementation looked like Sun's.  The Japanese language
support was fun to play with as well.

It doesn't look there's much commercial software out there for it, but if
you're writing your own, it should work on Suns and VAXen without too much
trouble..

We purchased two for AppleShare <-> NFS gateways.  They work pretty well.

-Jim
We have a couple of them on the network here.  They are not the worst
offenders, but they do have a couple of out-of-date features from what
I've observed.  I don't really have much recent experience (there're
only 2 out of hundreds of hosts, I usually don't pay much attention to
their activities), but if you really need some hard data, I could try
checking up on them.  It's also quite possible that the ones here are
running old versions of the software that have just not been upgraded
(they belong to the FSF as donations and I don't think the FSF really
has the volunteer manpower to really keep everything upgraded).

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

Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)
Please feel free to include summary information from the above, if you
want to quote me verbatim I would rather spend some time looking
through records rather than quoting off the top of my head.
In reference to your posting in comp.protocols.tcp-ip:

I have a Sony NeWS 1750, monochrome, 8M ram, 286M disk, .25" tape drive,
and 3.5" diskette.  The machine works great and is about 60% faster
than a comparable Sun 3/80.  I get about 7K dhrystones...

Anyways, I do have some minor complaints.  There are a few Japan-oriented
problems; specifically with the timezones, man pages, and fonts, but these
are easily fixed.  My biggest complaint is that the libc.a is missing
some juicy functions, but they are added easily.  Most notable is the
lack of quality resolver routines; currently they only use YP.  Of course,
BIND 4.8.3 is free and obtainable - I just haven't gottena round to it.

Other than that, I think the machine is a price/performance killer!

I strongly reccommend it.

Feel free to contact me if you have any further questions.
--
Bradley C. Spatz                                        Internet:  bcs@ufl.edu
Computer and Information Sciences                    UUCP:  uunet!uflorida!bcs
College of Engineering
University of Florida                  "School IS hell" -- Matt Groening
Yes, we do use several SONY workstations in our group.

In general, we are very happy with each model, but I'll give you
some tips...

We didn't have any serious problem with NFS or X11 they have
in their OS.  They have a newer OS called 4.0.  So, you should
try to use 4.0, if you're planning to use a system.


1. We have two NEWS-1750 (MC68030 model with a tape, etc.) with color
   monitors for last 2 years.  About 1.2 years later, 2 out of
   4 disks becames sick and couldn't use it...It was CDC Wren IV
   disk...  They said, they are not using these any more!

2. We have four NEWS-1720 (MC68030) model (US version) as our test
   target for ARTS1.0 and Real-Time Mach3.0.
   All of them came with a very nice big B/W display.  It has a Hitachi
   disk and we do not have any problem so far. (for 1.5 years)


3. We had one beta test machine of RISC-NEWS (R3000 with one I/O
   processor, MC68030) with a color monitor.
   It was VERY nice and we named it as "computeman".....
   After one year of testing, we sent it back to SONY and they did
   decided to sell only ONE CPU (R3000) model in US.

4. We just received two NEWS-3710 (US Model) from SMSC with 19inch
   B/W display.  We are waiting for Rel. 4.0 SONY OS tape...
   (I did use Rel. 4.0 in Japan and it was much nicer than the
   previous version.)

5. We have two SONY NEWS-Laptop (MC68030) as our demo target.
   We did give a demo of RT-Mach at USENIX Mach workshop using
   this one.  The screen has to be improved a lot...
   The 200MB internal disk is very nice... I used the Laptop
   at home a lot too.  But, it is too heavy to carry all the time.
   In US, I think, they will not sell this model.  Well, they
   will sell you R3000 version for US customers.



-- Hide Tokuda




  
 



    

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 91 10:29:22 GMT
From:      mni@techops.cray.com (Michael Nittmann)
To:        comp.protocols.tcp-ip
Subject:   INTERACTIVE UNIX Summary


Here my experiences with that Interactive UNIX product and a
summary of the list's replies to my query:

The installation of the product does not work as described.
The tcp/ip layer is unuseable:
 as was said in a network reply, I tried the following:
 two pings in the background to an unreachable destination.
  then: telnet localhost

Total block during login: sequence. No means to get the thing 
run again by the keyboard.

Thanks a lot for the replies! It saved me a lot of resources
that would have been invested in an unsuitable product.

michael



--------------------follow replies from list ---------------------



Hello Michael !

In comp.protocols.tcp-ip you write:
>question: does anybody have experiences with the following
>TCP/IP side of product:
>	Interactive UNIX	for 368 PCs (and 468),
>by Danet?

Just a few words: the TCP/IP that comes with ISC 2.2 seems to be fairly
well, BUT:
- sometimes closed or aborted TCP/IP connections remain in CLOSED state
  and never vanish completly (a reboot is necessary, to clear things up).
- a '/etc/ping' done from the consol or some vt?? can lock up the
  complete TCP/IP driver. I.e. not more connections possible, neither
  out of the machine nor into the machine. A reboot is neccessary then.
- NFS is not very usable (at least for me). I did some test with a
  Sun4c as the NFS-server (i.e. mounted filesystem from the sun
  at the PC-386). The performance is VERY BAD, I measured around 30 KB/sec
  on an 25 MHz '386. NFS tends to lockup when used heavly (I tested with
  more then 5 simultanious copies from the NFS mounted filesystem)
  although the locks vanish after some time.

After all: TCP/IP is usable. It highly depends on the usage. It seems
not to be 100 % error free, so expect quirks when used heavy.

  Joerg Lehners
-- 
Mail: Joerg.Lehners@arbi.Informatik.Uni-Oldenburg.DE
Path: ...!uunet!unido!uniol!lehners   Inhouse-Mail: aragorn!joerg
Real: Joerg Lehners, FB 10 Informatik ARBI, Uni Oldenburg, D-2900 Oldenburg
In reply to your message of Tue, 22 Jan 91 08:55:19 -0600
-------

If you get any reports, I would really like to get a copy.  The only real
interoperability problem I've seen is that the telnet daemon in TCP/IP 1.2
doesn't negotiate the X-DISPLAY-LOCATION option correctly.  It can be
disabled and things work (disable is documented in the telnetd man page).

Since nearly all the code originated with 4.3 and 4.3-Tahoe, there shouldn't
be too many problems but we would like to know if you hear of any.

Thanks,
Doug McCallum
Interactive Systems Corp.
dougm@ico.isc.com

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 91 13:37:27 GMT
From:      bob@astph.UUCP (Robert Ford)
To:        comp.unix.sysv386,comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.misc
Subject:   Terminal Servers and Concentrators


We are currently using multiport serial boards from Comtrol and Equinox
to serve terminals (mostly Televideo 950s) to 386-based UNIX machines
running ISC 2.2 UNIX.  The UNIX boxes are interconnected via ethernet,
running TCP/IP.

For the most part, we have been satisfied with the intelligent multiport
serial cards, especially with their low cost per port (about $50/port for 
16 ports).  However, we have experienced some board failures recently that
have undermined our confidence in their reliability.  Also, we are 
concerned about the number of slots they consume if we want to attach
64 terminals to one box (not to mention the extra cpu load).  

We are currently doing some research on ethernet terminal servers, multi-
plexers, and asynch terminal concentrators.  We are wide open in terms
of directions to move, but obviously want to find the solution that 
provides the best performance, reliability, and flexibility at the lowest
possible cost.  We have been somewhat dismayed to find the the cost of
an ethernet terminal server is 2-3 times as expensive per port as a 
multiport serial board solution.  The asych terminal concentrators seem
almost as expensive.

So, we could use some guidance.

1.  What are the pros and cons of each alternative?
2.  With each solution, what would bear the most load (cpu, network, etc.)?
3.  Which manufacturers are the best and most reliable?
4.  Any comment on whether we should go with stand-alone or
    chassis-based servers/concentrators?
5.  Does anyone know of a terminal server that will give us <$100/port?

Thanks for your help.

Bob Ford
-- 
Bob Ford                           (814) 234-8592x36
INTERNET: astph!bob@attmail.com     UUCP: attmail.com!astph!bob
Philadelphia Phillies

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 91 13:38:33 GMT
From:      mckenzie@bbn.com (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re: (none)

Those who objected to the "MarketPlace: Households" product should
applaud Lotus for making a good decision, regardless of whether it would
have been made without direct expression of concern from the general
public.

Remember, though, that what Lotus was planning to do was apparently
legal.   Rather than waiting for some other company, perhaps less
concerned about public sentiment, to offer a similar product, let me
suggest that you now write your Congresspersons stating what you found
objectionable about the project and asking that it be made illegal.
This will undoubtedly require some careful thought to avoid a "cure"
worse than the "disease".

Alex McKenzie
 

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 91 15:26:00 GMT
From:      mlm@uplxts1.UUCP
To:        comp.protocols.tcp-ip
Subject:   (none)

Administrator, 

Please remove me from the following Mailing list:

   tcp-ip


Thank You,

Michael Marshall

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 91 17:13:07 GMT
From:      cnolan@mee.tcd.ie
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   SUMMARY: NETWATCH with packet drivers.

My original posting concerned problems I was having creating NETWATCH from the
PCIP sources for use with packet drivers.  Because of the number of people who 
mailed me directly I'll summarize the findings here.

(A few replied with the same problem, so I wasn't alone.)

The answer is that it can be done. The archive at netlab.usu.edu in directory
[anonymous.netwatch], (N.B. VMS), has a compiled version for packet drivers.
It is maintained by one Joe Doupnik.  This is numbered Version 9.6.  Thanks to
ronald@robobar.co.uk for that.

There is also a compiled PCIP package at funic.funet.fi in directory
pub/msdos/pcip.  Thanks to dahlstr@hus.chalmers.se (and others) for that.

Because of delays in getting stuff by BITFTP I have only had a quick look at
NETWATCH from USU but it seems to work.  We are using D-Link DE-100 cards.

My thanks to all who took their time to assist me.  Once again the net to the
rescue.

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

             
       	 	Conor Nolan			Phone:	772941 (X1741)
           	Snr. Technician			Fax:	772442
            	Microelectronics Dept.
		Trinity College			
	      	Dublin 2			cnolan@mee.tcd.ie
  	     	IRELAND			
            

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

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 91 21:02:24 GMT
From:      kent@tfd.COM (Kent Hauser)
To:        comp.protocols.tcp-ip
Subject:   Wanted: Recommendations for thin-net tranceivers


Could someone recommend a vendor & supplier?

We're getting some Sun SLCs & Sparcstations, and need to connect them
to our older machines (with builtin thin-net).

Responses by email please.

Thanks.
	Kent

-- 
Kent Hauser			UUCP: {uunet,sundc,uupsi}!tfd!kent
Twenty-First Designs		INET: kent@tfd.com
(202) 408-0841	

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 02:36:34 GMT
From:      mckimg@bronze.ucs.indiana.edu (Geoffrey McKim)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject:   Re: Xircom has worst performance in PC Magazine tests

In article <1991Jan24.003038.2853452@locus.com> dana@locus.com (Dana H. Myers) writes:
>In article <NELSON.91Jan21132425@sun.clarkson.edu> nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) writes:
>>The Xircom Pocket LAN Adapter had the worst performance of three pocket
>>lan adapters in a PC Magazine review, published in the February 12, 1991
>>issue.
>>
>>	Adapter		mbps
>>	p.LAN		1.1
>>	D-Link		1.07
>>	Xircom		0.95
>>
>>Please don't buy Xircom products.  They used some of my software in
>>violation of its copyright.  Write for details...
>
>  While Russ may have a beef with Xircom over software copyright,
>the performance of the Xircom adapter is within 85% of the best in this
>comparison. I wouldn't call this bad performance.
>

First of all, Russ said that it had the "worst" performance, which indeed
is a true statement, no matter how you look at it.  Second of all, I 
hope that most of us will hold solidarity with Russ on this one -- there 
are countless of us out here who are grateful for his packet drivers, and 
wouldn't consider buying from a company that violated his generous 
copyrights.

=========================================================================
Geoffrey W. McKim			Internet: mckimg@ucs.indiana.edu
UCS Networks/LAN Group			BITNET: mckimg@iuamber
Indiana University Bloomington
855-4643
=========================================================================

-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 03:50:47 GMT
From:      jmaynard@thesis1.hsch.utexas.edu (Jay Maynard)
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection

*** BOGUS ANALOGY ALERT ***

In article <9101272223.AA08327@desktalk.com> rlg@BIOBIO.DESKTALK.COM (Richard L. Gralnik) writes:
>If you want to live on share-ware go ahead, but to say that people
>should boycott a company that tries to keep you from making unauthorized
>copies of their software is like saying you shouldn't go to the
>supermarket because they prosecute shoplifters.

Bzzt. Sorry, but you blew it.

Saying that people should boycott a company that uses copy protection is like
saying that you should change supermarkets when the one you're in attaches
bowling balls to the TV dinners to keep you from shoplifting them.

>p.s. Tops also implements a networked serial number comparison scheme.

Thanks for passing that along. Yet another product to avoid.

-- 
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
jmaynard@thesis1.hsch.utexas.edu  | adequately be explained by stupidity.
"Today is different from yesterday." -- State Department spokesman Margaret
Tutwiler, 17 Jan 91, explaining why they won't negotiate with Saddam Hussein

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 08:48:21 GMT
From:      ronald@robobar.co.uk (Ronald S H Khoo)
To:        comp.protocols.tcp-ip
Subject:   Re: SCO TCP/IP copy protection

jacob@gore.com (Jacob Gore) writes:

> Which is still a pain in the neck for the legitimate user: if you have a
> hundred machines, you need to keep a hundred sets of floppies

No, the floppies are identical.  The only thing you have to do is
to 
	# /etc/brand <unique_serial_number> <unique_password> /etc/slink

to each machine after copying the floppies (or tape).  Still a pain though...
I got a long list of the equivalent serial_number/password pairs
for our client sites' OS's on the wall in the room next door.

> It is still copy protection in all its glory: make the life of your paying
> customers miserable forever so that you can give a determined pirate a few
> days of work before they crack it.

This remains true. 

> It is still crippleware.

Well, maybe slightly limping :-)

-- 
Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 09:04:38 GMT
From:      jgd@Dixie.Com (John G. DeArmond)
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection

rlg@BIOBIO.DESKTALK.COM (Richard L. Gralnik) writes:

>Fellow networkers,
 
>While I agree that copy protection can make life less than fun for an
>administrator trying to make sure he/she restores the correct unique
>set of floppies on a trashed machine, I don't understand why people 
>feel the vendor has no right to protect their (usually considerable)
>investment in product development from rip-off artists.  And note that
>that term includes offices where everyone passes a copy around as much
>as people who take the floppies home overnight to make one for their 
>personal use.  
 
>If you want to live on share-ware go ahead, but to say that people 
>should boycott a company that tries to keep you from making unauthorized 
>copies of their software is like saying you shouldn't go to the 
>supermarket because they prosecute shoplifters.

NO!!  This is like saying that the supermarket prosecutes every customer
because they have a paranoia based on an imagined but not detected thief.

As the owner of a small software and (real soon to be) hardware company,
I gotta comment.  On my soapbox.

The reason copy protection of any kind is obscene is that it is merely a
symptom of an attitude disease in the vendor company.  Instead of viewing
the customer as the source of his wealth and cultivating him accordingly,
the vendor views the customer as simply a source of money who is to be
milked to the extent possible.  Ever notice how copy protection-using
vendors talk about those evil pirates with the same disgusted tone
reserved  for cheating spouses, child rapers and politicians?   It has 
nothing to do with a few disks being passed around.

Wealth in a business context means far more than the money collected on a
sale.  Business wealth means sales revenues, customer good will, word-of
mouth advertising, followon sales, upgrade and new product purchases,
customer understanding when bugs and/or bad features are found (which may
mean the difference between a polite phone call to customer support and a
massive flamage to this net and/or every magazine they can address a
letter to,) tolerance of corporate mistakes by regulators, and (close to
the hearts of the protectionists) customer reporting  of flagrant
copyright or contract violations. 

It really is an attitude problem on the part of the vendor.  I look upon
incidental copying (which I define as the insignificant copying to take 
home, to give to a friend or similiar activity.) as absolutely free
advertising.  If I offer good customer support, fair pricing, and a
decent upgrade policy, so-called "incidental pirates" will either grow
bored with the program or will buy a package in order to get all the 
above benefits.  And if they don't buy?  Well, I've not really lost 
anything because that person probably would not have bought in any
event and it is not like he had reached in my pocket and taken money
out.   I simply failed to sell this person.

I do, of course, have serious problems with real piracy, such
as corporate copying or pirate resellers or bulk give-aways.  But we have 
more than adequate legal remedies to address these problems.  If I treat
my customers as collegues and trusted friends instead of money pits, it
is likely that one of them will call and report large scale piracy.  After
all, it is in all our benefits that we all stay around over the long term.

Didya ever notice that there is usually an inverse relationship between
the quality of software and the degree of copy protection.  Some of the
absolutely worst software I've ever used (EE Designer) was a heavily
protected CAD package.  This package was written in MS BASIC,  for
christsake.  Yet the graphics device driver which contains the  copy
protection code employs a multitasker to allow the copy protection dongle
to be checked in real time (couldn't have a *paying customer* start the
program and then *gasp* switch the dongle to another machine so that work
could continue while the first PC drives a plotter for 6 hours.) 
Conversely, some of the best software (OrCad, WordPerfect) have
absolutely no protection.  Indeed, WordPerfect will take a support call
on their 800 number from so-called pirates. 

The original source of this thread, SCO Unix is a classic example.  Their
Unix implementation is IHMO a piece of shit.  Not only is it buggy in
general, the copy protection locks up the machine if it thinks it
discoverd a *GASP* pirate.  No warnings, no controlled shutdown, just a
lockup.  It's the company's Deputy Dipshit instinct revealing itself. 
While SCO is huddling in  their hovels in an emotional corporate crisis,
companies like IBM who DO understand customers (and coincidently how to
make money from them) are giving RS/6000s with nary a sign of copy
protection (yet, at least) to potential customers.  Wonder whether there
are now more AIX or SCO Unix application platforms out there now?   I 
have one client who is a MAJOR SCO VAR and reseller drop SCO and go with
AIX because  of this crap.  I wonder how many more customers are out
there?  Is the small system Unix market going to hand the market to IBM?
Looks like..

Here are some keys to "protecting your development investments" by 
keeping customers happy:

*	Provide a good product at a fair price.  If you have a $50 product
	that you are trying to sell for $500, then don't be surprised that
	copying goes on.  Exhibit A:  Lotus 123.  If you think you have a
	product worth thousands, then prove it to your customers. If you
	REALLY think that copying is a threat, have the customer sign
	a contract before delivering the product.  

*	Provide plenty of easy to use technical support.  Sure, users are
	dorks but they are also the ones who pay your salary and who 
	can either give you tremendous free advertising or more bad press
	than you can ever overcome.

*	Provide free bug fixes and provide free upgrades to those who report bugs.
	After all, the bug is your f*ckup, not the customer's.

*	Provide real value for the money in upgrades.  Don't call bugfix releases
	upgrades in order to charge for them.  Telebit is one of the worst 
	companies in this regard.   $150 for bugfixs. Jeez!  Of course,
	they increment the major version number to make it look like an upgrade.

*   If you sell a shrink-wrapped product, put in a copyright statement that
	won't make customers laugh as they throw it in the garbage.  You can
	do much worse than to copy Boreland's copyright statement.  Oh, and 
	do not make it worse by calling it a "license agreement".

*	Provide a way for your potential customers to "try before you buy".
	Incidental copying is a very legitimate way to do this, as is shareware.
	Orcad takes a different and inovative approach.  Call an Orcad sales
	office and ask for a demo product.  What you will get is a fully 
	functional version of the product but with a dongle.  Use it as
	long as you wish.  When you buy, you get an unprotected version.

Customer Service will make or break your product.  You'd damn well better
plan for it as an integral feature of your product, fully as important
as the software not crashing.  Here's an example of how to and how not to
do customer support.  I have used 2 brands of intelligent async cards in
Unix systems for my customers.  One brand is Comtrol and the other is 
Stargate.  I no longer use Stargate because of customer support.

When I opened the first Comtrol box, the first thing I saw was a plastic gold 
card just like a credit card.  On this card was printed the 800 toll free 
support number AND the names and direct dial numbers for the General Manager, 
the Engineering Manager, the Hardware Tech Support manager, the Software
Tech Support manager, the Production manager, the Marketing manager and
the Sales manager.  Above this list of numbers is this statement:

	"Our committment to you doesn't stop with our products.  We give 
	you the support and the extra service you want.  IT's because your
	satisfaction is our #1 priority.  COMTROL is only a phone call away.
	You have full access to all COMTROL personnel.  For your convenience,
	primary department contacts are listed below:"

I've had one occasion to use the support number.  A board arrived one
evening DOA.  I called just at closing time.  COMTROL had someone drive
a board down to Delta DASH and I got it in a few hours.  They told me
to return the DOA one when convenient and not to worry about shipping
back the (very good) documentation.

My Stargate experience was a bit different.  I inherited my first card 
in some surplus stock I bought.  The card uses address decode PALs that
are specific for each OS.  My card was equipped for Xenix and I  needed a
PAL for ISC Unix.  I called up Stargate and reached a rather sullen tech
support technician.  I was told that a new PAL cost $150!!! I passed on
the PAL and obtained one from a friend but ordered a  driver disk for
ISC.  When it got here, it was accompanied by some Nth-generation xeroxed
dot-matrix printed documentation that was practically unreadable and it
would not install.  It did not meet the specifications of ISC's
installpkg facility.  I copied the disk onto the system and installed it
manually. 

Later, I needed to get an upgraded driver for a new version of the OS.  
I called Stargate for the upgrade, somewhat expecting to pay for it.
I was told that I would either have to write (!) to the sales department
who would investigate me as a customer and if I passed, would give me
the secret password to their BBS where I could download the upgrade.
Or I could write and include some money and get a disk.  Write a letter
in order to access a BBS indeed!  Could they have been afraid that I 
had wirewrapped a board in my basement and wanted to steal the driver 
to make it work?  Who knows.

Now both boards work pretty well equally.  But I'll never fool with 
Stargate again while I recommend COMTROL whenever the opportunity arises.
The difference is service.  I perceived a better value from COMTROL even
though it cost more.

I firmly believe that if companies would get their heads out of where the
sun never shines and focus the energy they put into copy protection into
product quality, so-called piracy would cease to be an issue and their
profits would soar.  As my company grows, I'm going to do the best of my
ability to prove this theory correct yet again.

John

-- 
John De Armond, WD4OQC        | "Purveyors of speed to the Trade"  (tm)
Rapid Deployment System, Inc. |  Home of the Nidgets (tm)
Marietta, Ga                  | 
{emory,uunet}!rsiatl!jgd      |"Politically InCorrect.. And damn proud of it  

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 09:44:35 GMT
From:      ljm@TWG.COM
To:        comp.protocols.tcp-ip
Subject:   Network meltdown (was: SCO TCP/IP copy protection)

>
>>That SCO should build copy protection into their TCP/IP is an
>>abomination.  PC users fought for years to rid commercial software of
>>this pest, and won.
>
 
>...SUN had some scheme like this for PC-NFS. It would seem
>to me that the only legitimate gripe is how it screws
>up the network....

and

>
>...In case you didn't know, other vendors, like Novell, do the same thing.
>Try hooking up two SFT 2.1+ fileservers and see what type of nasty
>messages you get... /8^)...
>

Indeed.  For networks of any size, broadcast based protection schemes are
a disaster.  Either, the network is segregated and the copy protection
packets don't reach the other nodes or the network is flat and every copy
protection packets reaches every other node perhaps melting down the entire
network.  In neither case does the vendor's efforts produce the result
originally intended.

enjoy,
leo j mclaughlin
ljm@twg.com

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 12:27:54 GMT
From:      girard@kestrel.my.bull.fr (Francois Girard)
To:        comp.protocols.tcp-ip
Subject:   Re: LMX


sharon@asylum.SF.CA.US (Sharon Fisher) writes:

>I'm working on a story for Unix World about LAN Manager/X, or LAN
>Manager for Unix.  How many implementations of it are there?  Is
>anybody actually using it?  I'd be interested in hearing from users or
>vendors.  For now, I'd like to ask people to email me or post, rather
>than call, because I don't have a firm assignment yet; I need to do a
>little research and then do a proposal.  Thanks...

The french society BULL have implementations of a NETBIOS-X
and LMX for its UNIX server (DPX 2200 and DPX 2300 series).
The name of this package is "OpenTeam".

F.G.

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 14:55:16 GMT
From:      lisa@netwrx1.NW1.COM (Lisa C. Ingrassia)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   MIT SNMP on SCO 3.2.2 UNIX platform

I have recently downloaded the MIT SNMP Development kit code 
(Oct 90 version) from the allspice.lcs.mit.edu host.  
I want to port it to the SCO Unix 3.2.2 platform. However, it
refers to many include files that SCO Unix does not support
(e.g., machparam.h).

Has anyone already ported this code to the SCO Unix platform who will
share the changes made to run with SCO's include file & library
structure?

Thanks.

==============================================================================
  Lisa Ingrassia		Usenet:	  uunet!netwrx1!lisa
  Open Networks, Inc. 		Internet: lisa%netwrx1@uunet.uu.net
  11490 Commerce Park Drive	          lisa@netwrx1.nw1.com  
  Suite 205			FAX:      (703) 648-0016
  Reston, Virginia 22091	Voice:    (703) 648-0013

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 14:59:26 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection

Has this strayed far enough from TCP/IP yet?

-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 15:53:17 GMT
From:      litwin@ROBOTICS.JPL.NASA.GOV (Todd Litwin)
To:        comp.protocols.tcp-ip
Subject:   Monitoring TCP/IP sockets

I have a program that uses TCP/IP sockets and needs to know quickly, within a
second or so, if the physical connection between the two systems is broken. It
appears that the operating system is very tolerant of physical disruptions, and
won't timeout the connection and formally break it even if the problem lasts
several minutes. I'm using setsockopt() to turn on SO_KEEPALIVE, but this
doesn't help, either. Is there any way that I can force a socket to disconnect
after a second or so of failure to communicate (short of sending my own
heartbeats)? I am running under Sun OS 4.0.2, but also will need to move a
version of this software to the Silicon Graphics world, and to the VxWorks
real-time operating system. Any suggestions would be greatly appreciated.

 		Todd Litwin
 		Jet Propulsion Laboratory
 		(818) 354-5028
 		litwin@robotics.jpl.nasa.gov

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 16:27:42 GMT
From:      rjc@comlab3.gatech.edu (Russell J. Clark)
To:        comp.protocols.tcp-ip
Subject:   IP Multicast Support

Subject: IP Multicast Support

Can anyone give me some information on the status of IP Multicast Support
in the TCP/IP community. I've read the various RFC's up through August 1989
by Steve Deering. I've also spent some time implementing some lower
level multicast support on a Sparcstation and Sun OS 4.1.

I'm interested in hearing about implementations, both commercial and 
educational. I'm particularly interested in addressing the issues with
routing of multicast packets.

Thanks in advance for any responses!

----------
Russ Clark
College of Computing - Georgia Tech, Atlanta, GA 30332-0280
UUCP: !{decvax,hplabs,ncar,purdue,rutgers} !gatech!cc!rjc
Internet: rjc@cc.gatech.edu

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 16:47:14 GMT
From:      JAFFE@SSCVX1.SSC.GOV
To:        comp.protocols.tcp-ip
Subject:   In search of T2 multiplexer sources....


I am searching for sources of T2 multiplexing equipment and would appreciate any
assistance the net could provide in my thus far fruitless pursuit.  I am 
convinced that someone must make this stuff which I need to interface between
existing T2 devices and the multiple T1's which it can be broken down into.
Thanks in advance!

Mike Jaffe
SSC Laboratory


jaffe@sscvx1.ssc.gov  

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 16:51:25 GMT
From:      jacob@gore.com (Jacob Gore)
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection

/ comp.protocols.tcp-ip / rlg@BIOBIO.DESKTALK.COM (Richard L. Gralnik)
/ Jan 27, 1991 /
>While I agree that copy protection can make life less than fun for an
>administrator trying to make sure he/she restores the correct unique
>set of floppies on a trashed machine, I don't understand why people 
>feel the vendor has no right to protect their (usually considerable)
>investment in product development from rip-off artists.

Of course they have that right.  But I'm under no obligation to buy from
them, am I?

>the fact remains, if you didn't pay for it, and it isn't freebie
>public domain software, then you stole it.  Trying to make the vendor
>into the bad guy is a poor attempt at self-justification/rationalization.

I don't like the vendor making me into the bad guy after I do pay for his
software according to his terms.  That's why I don't buy copy-protected
products.

>If you want to live on share-ware go ahead, but to say that people 
>should boycott a company that tries to keep you from making unauthorized 
>copies of their software...

I don't boycott the company, I only avoid copy-protected products.  When I
boycott a company, I buy nothing from them, use nothing from them, and try
not to promote them or their products in any way.  Avoiding bad products is
not boycotting.

>...is like saying you shouldn't go to the 
>supermarket because they prosecute shoplifters.

No, it's like saying you shouldn't go to a supermarket that strip-searches
all of its customers.  (Unless you're into that kind of stuff...)

Jacob
--
Jacob Gore		Jacob@Gore.Com			boulder!gore!jacob

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 18:30:47 GMT
From:      eric@picard.sbi.com (Eric Ho)
To:        comp.protocols.tcp-ip,mail.list.sun-managers,cs.works.sun
Subject:   slip auto-dialout & where to get ?


Does anyone out there know where I can get a working copy of SLIP (a full copy
though, not just the slip drivers) for my SLC (under Sunos 4.1) and Telebit
T2500 ?

ALso, any install info would be much appreciated.  I also want to see if
anyone has written anything to make SLIP auto-config the T2500 and dialout ?

Any pointers/info would be much appreciated.
--

==========================================
+ Eric Ho                          Email: eric@sbi.com
+ Salomon Brothers, Inc.  [SISS]   Phone: (212) 855-3003
==========================================

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 18:43:38 GMT
From:      xxmartn@lims03.lerc.nasa.gov
To:        comp.protocols.tcp-ip
Subject:   RE: MacTelnet Solutions


Intercon Systems makes a VT52, VT102, VT240, Tektronics 4014, VT 3278 (mod 
2-5) emulator called TCP/CONNECT II. All the emulations are built into this 
package.  It supports TCP/IP and MacTCP.

NOTE: The developer who originally wrote NCSA TELNET (Gaige Paulsen) 
started this company. TCP/CONNECT II is essentially NCSA Telnet but with 
alot more options and alot more features.

Intercon Systems can be reached at (703) 709-9890.

-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 19:43:30 GMT
From:      don@nic.the.net (Donald L. Nash)
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection

In article <4605@lib.tmc.edu>, jmaynard@thesis1.hsch.utexas.edu (Jay
Maynard) writes:
>>p.s. Tops also implements a networked serial number comparison
>scheme.
>
>Thanks for passing that along. Yet another product to avoid.

The copy protection scheme used by Tops is very inobtrusive.  It uses
AppleTalk Name Binding protocol to register its serial number as a named
entity on the network.  NBP automatically makes sure that there is no
other identical name in the same AppleTalk zone (duplicate names in the
same zone are not allowed).  If the NBP RegisterName operation fails,
then this means someone else is using a copy of Tops with your serial
number, so Tops refuses to run.   I wouldn't exactly call this
"attach[ing] bowling balls to the TV dinners to keep you from
shoplifting them."  This is more like those magnetic targets which
clothing stores use to trip their alarm systems when someone trys to
take a piece of clothing out the door without having the target removed
by the cashier.  They don't get in the way if you are honest, since the
cashier removes the target when you pay for the clothes.  But they do
keep you from being dishonest.

BTW, for those of you not familiar with NBP, it does use broadcasts to
perform name lookups.  So when you register a name, you cause a
broadcast to occur when NBP looks up your name first to verify its
uniqueness.  However, if you are using AppleTalk already then you are
already living with NBP broadcasts.  They are just something that
happens when you use AppleTalk.  As far as Tops is concerned, it only
causes broadcasts when it starts up and registers its name.  To my
knowledge, it does not periodically poll to see if someone else is using
its serial number, which is in contrast to what the SCO/Lachman cpd
program does.  I wouldn't use the Lachman stuff if it continually
broadcasts like that.  I have no problem using Tops, since it does not
contribute unnecessarily to network traffic and since it does not
prevent me from making backup copies of  my disk.  And since I'm honest
and pay for my software, it doesn't prevent me from getting my work
done.

				Donald L. Nash

				The University of Texas System
				Office of Telecommunication Services

Internet:  D.Nash@utexas.edu
THEnet:    THENIC::DON
BITNET:    DON@THENIC
PSI Mail:  311051200131::DON

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 20:20:35 GMT
From:      hmiller@helios.lerc.nasa.gov (Harvey Miller (SVER))
To:        comp.protocols.tcp-ip
Subject:   Server Access


     I hope I am asking the right group of readers.

How does one access different servers in order to access all news groups?
We are using a Vax cluster that uses a program called "VNEWS".  Any helpfull
suggestions would be appreciated.  Please email the responses.

Thanks in advance.

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 20:33:24 GMT
From:      jonson@SERVER.AF.MIL (Lt. Matt Jonson)
To:        comp.protocols.tcp-ip
Subject:   Lan Computing Article on OSPF


Spotted in Lan Computing newsweekly front page article:

"A number of vendors are starting to implement and test the protocol
[OSPF], which will eventually replace the Routing Information Protocol
(RIP).  RIP was the first dynamic routing protocol for TCP/IP networks."

Hmmm...And I thought OSPF was so much more than just a replacement for
RIP - ;-) - and gee, what were we routing with before RFC 1058...?a

/matt
-- 

Lt Matthew W Jonson 	 jonson@server.af.mil	snail-mail:
Network Systems Engineer     205-279-4075	SSC/SSMT
USAF DDN Program Office	     AV: 446-4075	Gunter AFB, AL 36114

-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 20:51:55 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Monitoring TCP/IP sockets

You can't always tell within a second or two whether the physical
connection between two systems is broken. Sometimes the break is a
router crashing. Sometimes it's an AT&T fiberoptic cable cut by a
backhoe in upstate New York when you're in Dallas and the computer
you're talking to is in San Francisco. Most applications want to be
tolerant of order-of-several-minutes disruption of communications,
because there are too many real world transient conditions that aren't
readily distinguishable from long term failures.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	FAX: 415 594-1141

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 22:11:49 GMT
From:      brian@amc-gw.amc.com (Brian Crowley)
To:        comp.protocols.tcp-ip
Subject:   IP Header Checksum Calculation



I wonder if someone can't give me some pointers on what I feel should
be a simple operation, but one that I just can't seem to get a handle on.

I am building an IP packet for transmission over an Ethernet Network.
No problem building the packet, big problems getting the IP header
checksum to come out correctly!

According to the RFC in front of me, the IP header checksum is
calculated by treating the IP header as a sequence of 16-bit values,
which are added together using one's complement arithmetic, and then
the one's complement of the result is used as the checksum.

To test my algorithm, I pulled some IP packets off our local network and 
ran the IP headers through.  Alas, the results of my program do not 
match the checksums stored in the packets!

Would some kind soul please send me their algorithm to accomplish this
feat?  A "C" code fragment, a written algorithm, any help you can give
would be appreciated.

---------------------------------------------------------------------------
|Brian Crowley              |          DNS: brian@amc.com                 |
|Applied Microsystems Corp. |         UUCP: uunet!amc-gw!brian            |
|Redmond, WA                |          ATT: 206-882-2000  Ext. 328        |
 ---------------------------------------------------------------------------

-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 22:46:50 GMT
From:      kseshadr@quasar.intel.com (Kishore Seshadri)
To:        comp.protocols.tcp-ip
Subject:   Perl or shell scripts for NFSWATCH 3.0?

davy@erg.sri.com writes:
 > 
 > NFSWATCH Version 3.0 is now available for anonymous FTP from the host
 > 
 > 	ftp.erg.sri.com		(128.18.4.39)
 > 

I'm interested in representing some of this data graphically. 
Are there any perl or shell scripts that parse log files generated
by nfswatch and generate input files for plot, xgraph or gnuplot?

Email your responses and if there's sufficient interest, I'll
summarize and post.

Kishore Seshadri
-----------------------------------------------------------------------------
Kishore Seshadri,(speaking for myself)       <kseshadr@mipos3.intel.com>
Intel Corporation                            <..!intelca!mipos3!kseshadr>
Plus ca change, plus c'est la meme chose.

-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 23:23:26 GMT
From:      mpd@anomaly.SBS.COM (Michael P. Deignan)
To:        comp.protocols.tcp-ip
Subject:   Re: SCO TCP/IP copy protection

jacob@gore.com (Jacob Gore) writes:

>Which is still a pain in the neck for the legitimate user: if you have a
>hundred machines, you need to keep a hundred sets of floppies for the times
>when the software on one of the machines needs to restored, and then you
>need to find the right set of floppies.

Only one set of floppies, with multiple serialization numbers and 
activation keys, would be necessary.

>It is still copy protection in all its glory: make the life of your paying
>customers miserable forever so that you can give a determined pirate a few
>days of work before they crack it.

The added 5 seconds of "misery" is certainly nothing that most people cannot
deal with.

>It is still crippleware.

I wouldn't classify it as "crippleware". 

>It is still better to go to another vendor.

Spoken like the true "want something for nothing" trooper.

MD
-- 
--  Michael P. Deignan                      / They're not "bombs". 
--  Domain: mpd@anomaly.sbs.com            /  They're "gifts".
--    UUCP: ...!uunet!rayssd!anomaly!mpd  /   "Gifts From Above".
-- Telebit: +1 401 455 0347              /

-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 91 23:51:45 GMT
From:      davy@ERG.SRI.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Perl or shell scripts for NFSWATCH 3.0?


     From:  kseshadr@quasar.intel.com (Kishore Seshadri)
     Date:  Tue, 29 Jan 91 15:46:50 PDT
     Subject:  Perl or shell scripts for NFSWATCH 3.0?

     
     davy@erg.sri.com writes:
      > 
      > NFSWATCH Version 3.0 is now available for anonymous FTP from the host
      > 
      > 	ftp.erg.sri.com		(128.18.4.39)
      > 
     
     I'm interested in representing some of this data graphically. 
     Are there any perl or shell scripts that parse log files generated
     by nfswatch and generate input files for plot, xgraph or gnuplot?
     
     Email your responses and if there's sufficient interest, I'll
     summarize and post.
     
While we're at it, if you'll send them to me with some documentation,
I'll include them in the next release of NFSwatch as "auxilliary"
software or some such.

Personally, I think input to plot or gnuplot would be more useful than
xgraph, since many people are still stuck with SunView or other gross
things.

--Dave

-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 00:57:12 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Monitoring TCP/IP sockets


    I have a program that uses TCP/IP sockets and needs to know quickly,
    within a second or so, if the physical connection between the two
    systems is broken.

Foo.  tcp/ip is designed for reliability over many media.  You have no
guarantee that your packet will even get to its destination within a
second, even if the network is working perfectly.

If you really need to know that quickly whether the network has gone
away, tcp/ip is not a suitable protocol to be using.

BillW
-------

-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 01:47:28 GMT
From:      boyter@bimbo.uucp (Maj Brian Boyter)
To:        comp.protocols.tcp-ip
Subject:   Re: in.routed

kcpeng%ccsun1.csie.nctu.edu.tw@CUNYVM.CUNY.EDU writes:
>  Then I ping a host in domain edu.tw:
>    % ping nthu
>      sendto: Network is unreachable
>  Then I kill the routing daemon in.routed and restart it, and
>    % ping nthu
>      nthu.edu.tw is alive
>  After one or two minutes (indeed !), I do it again:
>    % ping nthu
>      sendto: Network is unreachable
>  So I have to restart in.routed each time I wanna connect to domain
>  edu.tw. Really irritating.

Do a "netstat -r" to look at the routing tables...
Do this when the ping works and when it doesn't work and see
what the difference is...

Brian

-- 
---------------------------------------------------------------
   Maj. Brian A Boyter
   US Army Foreign Science & Technology Center
   Charlottesville, Va 22901                         __
   off: (804)980-7362                              (    )
   home:     973-9440                             {      }
                                                   (    )
   boyter@fstc-chville.army.mil                      ||
                                                     ||
   Just say glow......                       _______<  >_______

-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 02:06:00 GMT
From:      0004219666@MCIMAIL.COM (Bob Stine)
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection

Please, oh please, could we not argue over copy protection in this forum?

-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 05:28:28 GMT
From:      RMRichardson.OSBU_North@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection


> ... but to say that people should boycott a company that tries to keep 
> you from making unauthorized copies of their software is like saying you 
> shouldn't go to the supermarket because they prosecute shoplifters.

No, ... not quite.  I think saying people should avoid a company that tries
to keep you from making unauthorized copies of their software with annoying
protections is like saying you shouldn't go to the supermarket that tries 
to prevent shoplifting by pat searching every customer as they exit the 
store.

If a supermarket thinks it's customer base needs to searched to prevent 
shoplifting, I don't want to be in that customer base.  

If a software company thinks it's customer base needs to be harassed to 
prevent piracy, I don't want to be in that customer base either.  


Rich

-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 06:13:06 GMT
From:      fortinp@bwdls56.bnr.ca (Pierre Fortin)
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection

In article <9101272223.AA08327@desktalk.com>, rlg@BIOBIO.DESKTALK.COM (Richard L. Gralnik) writes:

[stuff about illegal copying deleted]
>                                             Trying to make the vendor
> into the bad guy is a poor attempt at self-justification/rationalization.
> 
> If you want to live on share-ware go ahead, but to say that people 
> should boycott a company that tries to keep you from making unauthorized 
> copies of their software is like saying you shouldn't go to the 
> supermarket because they prosecute shoplifters.
> 
> Richard
> (rlg@desktalk.com)
> 
> p.s. Tops also implements a networked serial number comparison scheme.  

I have no problem with vendors trying to protect their investment, but where
should the line be drawn?  Checking serial numbers over the network (as is 
the case with some Mac software) does not always scale; worse, if it chews 
up lots of intercity bandwidth and causes me to have to increase the size of
my links to handle this type of traffic, then I will contact my Purchasing
and Legal departments to try and have this "network manace" blacklisted.  

If this type of copy protection scheme is deemed necessary, then lets get 
some concrete proposals on the table which are network and administrator 
friendly.  From there, why not have an RFC describing the process/protocol
and make it a standard.  After all, isn't this just another flavor of the 
larger "security" issues?

Cheers,                      
Pierre Fortin       fortinp@bnr.ca         (613)763-2598

-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 06:18:14 GMT
From:      zweig@cs.uiuc.edu (Johnny Zweig)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Header Checksum Calculation

Here is the C++ code from my working IP checksum calculation routine:

Word16
IPChecksum( octet * datagram, int length ) {
	// Add all the 16-bit words (in HOST byte-order!) inside a 32-bit word,
	//   so that the carries can all be added in at the end of the 
	//   calculation. Notice that, regardless of host byte order, if we 
	//   assign the sum to an int16, the byte with the lower address will 
	//   be the one with the high order bits (i.e. we never switched them, 
	//   even though the host might have regarded the high order 
	//   bits as low order when doing the sum -- the end-around carry
	//   takes care of everything!), so casting a pointer to an int16 
	//   as an octet * will cause the assignment to a Word16 to do the
	//   Right Thing. (See RFC 1071 for lots about checksum-computation.)

	int32	sum = 0;
	int16	tmp;
	Word16	num;
	int16 *	foo = (int16 *)datagram;

	// Add in a 32-bit int (won't overflow):
	while ( length > 1 ) {
		sum += *foo++;
		length -= 2;
	}

	// Add left-over byte, if any
	if ( length > 0 ) {
		int16 holder;	// Make it an int16 so alignment is right
		char * holderarray = (char*) & holder;
		holderarray[0] = *foo;
		holderarray[1] = 0x00;
		sum += holder;
			// To make sure there is a zero after that last byte!
	}

	// Fold 32-bit sum to 16 bits (while-loop since may have to add twice
	//   if the first addition causes overflow out of lo-order 16 bits)
	while ( sum >> 16 )
		sum = ( sum & 0x0000ffff ) + ( sum >> 16 );

	tmp = sum;
	tmp = ~tmp;

	num.equals((octet *) &tmp);
		// Here, then, we've basically casted from octet * to int16 *
		//   and back to octet *; it ends up with the right byte order
	return( num );
}

The class Word16 has operations equals(octet *) and val() which assign from a
network-byte-order value pointed to by the point, and return a host byte order
value from the word.  Octet is just unsigned char, int16 is probably unsigned
short int, etc.

-Johnny Checksum

-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 12:39:18 GMT
From:      sanand@sp90.uucp
To:        comp.protocols.tcp-ip
Subject:   RCP over Wide Area or Slow Serial


I am looking for references/information/opinions on using RPC over
"long delay" or slow serial (9.6) lines or X.25. Are there any performance 
studies out there? Any write-ups of case studies? (RPC would be used
between application entities, not for NFS purposes). What are the issues
involved in using RPC over IP@9.6 or even 2400 or X.25? Does the UDP layer
break down or become unusable over  IP/X.25?

As an aside, can anyone point me to info on the latest status of RPC
and security? Since RPC does not hold a "session" between two entities (is that
right?), how do people handle *session* security (as opposed to security for
a specific instance of an RPC call)?

Thanks in advance,
Sanand.
sp90.uucp!sanand 
sp90!sanand@lsuc.on.ca
sp90!sanand@uunet.uu.net

-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 13:34:54 GMT
From:      kasten@EUROPA.INTERLAN.COM (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re:  IP Header Checksum Calculation

Brian,
look at:

RFC 1071  Braden, R.T.; Borman, D.A.; Partridge, C.  Computing the Internet
          checksum.  1988 September; 24 p. (Format: TXT=54941 bytes)  (Updated by
          RFC 1141)
      
Frank Kastenholz
Racal Interlan

-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 14:20:03 GMT
From:      mckee@COMMUNITY-CHEST.MITRE.ORG (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: ISI W-Notes

You asked for info concerning the Secure Data Network System
(SDNS) documents.
The proposed protocols have been published by NIST as:
NISTIR 90-4250, 90-4259, and 90-4262.  The protocols are not
very readable.  If you want something more tutorial see the 
Proceedings of the 10th and 11th National Computer Security 
Conference.  The Proceedings were published jointly by the
NBS (now NIST), and the National Computer Security Center.
The relevant tutorial articles total about 23 pages.  If getting 
them is a hassle, give me an address; I will make a copy and mail 
them to you.  Regards - Craig

-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 14:44:45 GMT
From:      tcs@ccci.UUCP (Terry Slattery)
To:        comp.protocols.tcp-ip
Subject:   Re: When is a link saturated?

This discussion on identifying port numbers for use with the cisco feature
of prioritizing packets for output has concentrated on the 'standard'
network utilities.  There are many applications other than telnet and ftp
that can benefit from this feature.  The developers of these applications
often need a way of getting the data through the network in a timely
manner.  When other users are running large FTP transfers, time critical
data may be delayed, reducing its value.  The cisco port priority feature
allows the net manager to specify certain traffic, by port number, as having
higher priority than other traffic.  Telnet vs ftp is generally not their
concern.  

For example, stock market data being sent from a ticker-plant to trader
workstations probably has higher priority than a background FTP of a
database dump between two systems.  Without the priority selection (or
type-of-service), the market data may be delayed enough to seriously affect
its value to the trader.

I'd also consider configuring routers to give priority to SNMP packets so
that if someone is choking the net, I can still perform net management
through the mess.  (Not as good as out-of-band control, but better than
nothing.)

	-tcs
Terry Slattery
Chesapeake Computer Consultants, Inc.		Network and Unix Consulting
2816 Southaven Drive				(301) 970-8076
Annapolis, MD  21401

-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 15:23:25 GMT
From:      bob@MorningStar.Com
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection

(I told myself I wouldn't get drawn into this non-TCP/IP related
discussion, but this pushed a button...)

   From: don@nic.the.net (Donald L. Nash)
   Newsgroups: comp.protocols.tcp-ip
   Date: 29 Jan 91 19:43:30 GMT

   In article <4605@lib.tmc.edu>, jmaynard@thesis1.hsch.utexas.edu (Jay
   Maynard) writes:
         p.s. Tops also implements a networked serial number
         comparison scheme.
      
      Thanks for passing that along. Yet another product to avoid.

   The copy protection scheme used by Tops is very inobtrusive.
   ...They don't get in the way if you are honest, since the cashier
   removes the target when you pay for the clothes.  But they do keep
   you from being dishonest.
   ...
   I have no problem using Tops, since it does not contribute
   unnecessarily to network traffic and since it does not prevent me
   from making backup copies of my disk.  And since I'm honest and pay
   for my software, it doesn't prevent me from getting my work done.

You missed the point.  The problem isn't just the network load, it's
the copy protection scheme itself.

You obviously haven't tried to run a lab of 100 Macintoshes using TOPS
for file service from a large UNIX machine.  Every time an undergrad
bombs h{is,er} Macintosh they must approach the help desk for help
rebooting.  The lab monitor must then ascertain which particular Mac
the student was using (often requiring a trip out into the carrels and
back), and get its specific TOPS boot disk from the drawer.  The
monitor must then go out into the carrels (perhaps for the second
time) and assist the student in booting the Macintosh.  During each of
these trips, the monitor is vulnerable to interruption by other users,
which creates additional delay in servicing the original user's
request.  Then the boot disk must be returned to the drawer so that it
can be found and used the next time.  This is an example of an honest
user being hamstrung by legitimate use of a copy-protected product, in
fact using it in a way that the product's marketing stressed as a way
to reap the major advantages from the product.

This certainly does prevent honest users from getting their work done.
Several years ago when I was on the facilities staff and helping set
this stuff up at OSU CIS, the president of Centram (which developed
TOPS before it was bought by Sun) sat in a conference room and told us
to our faces that they would provide us with a non-copy-protected
version of the software.  Based on that promise we purchased hundreds
of copies of TOPS, expecting the hassles I described above to be only
a temporary inconvenience until the new version arrived.  Needless to
say, it never did, and last I heard Sun hasn't honored that promise
either (not that there's any reason to expect them to - Sun's not
Centram, and Sun didn't make the promise).

Is it OK to slam a company that doesn't exist any more? :-)

-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 15:56:06 GMT
From:      wbc@moose.dartmouth.edu (Wayne B. Cripps)
To:        comp.protocols.tcp-ip
Subject:   What is the voltage spec for thinnet?



What should the voltage be on thinnet? - I get readings of
-1.8 to -2.0 volts and .2 to .3 volts - is this in the
range?  is 1.2 volts ok?

	Wayne

-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 15:58:31 GMT
From:      calvert@cs.utexas.edu (Kenneth L. Calvert)
To:        comp.protocols.tcp-ip
Subject:   connect "collisions" in TCP


In TCP, the result of a "connect collision" (i.e., two peers
"simultaneously" attempting to open a connection to the same pair
of ports) is a single connection.  I have two questions:

0.  My impression is that the Berkeley Unix sockets interface (to TCP)
precludes deliberate use of this "feature".  Have I missed something?
(The implementation does the right thing when SYN is received in state
SYN_SENT).

1. Can anyone cite an application or higher-level protocol that
makes use of (or could, if it were possible) this fact,
i.e. permits users to establish connections symmetrically?
I can think of one possibility: the FTP data connection,
but I don't think it works that way.

Don't need to do this myself -- just curious.

Ken Calvert
calvert@cs.utexas.edu

-----------[000457][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 16:11:36 GMT
From:      brianop@opac.uucp (BRIAN MCBEE)
To:        comp.unix.misc,comp.protocols.tcp-ip
Subject:   Will telnet do VT100 translation for other term types?

I am a relative UNIX novice with a question about telnet:

Do the standard telnets that come sith Sys V or BSD do VT100 emulation, or do 
they just pass data transparently back to the terminal?  We don't have our 
Unix system yet (not sure what we are going to buy), but we have people that 
will be logging in from all kinds of different terminals.  We would then like 
to be able to telnet from the unix system to a VAX running VMS, and run an 
application that REQUIRES vt100 terminal emulation.  Will telnet do the 
translation for them, or do we need some other software?

Any and all replies appreciated.
-- 

=============================================================
Brian McBee  (503)378-4276  brianop@opac.UUCP                
Oregon State Library, State Library Building, Salem, OR 97310
=============================================================

-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 16:59:56 GMT
From:      rogers@OSI540SN.GSFC.NASA.GOV (Scott W. Rogers)
To:        comp.protocols.tcp-ip
Subject:   Re: MIT SNMP on SCO 3.2.2 UNIX platform

> From: netwrx1!lisa@uunet.uu.net  (Lisa C. Ingrassia)
> Organization: Open Networks, Inc., Reston, VA
> Subject: MIT SNMP on SCO 3.2.2 UNIX platform
> Message-Id: <1204@netwrx1.NW1.COM>
> 
> I have recently downloaded the MIT SNMP Development kit code (Oct 90
> version) from the allspice.lcs.mit.edu host.  I want to port it to
> the SCO Unix 3.2.2 platform. However, it refers to many include files
> that SCO Unix does not support (e.g., machparam.h).
> 
> Has anyone already ported this code to the SCO Unix platform who will
> share the changes made to run with SCO's include file & library
> structure?
> Thanks.
> ==============================================================================
>   Lisa Ingrassia		Usenet:	  uunet!netwrx1!lisa
>   Open Networks, Inc. 		Internet: lisa%netwrx1@uunet.uu.net
>   11490 Commerce Park Drive	          lisa@netwrx1.nw1.com  
>   Suite 205			FAX:      (703) 648-0016
>   Reston, Virginia 22091	Voice:    (703) 648-0013

Lisa,
I provide the network administration and Internet connection for the
annual UniForum conferences, and this year I did use SNMP as a basis
for monitoring the network.

I used The Wollongong Groups (TWG) SNMP management software and SCO's
SNMP agent on SCO-ODT UNIX.  The TWG Mgmt S/W ran fairly well, but the
SCO agent kept dying.  I also obtained CMU and MIT's SNMP software, and
also have not yet completed porting it due to missing include files.  I
just got my computer back from the last show (Jan 22-24) and will begin
working on this again next week.

Also, I intend to look at the ISODE 6.0 SNMP agent to see if it can
easily be ported to SCO UNIX (just need lots of disk space right?).

Anyhow, if you would like to colaberate, please let me know, also I
would be interested in any information/sucesses/failures you may have.
------------------------------------------------------------------------
Scott Wayne Rogers	Internet: <rogers@osi540sn.GSFC.NASA.GOV>
Computer Sciences Corporation -- System Sciences Division.
4600 Powder Mill Road         -- Beltsville, MD 20705  (301) 572-8297
*NASA SEAS Contract/Code 540 - Goddard Space Flight Cntr - Greenbelt, MD*
------------------------------------------------------------------------
DISCLAIMER:  I speak only for myself, I do not officially represent CSC,
GSFC or NASA in my comments above unless explicitly stated and quoted in
the text above.  The opinions and comments stated here are my own.
------------------------------------------------------------------------

-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 17:23:37 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Monitoring TCP/IP sockets

In article <9101291553.AA06606@litwin.jpl.nasa.gov.> litwin@ROBOTICS.JPL.NASA.GOV (Todd Litwin) writes:
>I have a program that uses TCP/IP sockets and needs to know quickly, within a
>second or so, if the physical connection between the two systems is broken.

This basically can't be done; it's easy to get transient interruptions that
last longer than that, and there is no reliable way to distinguish them
from a real break in the link.  If you're willing to consider even such a
hiccup as a failure, then you need some sort of keepalive protocol at a
higher level.  TCP/IP is deliberately very tolerant of outages.

>... I'm using setsockopt() to turn on SO_KEEPALIVE, but this
>doesn't help, either....

SO_KEEPALIVE is a kludge; its timeout period is non-adjustable and quite
long.  You're going to have to do it yourself.
-- 
If the Space Shuttle was the answer,   | Henry Spencer at U of Toronto Zoology
what was the question?                 |  henry@zoo.toronto.edu   utzoo!henry

-----------[000460][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 17:43:46 GMT
From:      c_rstine@HNS.COM (Robert Stine)
To:        comp.protocols.tcp-ip
Subject:   Variable-length subnet masks?

Would someone please point me to the latest poop on variable-length
subnet masks?

Thanks,

Bob Stine   home: bstine@MCIMail.com
            work: c_rstine@hns.com

-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 17:46:32 GMT
From:      swb@chumley.tn.cornell.edu (Scott Brim)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Multicast Support

Steve Deering is still working on multicasting.  John Moy and the IETF
Multicast OSPF Working Group have pretty much finished a design for
extending OSPF to route multicast packets.  I have two designs (similar,
but trade-offs) for BGP which I'm in the middle of introducing into the
BGP Working Group for inter-AS routing of multicast packets.  It's on
the list for the Inter-Domain Policy Routing folks but I'm pretty sure
no one there has done any real design work yet.  I don't know of any
actual *implementation* work on any of this yet -- for OSPF and BGP we
wanted to make sure it all fit together before we started implementing
either.

It is our (Cornell's) intention to implement forwarding multicasts in
both OSPF and BGP on the gatedaemon base, Real Soon Now.

There are a number of people out there working on transport protocols.
The most recent I have heard about is Keith Marzullo (here at Cornell).

							Scott


In article <759@mephisto.edu> rjc@comlab3.gatech.edu (Russell J. Clark) writes:

   Can anyone give me some information on the status of IP Multicast Support
   in the TCP/IP community. I've read the various RFC's up through August 1989
   by Steve Deering. I've also spent some time implementing some lower
   level multicast support on a Sparcstation and Sun OS 4.1.

   I'm interested in hearing about implementations, both commercial and 
   educational. I'm particularly interested in addressing the issues with
   routing of multicast packets.

-----------[000462][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 18:18:37 GMT
From:      root@ES-CIT.ESUSDA.GOV (Everett Dowd)
To:        comp.protocols.tcp-ip
Subject:   copy protection


	
> Please, oh please, could we not argue over copy protection in this forum?
	
Yes I agree! I thought this was for discussion of tcp-ip related items, 
not copy protection! 

-----------[000463][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 19:58:32 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  IP Header Checksum Calculation


I suggest you look at RFC-1071, republished in CCR April 89.

Bob Braden

-----------[000464][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 21:24:44 GMT
From:      erekose@apple.com (Erik Scheelke)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP + NFS for SysV 386


Hi,

I'm looking for a good TCP/IP and NFS for Intel Unix 386 Sys V 3.2.2.
It must have good socket library support.  I have tried Wollogong
and found it lacking in both support and function.

Any help would be appreciated!
Erik Scheelke

-----------[000465][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 21:31:39 GMT
From:      alex@sapphire.idbsu.edu (Alex Feldman)
To:        comp.protocols.tcp-ip
Subject:   ethernet frame specification

This isn't about tcp/ip, but someone in this group must know this...

The specifications of an ethernet frame in 8802/3 standard (5th 
printing, May 1988) and the one in Comer's book (Internetworking
with TCP/IP, 2nd ed (1991)) differ.  My question is, why the difference,
and what happens to the type field in the 8802/3 version?  Comer 
lists all these types for different kinds of potential data...
do those go away?  How are types distinguished?



-- 
	--alex			alex@opal.idbsu.edu

Boise State University doesn't have any opinions.  Therefore, these are 
not the opinions of Boise State University.

-----------[000466][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 22:17:42 GMT
From:      beach@DDNUVAX.AF.MIL (darrel beach)
To:        comp.protocols.tcp-ip
Subject:   ada tcp/ip lan 2.3


   Can anybody tell me if the term "ADA TCP/IP LAN 2.3" refers to some
product or if its just a bunch of terms that somebody put together???

   Somebody else asked me and I have no clue, but it does look like a
possible product name.

darrel

-----------[000467][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 91 22:35:10 GMT
From:      kasten@EUROPA.INTERLAN.COM (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re:  connect "collisions" in TCP


 > From tcp-ip-RELAY@NIC.DDN.MIL Wed Jan 30 17:15:41 1991
 > From: usc!cs.utexas.edu!calvert@ucsd.edu  (Kenneth L. Calvert)
 > Organization: U. Texas CS Dept., Austin, Texas
 > Subject: connect "collisions" in TCP
 > Sender: tcp-ip-relay@nic.ddn.mil
 > To: tcp-ip@nic.ddn.mil
 > 
 > 
 > In TCP, the result of a "connect collision" (i.e., two peers
 > "simultaneously" attempting to open a connection to the same pair
 > of ports) is a single connection.  I have two questions:
 > 
 > 0.  My impression is that the Berkeley Unix sockets interface (to TCP)
 > precludes deliberate use of this "feature".  Have I missed something?
 > (The implementation does the right thing when SYN is received in state
 > SYN_SENT).
I'm not sure what you mean by this question. This "feature" is a function
of the protocol, not the interface to your local protocol implementation.
The "feature" is deliberately "used" by TCP implementations to prevent
there being two Transmission Control Blocks in a host for the same
connection -- a state which is very bad.

 > 1. Can anyone cite an application or higher-level protocol that
 > makes use of (or could, if it were possible) this fact,
 > i.e. permits users to establish connections symmetrically?
 > I can think of one possibility: the FTP data connection,
 > but I don't think it works that way.

Generally, the client/server model of communications that we use
precludes the possibility of a "connect collision". Assuming that
it was possible to cause such a thing to happen, I am not sure why
one would explicitly want to do so -- the end result is the same
regardless of whether there was such a "conenct collision" or not --
a full duplex connection.

 > 
 > Don't need to do this myself -- just curious.
 
 > Ken Calvert
 > calvert@cs.utexas.edu
 > 

-----------[000468][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 91 00:19:09 GMT
From:      jqj@DUFF.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   SNAP, OUI=0, and transparent bridging


This message follows up on discussion that appeared on the tcp-ip list in
July of last year.  There have been some changes since that time: RFC1188
(revising RFC1103 and specifying IP over FDDI) in October, and a meeting
of 802.1d in November.  I gather from a recent posting by Kevin Brooks of
Apple on comp.protocols.appletalk that the 802.1d standard has changed
significantly.  In particular, it is now apparently generally agreed that
"transparent" bridging between Ethernet and 802 media should use a
non-zero Protocol ID for (some) Ethernet packets.  My question is whether
the authors of RFC1188 and 1042 have been involved in this process, and
what it implies for the future of IP-over-whatever heterogenous bridging.

One possible answer is "no change to IP encapsulation protocols".  If an
Ethernet->FDDI bridge uses the new non-zero OUI for only a small list of
protocols not including ARP and IP, and an FDDI->Ethernet bridge
decapsulates (at least IP and ARP) packets with OUI=0, then RFC1188 is
unaffected.  On the other hand, this might be an opportunity to rethink
encapsulation to deal with other problems like MTU mismatches and ARP
hardware type codes.  It certainly implies that we'll be seeing lots of
broken "transparent" bridge implementations, and that we as network
trobuleshooters will have lots of new business!

JQ Johnson
Director of Network Services		Internet: jqj@oregon.uoregon.edu
University of Oregon			voice:	(503) 346-4394
250E Computing Center			BITNET: jqj@oregon
Eugene, OR  97403-1212			fax: (503) 346-4397

-----------[000469][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 91 00:40:20 GMT
From:      lstowell@pyrnova.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: ethernet frame specification

In article <1991Jan30.213139.4067@sapphire.idbsu.edu> alex@sapphire.idbsu.edu (Alex Feldman) writes:
>This isn't about tcp/ip, but someone in this group must know this...
>
>The specifications of an ethernet frame in 8802/3 standard (5th 
>printing, May 1988) and the one in Comer's book (Internetworking
>with TCP/IP, 2nd ed (1991)) differ.  My question is, why the difference,
>and what happens to the type field in the 8802/3 version?  Comer 
>lists all these types for different kinds of potential data...
>do those go away?  How are types distinguished?

Not sure if you mean the diff between Ethernet and 802.3x frame
formats or not.  

Ethernet has the Type code right after addressing, 802.3 has the
"LLC Length" field in the same position.  

LLC Length is the length of the LLC data within the 802.3
frame.

IF, and it is a big if, the protocol stack conforms to 88022
LLC, the type code is inside the LLC data and actually serves as
a source and destination "address" for data contained within the
Frame (which have their own physical level addresses)

These LLC addresses are known as SAP (service access points).

  The format of the LLC data within the frame is:
  
    DSAP   SSAP   C-Field     LLC layer I-Field  
    Addx   Addx    >

It is not required that the DSAP and SSAP be the same value, sor
example in SNA, it is permissible for the SNA SAP '04' to
address LLC commands to the Null SAP '00' in order to query the
LLC of the destination for routing and/or status information.

Typically user data flows over like SAP's, but this is not a
requirement.....the SAP is just the protocol handler within the
device to which the LLC layer will hand the incoming data.  It
is up to the upper layer to handle the data appropriately.

-----------[000470][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 91 00:50:18 GMT
From:      cozza@cshl.org (Steve Cozza)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTelnet Solutions

In article <1991Jan29.184338.25059@eagle.lerc.nasa.gov> xxmartn@lims03.lerc.nasa.gov writes:
>
>Intercon Systems makes a VT52, VT102, VT240, Tektronics 4014, VT 3278 (mod 
>2-5) emulator called TCP/CONNECT II. All the emulations are built into this 
>package.  It supports TCP/IP and MacTCP.
>

We obtained a copy of TCP/Connect II for review here.  It performed
excellently over Ethernet using MacTCP and over a modem connection with
their SLIP implementation. The only reason we returned the product was
because we were looking for a SLIP (or PPP) driver for the Mac that would
allow us to run MacX over dial-in lines.  Their SLIP implementation did not
do this. I was told that this was due to limitations in the Mac OS, and might
be fixed in system 7.0.  Out of the othe networking packages we have used
I found TCP/Connect to have many features not normally found in just one
package.

Steven Cozza
Cold Spring Harbor Laboratory
Bungtown Road
Cold Spring Harbor
New York, 11724

-----------[000471][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 91 01:17:51 GMT
From:      lstowell@pyrnova.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   tn3270 Source Code for 5.3.2 Unix or 4.3 BSD

I am looking for a commercially available source for tn3270 for
a large scale Unix system.  This would be for a server,
although inclusion of client would be nice....
 
This code must be available for commercial resale....

The AT&T 5r3.2 environment would be preferred.  

Please reply to

  lstowell@pyramid.com

  or call:

  415-335-8854   

-----------[000472][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 91 01:23:04 GMT
From:      mleech@bwdlh131.bnr.ca (Marcus Leech)
To:        comp.protocols.tcp-ip
Subject:   Re: Monitoring TCP/IP sockets


In article <1991Jan30.172337.7084@zoo.toronto.edu>,
henry@zoo.toronto.edu (Henry Spencer) writes:
|> In article <9101291553.AA06606@litwin.jpl.nasa.gov.>
 litwin@ROBOTICS.JPL.NASA.GOV (Todd Litwin) writes:
|> 
|> SO_KEEPALIVE is a kludge; its timeout period is non-adjustable and quite
|> long.  You're going to have to do it yourself.
I'll second that, and add that I have successfully used application-level
  "keep-alives" (which should properly be called "make-deads") to detect
  server processes going away.  This *only* works if you have very tight
  control over where your packets are routed.  It happens that my applications
  have servers "in the next room", so network prop delays are quite
  predictable (in lieu of technicians severing cables ;-( ).
--
Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
mleech@bnr.ca                  P.O. Box 3511, Stn. C   |are my own, and not
VE3MDL@VE3JF.ON.CAN.NA         Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs

-----------[000473][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 91 04:24:06 GMT
From:      shaker@CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   PC version of tcpdump?

Does anyone know where I can get a PD version of a PC netwatch or tcpdump
program available for home use? If so, please respond to me via email, if
possible.  Send email to me if you also want to know what I find out.

Thank you,
Chris Shaker
shaker@cisco.com

-----------[000474][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 91 07:04:54 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Monitoring TCP/IP sockets

In article <12657895596.14.BILLW@mathom.cisco.com> BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes:

       I have a program that uses TCP/IP sockets and needs to know quickly,
       within a second or so, if the physical connection between the two
       systems is broken.

   Foo.  tcp/ip is designed for reliability over many media.  You have no
   guarantee that your packet will even get to its destination within a
   second, even if the network is working perfectly.

   If you really need to know that quickly whether the network has gone
   away, tcp/ip is not a suitable protocol to be using.

You didn't foo him very well, Bill.  Yes, he shouldn't be using TCP/IP.
But he *can* use IP.  It's just a matter of protocol design.  If you
*really* want to know if your network has gone away in a second, you
obviously have to have a network whose packets can make a round trip
in less than a second.

Moreover, we need to communicate in *much* less than a second, because
we have to be able to retry several times.  We also need to be able to
limit traffic on the network, so that we can guarantee a certain probability
that no return packet *really* means dead machines.

And if the protocol is designed well, it could constantly update a
probability measure of connection downness.

So, he can't do it on an arbitrary LAN (or LANs), nor guarantee a
100% correct answer, but he *can* do it over IP.

--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  FAX 315-268-7600
It's better to get mugged than to live a life of fear -- Freeman Dyson
I joined the League for Programming Freedom, and I hope you'll join too.

-----------[000475][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 91 15:02:43 GMT
From:      kcpeng%ccsun1.csie.nctu.edu.tw@CUNYVM.CUNY.EDU
To:        comp.protocols.tcp-ip
Subject:   in.routed

Hi,

  I'm running Sun4/370 with SunOS 4.0.3 (which itself is a name server).
  I ping a host in domain csie.nctu.edu.tw:

    % ping pdp1
      pdp1 is alive

  Then I ping a host in domain nctu.edu.tw:

    % ping mozart
      mozart.nctu.edu.tw is alive

  Then I ping a host in domain edu.tw:

    % ping nthu
      sendto: Network is unreachable

  Then I kill the routing daemon in.routed and restart it, and

    % ping nthu
      nthu.edu.tw is alive

  After one or two minutes (indeed !), I do it again:

    % ping nthu
      sendto: Network is unreachable

  So I have to restart in.routed each time I wanna connect to domain
  edu.tw. Really irritating.

  Any clue ?

Kai-Chih Peng
kcpeng@ccsun1.csie.nctu.edu.tw

-----------[000476][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 91 16:38:38 GMT
From:      MAB@CORNELLC.CIT.CORNELL.EDU (Mark Bodenstein)
To:        comp.protocols.tcp-ip
Subject:   Re: connect "collisions" in TCP

On 30 Jan 91 15:58:31 GMT you said:
>
>In TCP, the result of a "connect collision" (i.e., two peers
>"simultaneously" attempting to open a connection to the same pair
>of ports) is a single connection.  I have two questions:
> ...
>1. Can anyone cite an application or higher-level protocol that
>makes use of (or could, if it were possible) this fact,
>i.e. permits users to establish connections symmetrically?

The VMNET (NJE over TCP/IP) protocol makes use of this; VMNET servers
both passively listen for connections and actively try to connect to
their configured peers; simultaneous symmetric connection attempts are
possible and result in a single connection.

I understand that the VMNET protocol, which was crafted at Princeton
University, will be documented in an RFC Real Soon Now.

Mark Bodenstein   (mab@cornellc.cit.cornell.edu)
Cornell University

-----------[000477][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 91 16:41:47 GMT
From:      pdcst@unix.cis.pitt.edu (Patrick Champion)
To:        vmsnet.tcp.multinet,comp.protocols.tcp-ip
Subject:   Problems between Wolligong ftp on VMS and ftp on Sun


Does anyone know of any problems between Wolligong on VMS and Sun's ftp.
I can ftp into the Sun 386 from VaxStation 2100's, Vax VMS with their
own ftp, and Ultrix's ftp, but not from this one vax that is using Wolligong.
I can also ftp from Wolligong VMS into all the above except the afore mentioned
Sun.
	What happens is that I can ftp as anonymous between the two, and
I can then do a user to log in after I am in as anonymous.  However If
I log in just as a user then I get the user name but no prompt for password.
It just sits there after the carraige return.

Any ideas anyone?  I am stumped.

P.S. the Wolligong is version 2 and the Sun ftp is from SunOs 4.0.2




-- 
Patrick D. Champion	   *Epidemiology Data Center* OS/2, you better watch 
pchamp@edc3jr.gsph.pitt.edu*University of Pittsburgh* out unix is cooler
pdcst@unix.cis.pitt.edu	   *************************************
edc3::champion (Decnet)	   *My views may not be Pitt's or EDC's*

-----------[000478][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 91 16:43:04 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection

In article <9101301523.AA08491@volitans.MorningStar.Com> bob@MorningStar.Com writes:
      From: don@nic.the.net (Donald L. Nash)
      Date: 29 Jan 91 19:43:30 GMT
      ...

   You missed the point... You obviously haven't tried...

I apologize for my harsh comments against Mr Nash in a public forum,
and an inappropriate forum at that.  I should learn to sit on my
hands.

-----------[000479][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 91 17:34:04 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: ethernet frame specification


Lon Stowell:

See also RFC 1042 and RFC 894.

--jon.

-----------[000480][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 91 17:42:07 GMT
From:      ericd@sco.COM (Eric Davis)
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection


Dear Netlanders

Some of the information in this post is incorrect. I do not want to 
use network bandwidth to explain the issues, however I would be more 
than willing to email concerned individuals directly about the the 
copy protection scheme and how it affects system adminstration and users.
From a techinical and adminstrative point of view SCO's implementation 
of a copy protection scheme it is not the limiting monster that it is 
thought to be. Please take time to understand the facts. 

Eric Davis

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Eric Davis                      () INTERNET -=+ ericd@sco.COM
Technical Support Engineer II   () UUCP     -=+ {uunet|sun|att|ucsc}!sco!ericd
                                () VOX      -=+ US + 408 425 7222
                                () FAX      -=+ US + 408 427 5443
                                () TWX      -=+ 910-598-4510 sco sacz
				() HOME     -=+ ericd@bumby.santa-cruz.ca.US
The Santa Cruz Operation, Inc.  ()=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
399 Encinal Street              () "We are the people our parents warned us
Santa Cruz, California 95061    ()  about" -Jimmy Buffett
attn: ericd                     () #include <legal/network/disclamer.h+
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



In article <6207@rsiatl.Dixie.Com+ jgd@Dixie.Com (John G. DeArmond) writes:
+rlg@BIOBIO.DESKTALK.COM (Richard L. Gralnik) writes:
+
+>Fellow networkers,
+
+>While I agree that copy protection can make life less than fun for an
+>administrator trying to make sure he/she restores the correct unique
+>set of floppies on a trashed machine, I don't understand why people 
+>feel the vendor has no right to protect their (usually considerable)
+>investment in product development from rip-off artists.  And note that
+>that term includes offices where everyone passes a copy around as much
+>as people who take the floppies home overnight to make one for their 
+>personal use.  
+
+>If you want to live on share-ware go ahead, but to say that people 
+>should boycott a company that tries to keep you from making unauthorized 
+>copies of their software is like saying you shouldn't go to the 
+>supermarket because they prosecute shoplifters.
+
+NO!!  This is like saying that the supermarket prosecutes every customer
+because they have a paranoia based on an imagined but not detected thief.
+
+As the owner of a small software and (real soon to be) hardware company,
+I gotta comment.  On my soapbox.
+
+The reason copy protection of any kind is obscene is that it is merely a
+symptom of an attitude disease in the vendor company.  Instead of viewing
+the customer as the source of his wealth and cultivating him accordingly,
+the vendor views the customer as simply a source of money who is to be
+milked to the extent possible.  Ever notice how copy protection-using
+vendors talk about those evil pirates with the same disgusted tone
+reserved  for cheating spouses, child rapers and politicians?   It has 
+nothing to do with a few disks being passed around.
+
+Wealth in a business context means far more than the money collected on a
+sale.  Business wealth means sales revenues, customer good will, word-of
+mouth advertising, followon sales, upgrade and new product purchases,
+customer understanding when bugs and/or bad features are found (which may
+mean the difference between a polite phone call to customer support and a
+massive flamage to this net and/or every magazine they can address a
+letter to,) tolerance of corporate mistakes by regulators, and (close to
+the hearts of the protectionists) customer reporting  of flagrant
+copyright or contract violations. 
+
+It really is an attitude problem on the part of the vendor.  I look upon
+incidental copying (which I define as the insignificant copying to take 
+home, to give to a friend or similiar activity.) as absolutely free
+advertising.  If I offer good customer support, fair pricing, and a
+decent upgrade policy, so-called "incidental pirates" will either grow
+bored with the program or will buy a package in order to get all the 
+above benefits.  And if they don't buy?  Well, I've not really lost 
+anything because that person probably would not have bought in any
+event and it is not like he had reached in my pocket and taken money
+out.   I simply failed to sell this person.
+
+I do, of course, have serious problems with real piracy, such
+as corporate copying or pirate resellers or bulk give-aways.  But we have 
+more than adequate legal remedies to address these problems.  If I treat
+my customers as collegues and trusted friends instead of money pits, it
+is likely that one of them will call and report large scale piracy.  After
+all, it is in all our benefits that we all stay around over the long term.
+
+Didya ever notice that there is usually an inverse relationship between
+the quality of software and the degree of copy protection.  Some of the
+absolutely worst software I've ever used (EE Designer) was a heavily
+protected CAD package.  This package was written in MS BASIC,  for
+christsake.  Yet the graphics device driver which contains the  copy
+protection code employs a multitasker to allow the copy protection dongle
+to be checked in real time (couldn't have a *paying customer* start the
+program and then *gasp* switch the dongle to another machine so that work
+could continue while the first PC drives a plotter for 6 hours.) 
+Conversely, some of the best software (OrCad, WordPerfect) have
+absolutely no protection.  Indeed, WordPerfect will take a support call
+on their 800 number from so-called pirates. 
+
+The original source of this thread, SCO Unix is a classic example.  Their
+Unix implementation is IHMO a piece of shit.  Not only is it buggy in
+general, the copy protection locks up the machine if it thinks it
+discoverd a *GASP* pirate.  No warnings, no controlled shutdown, just a
+lockup.  It's the company's Deputy Dipshit instinct revealing itself. 
+While SCO is huddling in  their hovels in an emotional corporate crisis,
+companies like IBM who DO understand customers (and coincidently how to
+make money from them) are giving RS/6000s with nary a sign of copy
+protection (yet, at least) to potential customers.  Wonder whether there
+are now more AIX or SCO Unix application platforms out there now?   I 
+have one client who is a MAJOR SCO VAR and reseller drop SCO and go with
+AIX because  of this crap.  I wonder how many more customers are out
+there?  Is the small system Unix market going to hand the market to IBM?
+Looks like..
+
+Here are some keys to "protecting your development investments" by 
+keeping customers happy:
+
+*	Provide a good product at a fair price.  If you have a $50 product
+	that you are trying to sell for $500, then don't be surprised that
+	copying goes on.  Exhibit A:  Lotus 123.  If you think you have a
+	product worth thousands, then prove it to your customers. If you
+	REALLY think that copying is a threat, have the customer sign
+	a contract before delivering the product.  
+
+*	Provide plenty of easy to use technical support.  Sure, users are
+	dorks but they are also the ones who pay your salary and who 
+	can either give you tremendous free advertising or more bad press
+	than you can ever overcome.
+
+*	Provide free bug fixes and provide free upgrades to those who report bugs.
+	After all, the bug is your f*ckup, not the customer's.
+
+*	Provide real value for the money in upgrades.  Don't call bugfix releases
+	upgrades in order to charge for them.  Telebit is one of the worst 
+	companies in this regard.   $150 for bugfixs. Jeez!  Of course,
+	they increment the major version number to make it look like an upgrade.
+
+*   If you sell a shrink-wrapped product, put in a copyright statement that
+	won't make customers laugh as they throw it in the garbage.  You can
+	do much worse than to copy Boreland's copyright statement.  Oh, and 
+	do not make it worse by calling it a "license agreement".
+
+*	Provide a way for your potential customers to "try before you buy".
+	Incidental copying is a very legitimate way to do this, as is shareware.
+	Orcad takes a different and inovative approach.  Call an Orcad sales
+	office and ask for a demo product.  What you will get is a fully 
+	functional version of the product but with a dongle.  Use it as
+	long as you wish.  When you buy, you get an unprotected version.
+
+Customer Service will make or break your product.  You'd damn well better
+plan for it as an integral feature of your product, fully as important
+as the software not crashing.  Here's an example of how to and how not to
+do customer support.  I have used 2 brands of intelligent async cards in
+Unix systems for my customers.  One brand is Comtrol and the other is 
+Stargate.  I no longer use Stargate because of customer support.
+
+When I opened the first Comtrol box, the first thing I saw was a plastic gold 
+card just like a credit card.  On this card was printed the 800 toll free 
+support number AND the names and direct dial numbers for the General Manager, 
+the Engineering Manager, the Hardware Tech Support manager, the Software
+Tech Support manager, the Production manager, the Marketing manager and
+the Sales manager.  Above this list of numbers is this statement:
+
+	"Our committment to you doesn't stop with our products.  We give 
+	you the support and the extra service you want.  IT's because your
+	satisfaction is our #1 priority.  COMTROL is only a phone call away.
+	You have full access to all COMTROL personnel.  For your convenience,
+	primary department contacts are listed below:"
+
+I've had one occasion to use the support number.  A board arrived one
+evening DOA.  I called just at closing time.  COMTROL had someone drive
+a board down to Delta DASH and I got it in a few hours.  They told me
+to return the DOA one when convenient and not to worry about shipping
+back the (very good) documentation.
+
+My Stargate experience was a bit different.  I inherited my first card 
+in some surplus stock I bought.  The card uses address decode PALs that
+are specific for each OS.  My card was equipped for Xenix and I  needed a
+PAL for ISC Unix.  I called up Stargate and reached a rather sullen tech
+support technician.  I was told that a new PAL cost $150!!! I passed on
+the PAL and obtained one from a friend but ordered a  driver disk for
+ISC.  When it got here, it was accompanied by some Nth-generation xeroxed
+dot-matrix printed documentation that was practically unreadable and it
+would not install.  It did not meet the specifications of ISC's
+installpkg facility.  I copied the disk onto the system and installed it
+manually. 
+
+Later, I needed to get an upgraded driver for a new version of the OS.  
+I called Stargate for the upgrade, somewhat expecting to pay for it.
+I was told that I would either have to write (!) to the sales department
+who would investigate me as a customer and if I passed, would give me
+the secret password to their BBS where I could download the upgrade.
+Or I could write and include some money and get a disk.  Write a letter
+in order to access a BBS indeed!  Could they have been afraid that I 
+had wirewrapped a board in my basement and wanted to steal the driver 
+to make it work?  Who knows.
+
+Now both boards work pretty well equally.  But I'll never fool with 
+Stargate again while I recommend COMTROL whenever the opportunity arises.
+The difference is service.  I perceived a better value from COMTROL even
+though it cost more.
+
+I firmly believe that if companies would get their heads out of where the
+sun never shines and focus the energy they put into copy protection into
+product quality, so-called piracy would cease to be an issue and their
+profits would soar.  As my company grows, I'm going to do the best of my
+ability to prove this theory correct yet again.
+
+John
+
+-- 
+John De Armond, WD4OQC        | "Purveyors of speed to the Trade"  (tm)
+Rapid Deployment System, Inc. |  Home of the Nidgets (tm)
+Marietta, Ga                  | 
+{emory,uunet}!rsiatl!jgd      |"Politically InCorrect.. And damn proud of it  


Newsgroups: comp.protocols.tcp-ip
Subject: Re: copy protection
Summary: 
Expires: 
References: <9101272223.AA08327@desktalk.com+ <6207@rsiatl.Dixie.Com>
Sender: 
Followup-To: 
Distribution: 
Organization: The Santa Cruz Operation, Inc.
Keywords: 

In article <6207@rsiatl.Dixie.Com+ jgd@Dixie.Com (John G. DeArmond) writes:
+rlg@BIOBIO.DESKTALK.COM (Richard L. Gralnik) writes:
+
+>Fellow networkers,
+
+>While I agree that copy protection can make life less than fun for an
+>administrator trying to make sure he/she restores the correct unique
+>set of floppies on a trashed machine, I don't understand why people 
+>feel the vendor has no right to protect their (usually considerable)
+>investment in product development from rip-off artists.  And note that
+>that term includes offices where everyone passes a copy around as much
+>as people who take the floppies home overnight to make one for their 
+>personal use.  
+
+>If you want to live on share-ware go ahead, but to say that people 
+>should boycott a company that tries to keep you from making unauthorized 
+>copies of their software is like saying you shouldn't go to the 
+>supermarket because they prosecute shoplifters.
+
+NO!!  This is like saying that the supermarket prosecutes every customer
+because they have a paranoia based on an imagined but not detected thief.
+
+As the owner of a small software and (real soon to be) hardware company,
+I gotta comment.  On my soapbox.
+
+The reason copy protection of any kind is obscene is that it is merely a
+symptom of an attitude disease in the vendor company.  Instead of viewing
+the customer as the source of his wealth and cultivating him accordingly,
+the vendor views the customer as simply a source of money who is to be
+milked to the extent possible.  Ever notice how copy protection-using
+vendors talk about those evil pirates with the same disgusted tone
+reserved  for cheating spouses, child rapers and politicians?   It has 
+nothing to do with a few disks being passed around.
+
+Wealth in a business context means far more than the money collected on a
+sale.  Business wealth means sales revenues, customer good will, word-of
+mouth advertising, followon sales, upgrade and new product purchases,
+customer understanding when bugs and/or bad features are found (which may
+mean the difference between a polite phone call to customer support and a
+massive flamage to this net and/or every magazine they can address a
+letter to,) tolerance of corporate mistakes by regulators, and (close to
+the hearts of the protectionists) customer reporting  of flagrant
+copyright or contract violations. 
+
+It really is an attitude problem on the part of the vendor.  I look upon
+incidental copying (which I define as the insignificant copying to take 
+home, to give to a friend or similiar activity.) as absolutely free
+advertising.  If I offer good customer support, fair pricing, and a
+decent upgrade policy, so-called "incidental pirates" will either grow
+bored with the program or will buy a package in order to get all the 
+above benefits.  And if they don't buy?  Well, I've not really lost 
+anything because that person probably would not have bought in any
+event and it is not like he had reached in my pocket and taken money
+out.   I simply failed to sell this person.
+
+I do, of course, have serious problems with real piracy, such
+as corporate copying or pirate resellers or bulk give-aways.  But we have 
+more than adequate legal remedies to address these problems.  If I treat
+my customers as collegues and trusted friends instead of money pits, it
+is likely that one of them will call and report large scale piracy.  After
+all, it is in all our benefits that we all stay around over the long term.
+
+Didya ever notice that there is usually an inverse relationship between
+the quality of software and the degree of copy protection.  Some of the
+absolutely worst software I've ever used (EE Designer) was a heavily
+protected CAD package.  This package was written in MS BASIC,  for
+christsake.  Yet the graphics device driver which contains the  copy
+protection code employs a multitasker to allow the copy protection dongle
+to be checked in real time (couldn't have a *paying customer* start the
+program and then *gasp* switch the dongle to another machine so that work
+could continue while the first PC drives a plotter for 6 hours.) 
+Conversely, some of the best software (OrCad, WordPerfect) have
+absolutely no protection.  Indeed, WordPerfect will take a support call
+on their 800 number from so-called pirates. 
+
+The original source of this thread, SCO Unix is a classic example.  Their
+Unix implementation is IHMO a piece of shit.  Not only is it buggy in
+general, the copy protection locks up the machine if it thinks it
+discoverd a *GASP* pirate.  No warnings, no controlled shutdown, just a
+lockup.  It's the company's Deputy Dipshit instinct revealing itself. 
+While SCO is huddling in  their hovels in an emotional corporate crisis,
+companies like IBM who DO understand customers (and coincidently how to
+make money from them) are giving RS/6000s with nary a sign of copy
+protection (yet, at least) to potential customers.  Wonder whether there
+are now more AIX or SCO Unix application platforms out there now?   I 
+have one client who is a MAJOR SCO VAR and reseller drop SCO and go with
+AIX because  of this crap.  I wonder how many more customers are out
+there?  Is the small system Unix market going to hand the market to IBM?
+Looks like..
+
+Here are some keys to "protecting your development investments" by 
+keeping customers happy:
+
+*	Provide a good product at a fair price.  If you have a $50 product
+	that you are trying to sell for $500, then don't be surprised that
+	copying goes on.  Exhibit A:  Lotus 123.  If you think you have a
+	product worth thousands, then prove it to your customers. If you
+	REALLY think that copying is a threat, have the customer sign
+	a contract before delivering the product.  
+
+*	Provide plenty of easy to use technical support.  Sure, users are
+	dorks but they are also the ones who pay your salary and who 
+	can either give you tremendous free advertising or more bad press
+	than you can ever overcome.
+
+*	Provide free bug fixes and provide free upgrades to those who report bugs.
+	After all, the bug is your f*ckup, not the customer's.
+
+*	Provide real value for the money in upgrades.  Don't call bugfix releases
+	upgrades in order to charge for them.  Telebit is one of the worst 
+	companies in this regard.   $150 for bugfixs. Jeez!  Of course,
+	they increment the major version number to make it look like an upgrade.
+
+*   If you sell a shrink-wrapped product, put in a copyright statement that
+	won't make customers laugh as they throw it in the garbage.  You can
+	do much worse than to copy Boreland's copyright statement.  Oh, and 
+	do not make it worse by calling it a "license agreement".
+
+*	Provide a way for your potential customers to "try before you buy".
+	Incidental copying is a very legitimate way to do this, as is shareware.
+	Orcad takes a different and inovative approach.  Call an Orcad sales
+	office and ask for a demo product.  What you will get is a fully 
+	functional version of the product but with a dongle.  Use it as
+	long as you wish.  When you buy, you get an unprotected version.
+
+Customer Service will make or break your product.  You'd damn well better
+plan for it as an integral feature of your product, fully as important
+as the software not crashing.  Here's an example of how to and how not to
+do customer support.  I have used 2 brands of intelligent async cards in
+Unix systems for my customers.  One brand is Comtrol and the other is 
+Stargate.  I no longer use Stargate because of customer support.
+
+When I opened the first Comtrol box, the first thing I saw was a plastic gold 
+card just like a credit card.  On this card was printed the 800 toll free 
+support number AND the names and direct dial numbers for the General Manager, 
+the Engineering Manager, the Hardware Tech Support manager, the Software
+Tech Support manager, the Production manager, the Marketing manager and
+the Sales manager.  Above this list of numbers is this statement:
+
+	"Our committment to you doesn't stop with our products.  We give 
+	you the support and the extra service you want.  IT's because your
+	satisfaction is our #1 priority.  COMTROL is only a phone call away.
+	You have full access to all COMTROL personnel.  For your convenience,
+	primary department contacts are listed below:"
+
+I've had one occasion to use the support number.  A board arrived one
+evening DOA.  I called just at closing time.  COMTROL had someone drive
+a board down to Delta DASH and I got it in a few hours.  They told me
+to return the DOA one when convenient and not to worry about shipping
+back the (very good) documentation.
+
+My Stargate experience was a bit different.  I inherited my first card 
+in some surplus stock I bought.  The card uses address decode PALs that
+are specific for each OS.  My card was equipped for Xenix and I  needed a
+PAL for ISC Unix.  I called up Stargate and reached a rather sullen tech
+support technician.  I was told that a new PAL cost $150!!! I passed on
+the PAL and obtained one from a friend but ordered a  driver disk for
+ISC.  When it got here, it was accompanied by some Nth-generation xeroxed
+dot-matrix printed documentation that was practically unreadable and it
+would not install.  It did not meet the specifications of ISC's
+installpkg facility.  I copied the disk onto the system and installed it
+manually. 
+
+Later, I needed to get an upgraded driver for a new version of the OS.  
+I called Stargate for the upgrade, somewhat expecting to pay for it.
+I was told that I would either have to write (!) to the sales department
+who would investigate me as a customer and if I passed, would give me
+the secret password to their BBS where I could download the upgrade.
+Or I could write and include some money and get a disk.  Write a letter
+in order to access a BBS indeed!  Could they have been afraid that I 
+had wirewrapped a board in my basement and wanted to steal the driver 
+to make it work?  Who knows.
+
+Now both boards work pretty well equally.  But I'll never fool with 
+Stargate again while I recommend COMTROL whenever the opportunity arises.
+The difference is service.  I perceived a better value from COMTROL even
+though it cost more.
+
+I firmly believe that if companies would get their heads out of where the
+sun never shines and focus the energy they put into copy protection into
+product quality, so-called piracy would cease to be an issue and their
+profits would soar.  As my company grows, I'm going to do the best of my
+ability to prove this theory correct yet again.
+
+John
+
+-- 
+John De Armond, WD4OQC        | "Purveyors of speed to the Trade"  (tm)
+Rapid Deployment System, Inc. |  Home of the Nidgets (tm)
+Marietta, Ga                  | 
+{emory,uunet}!rsiatl!jgd      |"Politically InCorrect.. And damn proud of it  

-----------[000481][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 91 18:16:04 GMT
From:      imp@Solbourne.COM (Warner Losh)
To:        vmsnet.tcp.multinet,comp.protocols.tcp-ip
Subject:   Re: Problems between Wolligong ftp on VMS and ftp on Sun

In article <85868@unix.cis.pitt.edu> pdcst@unix.cis.pitt.edu (Patrick Champion) writes:
>Any ideas anyone?  I am stumped.
>
>P.S. the Wolligong is version 2 and the Sun ftp is from SunOs 4.0.2

The latest rev of WIN/TCP for VMS is at least 5.1.  If you are running
Version 2.x, you will have major problems talking to some people.
Version 2.x was released about 5 years ago.

I think your only hope is to upgrade to a later version of WIN/TCP.
:-(

Warner
-- 
Warner Losh		imp@Solbourne.COM
We sing about Beauty and we sing about Truth at $10,000 a show.

-----------[000482][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 91 19:51:53 GMT
From:      lizhen@silver.ucs.indiana.edu (Zhen Li)
To:        comp.protocols.tcp-ip
Subject:   send motion pictures over ip network


Hello,
   
   Does anybody knows anything about sending motion 
pictures over an ip network?  Is there any such kind
of products on the market?  Any information will be
appreciated.

   Thanks,

   Jane  Li

-----------[000483][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 91 20:52:56 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   RFC 1108 and IP Security options?

RFC 1122 section 3.2.1.8(a) refers to an RFC 1108, "Internet Protocol
Security Options," by one B. Schofield, dated October 1989.  RFC 1122
also specifically warns that RFCs 1038 and 791 are obsolete, though it
cites 791 as the source of its MUSTs and MAYs.

But the RFC Index lists RFC 1108 as "not yet issued", and it indeed
seems not to be available from the NIC.  And RFC 1038 claims to be a
pre-publication draft.

What is the current authoritative reference in this area?  Must an
implementor order the revised MIL-STD 1777 from Navy Publications (as
suggested in RFC 1038), or is it available on-line in RFC form?

-----------[000484][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 91 21:05:42 GMT
From:      ejm@ejmmips.NOC.Vitalink.COM (Erik J. Murrey)
To:        comp.protocols.tcp-ip
Subject:   Re: When is a link saturated?

In article <9101301444.AA13881@ccci>, tcs@ccci.UUCP (Terry Slattery) writes:
> For example, stock market data being sent from a ticker-plant to trader
> workstations probably has higher priority than a background FTP of a
> database dump between two systems.  Without the priority selection (or
> type-of-service), the market data may be delayed enough to seriously affect
> its value to the trader.
> 

This is a valid point.  However, a lot of the newer applications are
forced to use not-so-well-known-ports via portmapper, etc.  There just
aren't that many ports to reserve them for speicalized use.  This
presents a big problem to routers since they shouldn't have to track
the portmap requests to see what service is registered to what port.

This makes TOS via port # an unrealistic choice.

The real solution to this problem is to make sure that specialized
services that use variable port numbers set the low-delay, etc., bits
in the IP header to tell the routers to prioritize these packets.

And, yes, the BSD stack is capable of setting these bits with some
mods to the code via socket options.

---
Erik J. Murrey
Vitalink Communications NOC
ejm@NOC.Vitalink.COM	...!uunet!NOC.Vitalink.COM!ejm

-----------[000485][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 91 22:43:31 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re:  connect "collisions" in TCP

In article <9101302235.AA04289@europa.InterLan.Com> kasten@EUROPA.INTERLAN.COM (Frank Kastenholz) writes:
> > From: usc!cs.utexas.edu!calvert@ucsd.edu  (Kenneth L. Calvert)
> > 1. Can anyone cite an application or higher-level protocol that
> > makes use of (or could, if it were possible) this fact,
> > i.e. permits users to establish connections symmetrically?
> > I can think of one possibility: the FTP data connection,
> > but I don't think it works that way.
>
>Generally, the client/server model of communications that we use
>precludes the possibility of a "connect collision". Assuming that
>it was possible to cause such a thing to happen, I am not sure why
>one would explicitly want to do so -- the end result is the same
>regardless of whether there was such a "conenct collision" or not --
>a full duplex connection.

It's unlikely to happen with client-server protocols, but I can imagine it
happening with peer-peer protocols.  Most such protocols that I can think
of are datagram and possibly broadcast/multicast based, rather than using
TCP.

One application I can think of would be the use of a long-lived TCP
connection to emulate a point-to-point link.  This might be specified such
that a particular pair of hosts always use the same pair of port numbers,
i.e. instead of a well-known server port, there would be a well-known
quadruple <host1-addr,host1-port,host2-addr,host2-port> (for simplicity,
both ports would probably be chosen to be the same).  When a host boots, it
sends out a SYNs using this well-known quad, until the connection succeeds.
If the other host was up while this host was down, it will notice the
out-of-sequence SYN, close its end (sending out a RST, I guess), and then
try to open the connection, which should succeed using a connect collision.
If both hosts were down at the same time, then when they each come up
they'll start sending out SYNs, and when both are up a connection collision
will occur.

--
Barry Margolin, Thinking Machines Corp.

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

END OF DOCUMENT