The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Nov 1993 03:29:06 GMT
From:      ctkosti@afterlife.ncsc.mil (Chris Kostick)
To:        comp.protocols.tcp-ip
Subject:   Re: ping's maximum packet size

In article <fred_sCFq1oM.E9H@netcom.com>,
Frederick Scott <fred_s@netcom.com> wrote:
>ctkosti@afterlife.ncsc.mil (Chris Kostick) writes: 
>
>>I was hoping to experiment with the affects of various packet sizes
>>on a network and was going to use ping.
>>
>>On a Sun (SUNOS 4.1.3) I tried
>>
>>	$ ping -s afterlife 2048
>>	PING afterlife.ncsc.mil: 2048 data bytes
>>	sendto: Message too long
>>	ping: wrote afterlife.ncsc.mil 2056 chars, ret=-1
>>	sendto: Message too long
>>	ping: wrote afterlife.ncsc.mil 2056 chars, ret=-1
>>	^C
>>	----afterlife.ncsc.mil PING Statistics----
>>	2 packets transmitted, 0 packets received, 100% packet loss
>>
>>The man page for sendto() says
>>
>>     If the message is too long to pass  atomically  through  the
>>     underlying  protocol,  then  the error EMSGSIZE is returned,
>>     and the message is not transmitted.
>>
>>I'm assuming the problem is with sendto() and not ping itself. Is there
>>anything I can do to make ping work with a packet size over 2000 bytes?
>>Do I need to change the source? the OS? Is there another program out in
>>net land that gives me the same functionality as ping?
>
>I don't think the problem is with sendto().  What kind of network are you
>pinging on?  An ethernet network has a maximum packet size of 1518 bytes,
>And I believe the ethernet and ICMP/IP headers and the CRC checksum will
>reduce the number of bytes you give ping as a parameter further.
>
>Anyway, the point is, I don't think there's any way you can convince SunOS
>to fragment your ping packet on the local network.  You're stuck with the
>maximum packet size.

I'm pinging on an ethernet network. From my understanding of the
protocols, if I have 4K of data to send, then IP can handle that. It just
fragments the data. Isn't that how NFS works? By default 8K UDP packets
are sent. IP has no problem fragmenting that. You say I can't convince
SunOS to fragment. Well, if send the 2000 bytes and then monitor the network,
it's fragmentmented into two packets. So obviously I can, my question
is why the 2000 byte limitation?

>
>As for another program giving you the "same functionality as ping does",
>that depends on exactly what functionality you want.  *No* program will
>allow you to transmit more bytes in a single packet than a network's MTU on
>that network, of course.  If you just want to send an arbitrary "X number of
>characters" to another host and have it reply with the same data coming back,
>I suppose you could just write a simple TCP program to do that.  TCP, of
>course, will have additional implications to any study of network performance.
>Alternatively, you could use UDP if you consented to use multiple sendto's.
>But any program attempting to implement the use of the ICMP/echo message
>in order to get a reply directly from the remote node's IP stack will run up
>against the same limitation that ping has.
>
>Fred

Sorry for the ambiguity. The functionality I was looking for was being able
to generate arbitrary packet sizes and measure the round trip time for a
series of packets sent.

--
chris

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 1993 03:47:27 GMT
From:      Martin Visser <Martin.mc.visser@bhpmelmsm.bhp.bhpmel04.telememo.au>
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip
Subject:   Re: which type of fiber to use?

In article <CFHME8.21s@world.std.com> Craig Partridge,
craigp@world.std.com writes:
>    Given the job of installing fiber into and between two buildings,
 what
>type of fiber should you install?  Let's assume both buildings are no
 more
>than six stories high, and no office in each building is more than 100m
>from a central wiring closet that runs up the core of each building, and
>the two buildings are 500m apart.  What type of fiber do you run:

We'll be undertaking a project of a similar nature ( but longer average
distances) in the next year
or so in out Steelworks. Currently we intend our backbone cable to be 18
core MM and 6 core SM.

Because of cost and the bandwidth requirements at the moment, we would
expect the SM to remain dark for the next 5 years at least. Single mode
interfaces are likely to very expensive until then , and probably will
not required to meet our needs.

One difficulty may be also choosing the specs of fibre. In another post,
ATM Forum have specified 500 MHz/km for MM fibre UNI. Garden-variety
62.5/125 seems to be only 400MHz/km, meaning older fibre may not be as
good, and you also may have order a special.

In article <1993Oct26.082922.6626@dxcern.cern.ch> Brian Carpenter  
CERN-CN, brian@dxcern.cern.ch writes:
>Inside buildings: multi-mode up to the closet
>		  UTP 5 to the desk (plus empty tubes!!!)

Are these "empty tubes" for fiber and if so are they in the same cable as
UTP?
Also how far can you blow fibre through tubes, both in straight runs, and
around bends?
               : Martin Visser
      /\/\     : BHP Steel - Slab & Plate Products Division 
     / / /\    : Engineering Technology - Computer Systems
    / / /  \   : PO Box 1854 Wollongong NSW 2502, AUSTRALIA
   / / / /\ \  : A.C.N. 006 476 218
   \ \/ / / /  : Phone     +61-42-753852
    \  / / /   : Fax         +61-42-757897
     \/\/\/    : Internet MARTIN.M.C.VISSER@
               :          BHPMELMSM.BHP.bhpmel04.telememo.au
               : X.400    G=MARTIN I=MC S=VISSER OU=BHPMELMSM O=BHP
               :          P=BHPMEL04 A=TELEMEMO C=AU

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Mon,  1 Nov 93 13:36:12 PST
From:      EricR@cup.portal.com (Eric - Rupert)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: multiple subnets behind a router



  I posted a question last week about netmasking multiple subnets to look
as one.  I havent received any responses yet, but have a possible way to
do this and am looking for comments on potential problems.

Given:  a cisco router and a cluster of class B subnets(ie. netmask 255.0)

How do you get a couple of thousand addresses to look like a single net.

Use 8 subnets beginning on say:  

	x.x.8.yyy
	x.x.9.yyy
	x.x.10.yyy
	x.x.11.yyy
	x.x.12.yyy	  
	x.x.13.yyy
	x.x.14.yyy
	x.x.15.yyy

  With the following environ:

	A --- Cisco ---T/1 (internet)

  where A is a group of systems(actually a unix cluster).

This is quite simple with the "secondary" ip address function of the router.
Look on pg 14-53 , Vol II of the manual, no need to mess around with the mask.

Eric Rupert - RPM Associates
Ericr@rpm.com

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Nov 1993 06:51:29 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: ping's maximum packet size

ctkosti@afterlife.ncsc.mil (Chris Kostick) writes: 

>In article <fred_sCFq1oM.E9H@netcom.com>,
>Frederick Scott <fred_s@netcom.com> wrote:
>>I don't think the problem is with sendto().  What kind of network are you
>>pinging on?  An ethernet network has a maximum packet size of 1518 bytes,
>>And I believe the ethernet and ICMP/IP headers and the CRC checksum will
>>reduce the number of bytes you give ping as a parameter further.
>>
>>Anyway, the point is, I don't think there's any way you can convince SunOS
>>to fragment your ping packet on the local network.  You're stuck with the
>>maximum packet size.
>
>I'm pinging on an ethernet network. From my understanding of the
>protocols, if I have 4K of data to send, then IP can handle that.

That is correct.   Any IP packet can be fragmented, it's just that if you
know that the MTU of your local net is X bytes, there (theoretically) isn't
any reason to attempt to send an IP packet of greater than X bytes.  The
BSD implementation of TCP, I believe, takes advantage of that by assuming a
default maximum segment size of the local net's MTU, to be reduced if it is
later found necessary or useful to for other reasons.

>It just fragments the data.

I'm somewhat surprised by this for the reasons I just stated.  However, if the
IP stack implementation is written to that with ICMP echos, then that's how it
is.  It's certainly "legal" to do.

>Isn't that how NFS works? By default 8K UDP packets are sent.

Yes, that would make sense.  RPC probably needs of UDP's record boundary
preservation feature in order to "atomize" an RPC operation, so that RPC
doesn't have to worry about, say, partial receipt of an RPC request.  That is,
some UDP packets arriving and some not.  By using a single, fragmented UDP
packet, RPC in essense leaves this problem for the IP protocol to deal with.
So I guess there IS a reason to purposely transmit a packet you know needs to
be fragmented right from the start.

>IP has no problem fragmenting that. You say I can't convince SunOS to
>fragment.

I was assuming so because I'd run into Berkeley distributions where you
couldn't.  (I knew it was legal to do - it's just that that the code wouldn't
let you.)  Of course, when you ASS-U-ME.... :-)

>Well, if send the 2000 bytes and then monitor the network, it's fragmentmented
>into two packets. So obviously I can, my question is why the 2000 byte
>limitation?

Well, now you've got me.  It may turn out to be arbritrary limit or it may
not.  So I'll leave the original question open to anyone who knows more about
this IP implementation than I do.  Sorry.

Fred

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Mon, 01 Nov 1993 14:58:08 EST
From:      Robert_Meindl__ISSG@bbsnewsgate1.ads.com
To:        comp.protocols.tcp-ip
Subject:   Newbie OSPF Question

Greetings

Could someone provide a clear explanation of how to determine the subnet
mask when you are using the variable length subnet mask feature of OSPF for
route summarization.  Specifically, I understand  the case when the
internet consists of multiple Class B addresses, but don't quite get how to
determine the mask for breaking up a Class B into several areas.

Thanks in advance

Bob Meindl
meindlr@v3.hanscom.af.mil
*************************************************************************** 
This message was sent from FirstClass(tm) by PostalUnion(tm) originating at
BOOZ-ALLEN & HAMILTON INC.  The views expressed in this posting are those
of the individual author and do not necessarily reflect the views of
BOOZ-ALLEN & HAMILTON INC.
***************************************************************************



-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Nov 1993 13:10:35 GMT
From:      bagpuss@spuddy.uucp (Mark Liversedge)
To:        comp.protocols.tcp-ip
Subject:   Re: How to read any packet in the ethernet

In article <1993Oct26.194928.10458@litwin.com> hoang1@litwin.com (Ted Hoang) writes:
>Hi,
>Could someone explain how to read any packet (TCP, UDP, IP, IPX ...) directly
>from the ethernet. Should I use open(), socket(), or none_of_the_above()...?
>How could I read this packet from beginning (byte 0)? 

Ultrix "man packetfilter"
SunOS  "man nit" (and etherfind)
BSDi   "man bpf" (and tcpdump)

Anything else and I haven't a clue. If you want some sample code I can mail
it to you, these devices read from the wire It's down to the user to
decode protocols.

Good luck!
-- 

 * Meeeow ! Call Spuddy on (0203) 364436/362560 for FREE mail & Usenet access *

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Nov 1993 13:31:58 GMT
From:      leighd@syma.sussex.ac.uk (Leigh Dodd)
To:        comp.protocols.tcp-ip
Subject:   Ethernet MAC address programme required

Hi All
	Can anyone give me a glue as to where I can find a P.D. (Free)
programme that will give me the MAC address on a selected computer ?.
	I can ping and the arp a few computers and I get the address, but
a number don't update the arp tables (Sun OS 4.1.3). I can also run snoop
but it's a bit messy considering I need to get the addresses of about 100
machines. 
	A simple ping type thing would be nice. Can be Unix or DOS.

Thanks in advance

Leigh

--
*******************************************************************************
* Leigh Dodd (Sun System Administrator)  |      Three Steps to Heaven         *
* University of Sussex                   | 1). C.B.T. ----- Passed            *
* Brighton, England.                     | 2). Part 2 ----- Passed            * 
* INTERNET: leighd@eaps.susx.ac.uk       | 3). Gota GPz550 and Riding To HELL *
*******************************************************************************

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 1993 15:50:51 GMT
From:      hunenr@cis.corp.medtronic.com (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   Re: ping's maximum packet size

In article <1993Nov1.032906.8590@afterlife.ncsc.mil> ctkosti@afterlife.ncsc.mil (Chris Kostick) writes:
#I'm pinging on an ethernet network. From my understanding of the
#protocols, if I have 4K of data to send, then IP can handle that. It just
#fragments the data. Isn't that how NFS works? By default 8K UDP packets
#are sent. IP has no problem fragmenting that. You say I can't convince
#SunOS to fragment. Well, if send the 2000 bytes and then monitor the network,
#it's fragmentmented into two packets. So obviously I can, my question
#is why the 2000 byte limitation?

It may be that DON'T-FRAGMENT is set on ping packets (which makes sense
to me). In that case the maximum ping size equals the minimum MTU on any
part of the path.

Regards,
-Roger

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Nov 1993 16:27:32 GMT
From:      cawilco@afterlife.ncsc.mil (Chris A. Wilcox)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip
Subject:   Re: which type of fiber to use?

In article <1993Oct26.082922.6626@dxcern.cern.ch>,
Brian Carpenter   CERN-CN <brian@dxcern.cern.ch> wrote:
>
>Craig,
>
>What's hypothetical? These are exactly the questions we've been
>asking for two years. Our current answers are:
>
>Between buildings: multi-mode up to 1 km; single mode for longer
>distances.
>
>Inside buildings: multi-mode up to the closet
>		  UTP 5 to the desk (plus empty tubes!!!)
>
>We are betting on FDDI over UTP5 and ATM over UTP5. The empty tubes
>are vital, in case we are wrong.
>
>Regards,
>	Brian Carpenter CERN, brian@dxcern.cern.ch
>			voice +41 22 767 4967, fax +41 22 767 7155

I would think that the expected rates you want to run between buildings
would also make a difference as to whether you use multimode or single
mode fiber. As an example, I don't think you could run an OC-48 SONET
trunk between buildings using multimode fiber. As a matter of fact, if
you are planning on using SONET, you must use single mode fiber (I have
heard that the ATM forum has defined a SONET interface using multimode
fiber, but as far as I know that has not been coordinated with any of
the "official" standards bodies such as ANSI or ITU (formerly CCITT)).

Sorry for the late response; I just got back from an ANSI meeting... :-)
-- 
Chris Wilcox                |"The guy sure looks like plant food to me"
Dept. of Defense            |                     Seymour and Audrey II
cawilco@afterlife.ncsc.mil  |                  'Little Shop of Horrors'
The views represented here probably aren't held by the DoD. Get over it.

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 93 16:36:45 GMT
From:      anils@ada.CS.ORST.EDU (Anil Srivastava)
To:        comp.protocols.tcp-ip
Subject:   UNIX based time servers...

I am looking for the ip address of a really accurate time server which
allows me to poll it for time and synch our Novell server's with it using
RDATE.NLM.  

Any help would be greatly appreciated.  I have a copy of Murkworks RDATE and
all I need is the ip address of a machine that allows me poll it for time.

Thanks....

PS: SInce I don't follow this news group regularly, responses via e-mail
would be REALLY appreciated :-)

-- 
Anil Srivastava                       
anils@research.cs.orst.edu

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Nov 1993 17:50:56 GMT
From:      sharmila@forge.Tandem.COM (Sharmila Podury)
To:        comp.protocols.tcp-ip
Subject:   Service port #s in inetd.conf???...



Does anyone know why the entries for each service
in the inetd.conf file do not contain the port numbers?
Is there a reason why one would not want to put the 
port numbers in inetd.conf?

Answers would be greatly appreciated.

Thanks.
 
-- 
PODURY_SHARMILA@Tandem.com

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 1993 17:56:44 GMT
From:      nessett@framsparc.ocf.llnl.gov (Dan Nessett)
To:        sci.crypt,mitre.crypt,alt.security,comp.protocols.tcp-ip
Subject:   ISOC Symposium on Network and Distributed System Security

ISOC Symposium on Network and Distributed System Security
---------------------------------------------------------

Program
-------

Wednesday, February 2

6:00 P.M. Ð 8:00 P.M.
  Registration and Reception 

Thursday, February 3

7:30 A.M.
  Continental Breakfast 
8:30 A.M.
  Opening Remarks 
9:00 A.M.
  Session 1:  Electronic Mail Security
                       Chair: Steve Kent (BBN)
  Certified Electronic Mail, Alireza Bahreman (Bellcore) and Doug Tygar 
    (Carnegie Mellon University), USA
  Privacy Enhanced Mail Modules for ELM, Selwyn Russell and Peter 
    Craig, Queensland University of Technology, Australia
  Management of PEM Public Key Certificates Using X.500 Directory 
    Service: Some Problems and Solutions, Terry Cheung, Lawrence 
    Livermore National Laboratory, USA
10:30 A.M.
  Break
11:00 A.M.
  Session 2: Panel: Public Key Infrastructure, Santosh Chokhani (MITRE), 
    Michael Roe (Cambridge University), Richard Ankney (Fischer, Intl.)
                       Chair: Miles Smid (NIST)
12:30 P.M.
  Lunch
2:00 P.M.
  Session 3:  Protocols
                       Chair: Tom Berson (Anagram Labs)
  Paving the Road to Network Security, or The Value of Small Cobblestones, 
    H. Orman, S. O'Malley, R. Schroeppel, and D. Schwartz, University of 
    Arizona, USA
  A Complete Secure Transport Service in the Internet, Francisco Jordan 
    and Manuel Medina, Polytechnical University of Catalunya, Spain
3:00 P.M.
  Break
3:30 P.M.
  Session 4:  Internet Firewall Design and Implementation
                       Chair: Jim Ellis (CERT)
  Inter-LAN Security and Trusted Routers, Pal Hoff, Norwegian Telecom 
    Research, Norway
  Trusted to Untrusted Network Connectivity:  Motorola Authenticatd 
    Internet Access -- MANIAC(TM), Bill Wied, Motorola, USA
  BAfirewall: A Modern Firewall Design, Ravi Ganesan, Bell Atlantic, USA
  WhiteHouse.Gov: Secure External Access and Service for the Executive 
    Office of the President, Frederick Avolio and Marcus Ranum, Trusted 
    Information Systems, USA
7:00 P.M.
  Banquet

Friday, February 4

7:30 A.M.
  Continental Breakfast
8:30 A.M.

  Session 5:  Panel: All Along the Watchtower: Experiences and Firefights 
    Managing Internet Firewalls, Brian Boyle (Exxon Research), Brent 
    Chapman (Great Circle Consulting), Bill Cheswick (AT&T Bell Labs), 
    Allen Leibowitz (Warner-Lambert), Marcus Ranum (TIS)
                       Chair: Frederick Avolio (TIS)
10:00 A.M.
  Break
10:30 A.M.
  Session 6:  Issues in Distributed System Security
                       Chair: Cliff Neuman (USC-ISI)
  CA-Browsing System -- A Supporting Application for Global Security 
    Services, Denis Trcek, Tomas Klobucar, Borka Jerman-Blazic, and Franc 
    Bracun, Jozef Stefan Institute, Slovenia
  The X.509 Extended File System, Robert Smart, CSIRO Division of 
    Information Technology, Australia
  Auditing in Distributed Systems, Shyh-Wei Luan (VDG, Inc.) and Robert 
    Weisz (IBM Canada Laboratory), USA/Canada
12:00 Noon
  Lunch
1:30 P.M.
  Session 7:  Authentication
                       Chair: Dave Balenson (TIS)
  The S/KEY(tm) One-Time Password System, Neil Haller, Bellcore, USA
  A Technique for Remote Authentication, William Wulf, Alec Yasinsac, 
    Katie Oliver, and Ramesh Peri, University of Virginia, USA
  Remote Kerberos Authentication for Distributed File Systems:  As 
    Applied to a DCE DFS-to-NFS File System Translator, Thomas Mistretta 
    and William Sommerfeld, Hewlett-Packard, USA
3:00 P.M.
  Break
3:30 P.M.
  Session 8:  Panel:  IP Security Alternatives, K. Robert Glenn (NIST), Paul 
    Lambert (Motorola), David Solo (BBN), James Zmuda (Hughes)
                       Chair: Russell Housley (Xerox)


PROGRAM CO-CHAIRS

Russell Housley, Xerox Special Information Systems
Robert Shirey, The MITRE Corporation

GENERAL CHAIR

Dan Nessett, Lawrence Livermore National Laboratory

PROGRAM COMMITTEE

Dave Balenson, Trusted Information Systems
Tom Berson, Anagram Laboratories
Matt Bishop, University of California, Davis
Ed Cain, U.S. Defense Information Systems Agency
Jim Ellis, CERT Coordination Center
Steve Kent, Bolt, Beranek and Newman
John Linn,  Geer Zolot Associates
Clifford Neuman, Information Sciences Institute
Michael Roe, Cambridge University
Robert Rosenthal, U.S. National Institute of Standards and 
           Technology
Ravi Sandhu, George Mason University
Jeff Schiller, Massachusetts Institute of Technology
Peter Yee, U.S. National Aeronautics and Space
           Administration

BEAUTIFUL SAN DIEGO

The Symposium venue is the Catamaran Resort Hotel, providing 7 acres of  
gorgeous surroundings, facing Mission Bay and only 100 yards from 
beautiful Pacific Ocean beaches. Spouses and family members can catch a  
convenient Harbor Hopper for a quick trip to Sea World. After the 
Symposium, plan to spend  the weekend  visiting La Jolla, the world 
famous San Diego Zoo or Mexico, only  30 minutes by car or Trolley.

A limited number of rooms have been reserved at the Catamaran for the 
very special rate of $77 single, $87  double. Reservations, on a space 
available basis, can be made by calling (800) 288-0770 and indicating you are  
attending the ISOC Symposium. Reservations must be made before Jan. 1, 
1994 to ensure  this rate.

CLIMATE

February weather in San Diego is normally very pleasant. Early morning 
temperatures average 51 degrees while afternoon temperatures average 67
degrees. Generally, a light jacket or sweater is adequate during February;
although, occasionally it rains.

TRANSPORTATION

San Diego International Airport is 10 miles (15 minutes) from the 
Catamaran  Hotel. Supershuttle operates a continuous service between the 
airport and the hotel: fare is $6.00. When you arrive at the airport, use the 
free Supershuttle phone. Taxi fare between the airport and the hotel is $20. 
The Catamaran charges $6 per day for parking.

REGISTRATION FEES

Postmarked        Subsequent
by Jan. 1         registration

$305              $350

REGISTRATION INCLUDES

- Attendance    - Symposium Proceedings
- Reception     - Banquet
- Luncheons     - Coffee Breaks

On-site registration is available Wednesday evening at the reception, and 
Thursday morning at the Symposium. For more information on 
registration and local arrangements contact Dan Nessett at (510) 422-4033 
or nessett@llnl.gov.

SYMPOSIUM REGISTRATION FORM

Name ________________________________________________

Affiliation__________________________________________

Name on Badge _______________________________________

Vegetarian Meals?____________________________________

Mailing Address _____________________________________

_____________________________________________________

_____________________________________________________


Area Code/Phone # ___________________________________

Email Address _______________________________________

Make check (credit cards not accepted) payable to SNDSS94. (Registration is 
not effective until payment is  received). Mail to: ISOC Symposium, C/O 
Belinda  Gish, L-68, Lawrence Livermore National Laboratory,  Livermore, 
CA. 94550.


-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Nov 1993 18:08:05 GMT
From:      davidb@ndl.co.uk
To:        comp.protocols.tcp-ip
Subject:   Deployment of RFC1058 X25 RR's

I'm interested in finding out out whether anyone has deployed 
the DNS resource record scheme for X.25 given in RFC1058.
Any experiences, examples or other tales of interest should 
be mailed to me please.

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 1993 18:13:31 GMT
From:      datkins@polaris.unm.edu (Drexel Atkinson CIRT)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   multiple subnets behind a router



  I posted a question last week about netmasking multiple subnets to look
as one.  I havent received any responses yet, but have a possible way to
do this and am looking for comments on potential problems.

Given:  a cisco router and a cluster of class B subnets(ie. netmask 255.0)

How do you get a couple of thousand addresses to look like a single net.

Use 8 subnets beginning on say:  

	x.x.8.yyy
	x.x.9.yyy
	x.x.10.yyy
	x.x.11.yyy
	x.x.12.yyy	  
	x.x.13.yyy
	x.x.14.yyy
	x.x.15.yyy

  With the following environ:

	A --- Cisco ---T/1 (internet)

  where A is a group of systems(actually a unix cluster).


Set broadcast to be: 255.255.15.255
Set netmask on router to be: 255.255.255.0 (ie. same as on the remainder of 
						the class B)

Set netmask on systems in area A to be: 255.255.248.0 

Does anyone see any problems with doing this.  It seems there may be a problem
with route updates since there would be multiple network interfaces behind the
router.  There would be a couple of different ethernet cards and an fddi ring.
Comments.
 
	-------------------------------------------------------------------------
    Drexel Atkinson 			datkins@unm.edu
    Systems Programmer			CIRT-ACS  University of New Mexico  
---------------------------------------------------------------------------
    

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Nov 1993 18:14:15 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: NetBIOS over TCP/UDP and IP over NetBIOS ???

In article <1993Oct27.131624.16356@newstand.syr.edu> fkyu@top.cis.syr.edu (Fang-Kuo Yu) writes:
>
>RFC1001 and RFC1002 define 'Protocol standard for a NetBIOS
>service on a TCP/UDP transport'.
>
>RFC1088 defines 'Standard for the transmission of IP datagrams
>over NetBIOS networks'.
>
>As a result, we can get a configuration, such as,
>
> 'Application -> NetBIOS -> TCP/UDP -> IP -> NetBIOS -> ...'
>
>in a single host?!
>
>I feel comfortable about RFC1001 and RFC1002. But, why we need 
>RFC1088?

If you have a TCP/IP network and you want to talk using the NetBios
API between machines, you use RFC1001/2.

If you have two machines already talking through the NetBios API and
you want to connect them with TCP/IP, you can use RFC1088.

The fact that you could run RFC1001/2 on top of RFC1088 (on top of
RFC1001/2...) is just a curiousity of very little practical interest.
If two machines are talking TCP/IP directly, there'd be no reason to
connect them again with TCP/IP on top of NetBios.  (You can construct
legitmate configurations that include such recursion in parts of the
path, but I doubt any would actually come up in real life.)

I don't really knowing what's going on in the world of NetBios, buy
I'd guess that RFC1088 is becoming less and less interesting as more
and more machines talk TCP/IP directly on the physical network.

						don provan
						donp@novell.com

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Nov 1993 18:26:35 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: definition of 'internet'

In article <18822@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
>Umm, at least the way I've heard it used, *the* Internet refers only to
>those machines connected via TCP/IP.
>
>I would be nice if somebody could come up with a name for the set of all
>machines that can exchange email

In The Internet, it's been traditional to refer to the entire email
domain as the internet, with a lower case "i".  Kind of fitting, I
think: "the internet" is just a noun, like "the sky".

					don provan
					donp@novell.com

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Nov 1993 18:36:18 GMT
From:      bruce@cortex.elekta.com (R. Bruce Rakes)
To:        comp.protocols.tcp-ip
Subject:   Re: definition of 'internet'

guy@Auspex.COM (Guy Harris) writes:

>>>I have always called the Internet: "A network of interconnected networks
>>>using TCP/IP"
>>>
>>    Or uucp, or kermit, or......
 
>Umm, at least the way I've heard it used, *the* Internet refers only to
>those machines connected via TCP/IP.
 
>I would be nice if somebody could come up with a name for the set of all
>machines that can exchange email, which is what I assume you are
>referring to (there already *is* a name for the set of all machines that
>can exchange netnews - "USENET").

I have heard the expression "Outernet" to include all other networks
and/or protocols that can xchange email w/ the internet.
-- 
R. Bruce Rakes, Software Systems Manager
Elekta Instruments, Inc.  8 Executive Park W, Suite 809, Atlanta, GA 30329
Voice:(404)315-1225 FAX:(404)315-7850 email: bruce@elekta.com
 

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Nov 1993 18:56:28 GMT
From:      visser@convex.com (Lance Visser)
To:        comp.protocols.tcp-ip
Subject:   Re: ping's maximum packet size

In <1993Nov1.032906.8590@afterlife.ncsc.mil> ctkosti@afterlife.ncsc.mil (Chris Kostick) writes:


+>I'm pinging on an ethernet network. From my understanding of the
+>protocols, if I have 4K of data to send, then IP can handle that. It just
+>fragments the data. Isn't that how NFS works? By default 8K UDP packets
+>are sent. IP has no problem fragmenting that. You say I can't convince
+>SunOS to fragment. Well, if send the 2000 bytes and then monitor the network,
+>it's fragmentmented into two packets. So obviously I can, my question
+>is why the 2000 byte limitation?

	The ping source I have access to has a #define in it for
the maximum packet size.  There is no good reason.  I have upped
it to 60k occasionally for hippi testing.

	There is a bad reason for leaving it at 2k though.  If you
send enormous icmp packets (10k+) to certain systems
over ethernet, you can crash them.






-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 1993 19:20:34 GMT
From:      rawn@lead.aichem.arizona.edu (Rawn Shah)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.answers,news.answers,comp.sys.mac.comm
Subject:   NFS & TCP/IP FAQ for PCs & Macs [part 01/06]

Archive-name: pcnfs-faq/part1
Last-modified: 1993/10/28
Version: 1.5


Back again from the blue. Here's version 1.5. 

Disclaimer:
	The material in this FAQ is not based on preferrence for any
one product. All questions have been drawn from the archives of
comp.protocols.nfs starting from the very beginning. To all distributers/ 
software houses: If you feel that there is unfair representation of your
product in this list please mail me at:
	rawn@rtd.com	or
	rawn@xray1.chem.arizona.edu

or call:
	(602) 318-0696 [US]

I have to admit that there is one bias. All addresses or phone numbers which
do not state which country they are in, are in the US. I've been pretty 
oblivious about that.

NOTE: If you use this FAQ list and decide you like a product listed here
enough to purchase it, please mention where you got this information to the
product seller. Thank you.

Rawn Shah
RTD Systems & Networking, Inc.
Tucson, AZ

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

*. This FAQ

*-1.   What topics does this FAQ cover?
*-2.   Where can I get this FAQ?
*-3.   Who helped write this FAQ?
*-4.   Who maintains this FAQ?
*-5.   Who maintains comp.protocols.nfs?
*-6.   Where are the archives for comp.protocols.nfs?
*-7.   Trademarks and Registered names.
*-8.   What do the -, + and * before the questions mean?
*-9.  *Whats up and coming in the next issue of the FAQ list?

The real FAQ:

A. Basics

A-1.   What is NFS?
A-2.   What is (PC)NFS?
A-3.   Where can I get (PC)NFS for my DOS system?
A-4.   Where can I get (PC)NFS for my MS-Windows system?
A-5.  +Where can I get (PC)NFS for my Macintosh system?
A-6.   What is PC-NFS as opposed to (PC)NFS?
A-7.   What is TCP/IP?
A-8.   What is telnet? What is ftp?
A-9.   What is a client? What is a server? Why do I need them?
A-10.  Where can I get (PC)NFS cheap/free/PD?
A-11.  What is SOS & SOSS? Where can I get it?
A-12. +Are there any free NFS clients available for DOS?
A-13.  What is SLIP?
A-14.  What is PPP?

B. Setup

B-1.  *What are the different types of drivers available?
B-2.  -What are "shim"s? What shims are available?
B-3.   What are packet drivers? Where do I get them?
B-4.   Can I use packet drivers with (PC)NFS?
B-5.  +Can I run (PC)NFS over SLIP?
B-6.   Can I run (PC)NFS at the same time as Netware?
B-7.   Can I run (PC)NFS at the same time as CUTCP or NCSA Telnet?
B-8.   Can (PC)NFS run with NDIS drivers?
B-9.  +Can I use (PC)NFS to mount a diskless PC from a remote server?
B-10.  Can (PC)NFS run over token ring?
B-11.  Can I run PC-NFS with my 3C509 Etherlink III card?
B-12.  Can I run PC-NFS slip at higher baud rates than 9600?
B-13.  Can I access an MSCDEX CD-ROM with PC-NFS?
B-14.  Can I run NDIS over Packet drivers?
B-15. *How does ODI compare to NDIS?

C. Server 

C-1.   What is pcnfsd? What is pcnfsdv2?
C-2.  +Where can I get pcnfsd for my server system?
C-3.  -What is lockd?
C-4.   How can I test NFS performance?
C-5.   What is NHFSSTONES? Where can I get it?
C-6.  -What will help my server increase performance?
C-7.   How many nfsd's & biod's should I run on my server?
C-8.   What is asynchronous I/O? How can I modify my NFS server system to use
       asynchronous I/O?
C-9.   What is a good NFS server?
C-10.  What is LADDIS?
C-11. -What is XRemote & LBX?

D. Applications

D-1.  +Where can I get mail with (PC)NFS?
D-2.   Where can I get news with (PC)NFS?
D-3.   Where can I get an FTP server?
D-4.   Where can I get rwalld for (PC)NFS?   [May be removed, please read]
D-5.   Where can I get a INT-14 redirector for (PC)NFS?
D-6.   Where can I get YPPASSWD for PC-NFS?
D-7.   Where can I get IBM 3270 terminal for (PC)NFS?
D-8.   Where can I get an X-Windows server for (PC)NFS?
D-9.  -Where can I get a calender/scheduling program for (PC)NFS? 
D-10. +Where can I get a database that works with (PC)NFS?
D-11.  Where can I get a WAIS client for (PC)NFS?
D-12. +Where can I get an archie for (PC)NFS?
D-13. +Where can I get a gopher client for (PC)NFS?
D-14. +Where can I get a WWW (World Wide Web) client for (PC)NFS?
D-15.  Where can I get X25 for (PC)NFS?
D-16.  Where can I get NEWGRP.EXE for PC-NFS?
D-17.  Where can I get AUTOCONF for PC-NFS?
D-18.  Where can I get a backup utiliy for (PC)NFS?
D-19.  Which (PC)NFS packages support DNS [named]?
D-20.  Where can I get a traceroute program?
D-21. +Where can I get an LPD program?

E. Problems & General Q&A

E-1.  -How can I load (PC)NFS into DOS high memory?
E-2.   Can I use DNS instead of NIS with PC-NFS?
E-3.   Why do some versions of (PC)NFS not follow symbolic links?
E-4.   PC-NFS v4.0 has trouble with Cntl-S, Cntl-Q.
E-5.   PC-NFS v4.0 has trouble with redrawing the window while in MS-Windows.
E-6.  +PC-NFS v4.0 doesn't allow me to access the local printer when I have
       network printers.
E-7.   I cannot delete any file that PC-NFS makes with a ~ (tilde) in it.
E-8.   PC-NFS says that it cannot open any more files even when the limit in 
       autoexec.bat is set higher.
E-9.   Can (PC)NFS mount file systems which are bigger than 2 GB?
E-10.  What is NFS/TCP? Will it work with my NFS?
E-11. +What is PKTD.SYS? Where can I get it?
E-12.  How can I run Novell Netware (tm) 3.xx at the same time as (PC)NFS
       using NDIS?
E-13. -How many PC's can work with a single PC-NFS server?
E-14.  Is it possible to modify the read & write buffer sizes in (PC)NFS?
E-15.  How can I install Ethernet boards not supported by (PC)NFS?
E-16. *In postscript files I sometimes get a ^D before the header from my
       programs. How do I get rid of it?

F. Programming 

F-1. +Is there a toolkit for (PC)NFS programming? Whats the latest version
      and where can I get it?
F-2.  What is the Windows Sockets API (winsock)? Where can I get it?
F-3.  What is the latest version of the NFS protocol?
F-4.  What happened to version 3 of the NFS protocol?
F-5.  What is the current RPC version? Where can I get it?
F-6.  Where can I get the RPC definition for PCNFSD?
F-7.  What are RFC's? What RFC's describe the NFS protocol? Where can I get
      these RFC's? 
F-8.  How can I tell if a file is NFS mounted from a server?

G.  Product Features Comparisons

G-1. +Driver support comparison chart of different products.
G-2. +Protocol support comparison chart of different products.
G-3. +MS-Windows applications and support chart of different products.
G-4. +Utilities available with different products.
G-5. +Telnet features of different products.
G-6. +TCP/IP package compability with other network protocols.
G-7.  Features of different X-windows products.

H.  Information Sources

H-1.  Chest - Council for Higher Education Software Transfer [UK]
H-2.  X/Open
H-3. +Books
H-4.  Related Papers (published)
H-5. +Popular FTP sites
H-6.  Related FAQ's, USENET lists, mail lists.
H-7. *Glossary.

W.  Third-Party Email Software

W-1.   CliqAccessories		Quadratron Systems
W-2.   Higgins Group Prod sw	Enable Software
W-3.   Linkage			Concentric Technologies
W-4.   OpenMail			Hewlett-Packard
W-5.   PathWay Messenger	The Wollongong Group.
W-6.   PC-Eudora		Qualcomm Software.
W-7.   SelectMail		SunSelect

X.  X-Windows Software

X-1.   eXceed  			Hummingbird Software Ltd.
X-2.   eXcursion  		DEC
X-3.   eXodus  			White Pines Software.
X-4.   Micro X-Lite   		StarNet Communications Corporation.
X-5.   MultiView/X  		JSB Corporation
X-6.   PC-Xware & PC-Xview  	NCD, Inc.
X-7.   PC X-server & PC Link  	XLink
X-8.   PC-Xsight 		Locus Computing Corp.
X-9.   PC DECWindows Motif  	DEC
X-10. -Reflection X		Walker, Richer & Quinn
X-11.  X Appeal			Xtreme s.a.s.	
X-12.  Xoftware  		AGE Logic, Inc.
X-13.  Xvision  		VisionWare Soft, Inc
X-14.  X-windows for OS/2  	IBM

Y.  Other Third Party & Related Software

 Server Products:
Y-1.   eNFS  			INTERSTREAM
Y-2.   Multinet  		TGV, Inc.
Y-3.  -DEC TCP/IP  		Digitial Equipment Corp.
Y-4.  -NHFSSTONE  		Legato
Y-5.  -PrestoServe  		Legato
Y-6.   SOSS 			Rich Braun
Y-7.   TCPWare for VMS  	Process Software Corp.

 Other software:
Y-9.  -WinTrumpet/Trumpet	Peter Tatam.
Y-10. -WinVN 
Y-11. -Cello
Y-12.  MacPPP			


Z. TCP/IP & NFS Products

Z-1.   AIR for Windows  	SPRY, Inc.
Z-2.   BW-NFS  			Beame & Whiteside, Inc.
Z-3.   Chameleon NFS  		NetManage
Z-4.   CU/TCP  			Clarkson University/Rutgers University
Z-5.   Distinct TCP  		Distinct Corp.
Z-6.  -LAN Manager TCP/IP  	Microsoft Corp.
Z-7.   LAN Workplace NFS  	Novell, Inc.
Z-8.   NCSA Telnet  		Nat'l Center for Supercomputing Applications.
Z-9.   NFS/Share  		Intercon, Inc.
Z-10.  NS & ARPA Services  	Hewlett-Packard, Inc.
Z-11. +Pathway Access DOS/Win  	The Wollongong Group.
Z-12.  PathWay Access OS/2	The Wollongong Group.
Z-13.  PC-NFS  			SunSelect Inc.
Z-14.  PC/TCP  			FTP Inc.
Z-15.  Reflection 		Walker Richer & Quinn, Inc.
Z-16.  SuperTCP 		Frontier Technology, Corp.
Z-17.  TCP/IP for DOS  		IBM
Z-18. -TCP/IP for OS/2  	IBM
Z-19.  TCP/Open  		Lanera Corp.
Z-20.  TTCP  			Turbosoft Pte. Ltd.
Z-21.  WATTCP			Erick Engelke
Z-22.  WinQVT  			QPC Software, Inc.

Z-23. *Fusion 			Pacific Softworks, Inc.
Z-24. *PathWay Access for Mac	The Wollongong Group.
Z-25. *ICE/TCP			James River Group
Z-26. *Piper/IP			IPswitch, Inc.


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

*-1.  What topics does this FAQ cover?

This Frequently Asked Questions list covers questions on commonly available
NFS products and related products and topics running on PC systems and
Macintosh systems. The original section of topics has increased so much that
I've expanded them into separate sections as well. The topics now covered
are:  

        A. Basics - general questions on what NFS, (PC)NFS, & TCP/IP are.
        B. Setup  - questions on setting up these products
        C. Server - questions on the PCNFSD server & server system
		    administration 
        D. Applications - commercial and public-domain applications which
                    will work with these systems.
        E. Problems & General Q&A - questions, problems and general info on 
                    (PC)NFS maintainence.
        F. Programming - Programming toolkit and NFS & RPC related
                    programming questions.
	G. Product Features Comparions - This compares the features of
		    the TCP/IP packages.
	H. Information Sources - This is a list of organizations or sources
	    	    of information on NFS, XDR, Winsock, lists, etc.
	W. Third Party Email - This is a list of commercial and shareware
		    email packages
	X. Xwindows Packages - This is a list of commercial Xwindows
		    software 
	Y. Third Party & Related Software - Third party products such as
		    server software, news, etc.
        Z. TCP/IP & NFS products - Commercial and public domain/shareware
		    TCP/IP & NFS products.

NOTE: Throughout this document all vendors are referred to by their entry
      number in section Z, eg.
            Z-X refers to entry X in section Z.

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

*-2.  Where can I get this FAQ?

This FAQ is available on the USENET newsgroup, posted once in every two
weeks and also on the following FTP sites:
	seagull.rtd.com: /pub/tcpip/pcnfs.FAQ
	ftp.york.ac.uk: /pcnfs/FAQ/pcnfs.FAQ

As of August:
	bcm.tmc.edu: /nfs
	src.doc.ic.ac.uk
	ftpserver.massey.ac.nz

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

*-3.  Who helped write this FAQ? 

The information in the FAQ is a collection generated from my personal
knowledge and with the help of the following people who I'm very grateful
to: 

Geoff Arnold	(geoff@east.sun.com)		Sun Microsystems
Farid Rahmi	(fr@sunbim.be)		        Sunbim (?)
Marty Udescci	(martyu@twg.com)		The Wollongong Group
Chip Sparling	(chip@ftp.com)			FTP Software
Fred Whiteside	(fred@bws.com)			Beame & Whiteside 
C. J. Sacksteder, et. al.  (cjs@psuvm.psu.edu)	Penn State Univ.
Dean 		(Dean@frontiertech.com)		Frontier Tech.
Winifred Crowther				Beame & Whiteside
Kenneth Adelman	(Adelman@tgv.com)		TGV, Inc.
Bruce Miller	(Miller@tgv.com)		TGV, Inc.
John Keyes	(john.keyes@east.sun.com)	Sun Microsystems
Vernon Schryver	(vjs@sgi.com)			SGI, Inc.
Marc Wiz	(mwiz@austin.ibm.com)		IBM Corp. (The Core Group)
Dave Fetrow	(fetrow@biostat.washington.edu) Univ. of Washington
Fritz Mueller	(fritz@netmanage.com)		NetManage, Inc.
Zvi Alon	(zvi@netmanage.com)		NetManage, Inc.
Brian Pawlowski	(beepy@ennoyab.eng.sun.com)	Sun Microsystems
Edmund J. Sutcliffe	(edmund@york.ac.uk)	Univ. of York
Erick Engelke	-				Independent
Giovanni Novelli 				Xtreme s.a.s
Danny Thomas     (vthrc@mailbox.uq.oz.au)	Independent
Thomas Dwyer III (tomiii@mtu.edu)		Independent
Geert Jan de Groot      (geertj@ica.philips.nl)	Philips
Francis K. Selkirk      (fks@ftp.com)		ftp Software Inc.
Alan Arndt	 (aga@Comtech.com)		Comtech Labs
Gavin Longmuir   (gavin@sorokin.anu.edu.au)     Australian Nat'l Univ.
George Brad Weiner      (sales@age.com)		AGE Logic, Inc.
George Stump					The Wollongong Group, Inc.
Bob MacFadgen	(bob@ipswitch.com)		Ipswitch, Inc.

Special thanks to:
Edmund Sutcliffe & the University of York for providing an FTP site and his
endless help.

Geoff Arnold for placing the FAQ on the comp.protocols.nfs FTP sites.

C.J.Sacksteder for allowing the use of portions of his document,
"Features of TCP/IP Packages for DOS and Windows" 

Brian Pawlowski for allowing the use of his list of bibliographic entries on
papers for NFS, XDR, and RPC.

To any others that I may have forgotten, you have the right to look me up
in Tucson and demand a beer out of me. 

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

*-4.  Who maintains this FAQ?

This FAQ is maintained by Rawn Shah. Any additions, clarifications,
modifications and other changes to the FAQ should be directed to me. You can
reach me at any of the following addresses (in order of preferrence):
        rawn@rtd.com
        rawn@xray1.chem.arizona.edu

You can also contact me at the following postal address:

Rawn Shah
RTD Systems & Networking, Inc.
2601 N. Campbell Ste 202B, 
Tucson, AZ 85719
USA

or the following US phone numbers: 
Phone: (602) 318-0696
FAX:   (602) 318-0695

This FAQ list may not be modified or redistributed under any other name
other than that reserved by the author. You may reproduce the FAQ and
distribute it freely as long as you maintain the original author. 

-------------------------------------------------------------------------------
        
*-5.  Who maintains comp.protocols.nfs?

This is an unmoderated USENET newsgroup although there are regular posters
who will be able to help with your questions related to (PC)NFS products.

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

*-6.  Where are the archives for comp.protocols.nfs?

The archives for comp.protocols.nfs are kept at the following FTP sites:
	bcm.tmc.edu
	src.doc.ic.ac.uk
	ftpserver.massey.ac.nz

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

*-7.  Trademarks and Registered names.

AppleTalk, LocalTalk and Macintosh are registered trademarks and MacX and
  A/UX are trademarks of Apple Computer Corp. 
VMS, and OpenVMS are registered trademarks of Digital Equipment Corp.
ONC, NFS, NIS & PC-NFS are registered trademarks of Sun Microsystems
  Computer Corp. 
PC/TCP and Interdrive are trademarks of FTP Software Inc.
BW-TCP and BW-NFS are trademarks of Beame & Whiteside Software, Ltd.
IBM, IBM PC, AIX & OS/2 are registered trademarks and LAN Server is a
  trademark  of International Business Machines, Inc. 
Chameleon, ChameleonNFS and Newt are trademarks of NetManage Corp.
DEC, VMS, OpenVMS, DECnet are registered trademarks and eXcursion and
  DECwindows are trademarks of Digital Equipment Corporation 
TSSNet is a trademark of Thursby Software Systems, Inc.
PathWay, PathWay Access & PathWay Client NFS are trademarks of The
  Wollongong Group 
SuperTCP is a trademark of Frontier Technologies, Inc.
XVision is a trademark of VisionWare Software Ltd., UK.
eNFS is a trademark of INTERSTREAM, Inc.
AIR is a trademark of SPRY, Inc.
ODI and LAN WorkPlace are trademarks of Novell, Inc.
NDIS, MS-DOS and MS-Windows are registered trademarks and LAN Manager is a
  trademark of Microsoft Corp.
MOTIF is a trademark of the Open Software Foundation, Inc.
WINQVT/NET and WINQVT/NFS are trademarks of QPC Software Corp.
HCL-eXceed, HCL-eXceed Plus, and HCL-eXtend are trademarks of Hummingbird
 Software, Ltd.
TCPOpen is a trademark of Lanera Corp.
UNIX is a trademark of Unix Systems Laboratories
Multinet is a trademark of TGV, Inc.
PC-Xware & PC-Xview are trademarks of NCD, Inc.
PC-Xsight is a trademark of Locus Computing Corp.
Multiview/X is a trademark of JSB Corporation
PC X-server & PC-Link are trademarks of XLink Corp.
eXodus is a trademark of White Pines Software.
CU/TCP is a trademark of Clarkson University and Rutgers University
NCSA Telnet is a trademark of the National Center for Supercomputing
  Applications.
Micro X-Lite is a trademark of StarNet Communications Corp.
AIR is a trademark of SPRY, Inc.
ICE.TCP is a trademark of the James River Group, Inc.
Piper/IP is a trademark of Ipswitch, Inc.

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

*-8.  What do the -, + and * before the questions mean?

The - is used to signify that the question is out of date or has no
information related with it.

The + is used to signify that the question has been recently updated with
new information or corrections have been made to the answer.

The * signifies the question as a new one as of the current FAQ version

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

*-9.  Whats up and coming in the next issue of the FAQ list?

The FAQ is expanding at good rate and I'm still waiting for it to level off.
Coming issues should include:
	- a few more TCP products (VxDTCP, DLink, etc)
	- a better description of NFS 3 once I finish reading it.
	- Cello, trumpet, MacWAIS, etc.

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

A. Basics
=========

A-1.  What is NFS?

Network File System (NFS) is file system that will mount remote file systems
across homogenous and heterogenous systems. NFS consists of a client and
server systems. An NFS server can export local directories for remote NFS
clients to use. NFS runs over IP using UDP (commonly). There are NFS
implementations that will work using TCP as the network transport service.
NFS was originally developed by Sun Microsystems Computer Corp. (SMCC) and
is now part of their Open Network Computing (ONC) initiative. NFS has been
accepted by the IETF in certain RFC's (see question F-X) as a standard for
file services on TCP/IP networks on the Internet.

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

A-2.  What is (PC)NFS?

(PC)NFS is a generic term referring to all NFS systems running on IBM PC and
compatible systems as well as other Personal Computer systems as defined
upon by the X/Open Group.

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

A-3.  Where can I get (PC)NFS for my DOS system?

(PC)NFS for DOS systems is available from the following vendors:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Product Name    Vendor                  Pricing                 Entry
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AIR		SPRY						Z-1
PC-NFS          SunSelect              *$435                    Z-13
BWNFS           Beame & Whiteside      *$395                    Z-2
PC/TCP          FTP Corp.              *$400                    Z-14
IBM TCP/IP	IBM						Z-17
LAN Manager TCP	Microsoft					Z-6
PathWay         The Wollongong Group   *                        Z-11
SuperTcp        Frontier Tech.         *$495                    Z-16
LAN Workplace	Novell			$			Z-7

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

* means other pricings available see corresponding entry for product in 
  Section Z.

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

A-4.  Where can I get (PC)NFS for my MS-Windows system?

(PC)NFS for MS-Windows is available from the following vendors:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Product Name    Vendor                  Pricing                 Entry
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AIR		SPRY			$			Z-1
PC-NFS          SunSelect              *$435                    Z-13
BWNFS           Beame & Whiteside      *$349                    Z-2
Distinct 	Distinct Corp.					Z-5
TCPOpen		Lanera Corp.				        Z-19
PC/TCP          FTP Corp.              *$400                    Z-14
PathWay         The Wollongong Group   *                        Z-11
ChameleonNFS    NetManage              *$495                    Z-3
SuperTCP        Frontier Tech.                                  Z-16
WinQVT/Net      QPC Inc.                $40 (shareware)         Z-22
                                        $20 (student)    
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

* other pricings available; see corresponding entry for product in 
  Section Z.

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

A-5.  Where can I get NFS for my Macintosh system?

You can get NFS clients for Macintosh from:
	The Wollongong Group: PathWay NFS [Z-11]
	Intercon: NFS/Share [Z-9]

There are also packages for hardware gateways which will allow Macintosh
systems to NFS drive systems. Cayman systems puts out the GatorShare
software for their GatorBox and GatorStar series which gateway LocalTalk
based Macintosh systems onto an Ethernet and allow IP tunneling inside
Appletalk to reach external systems. GatorShare allows Macintoshs to mount
NFS disks as AFP (Apple Filing Protocol) volumes which are displayed as
remote drives on the Apple Chooser. Shiva & Fallaron have similar gateway
(DDP-IP) systems. 

IPT has a software only system that works in concert with one of the above
mentioned hardware systems that allow Unix systems to export disks as AFP
volumes. IPT's Partner is not in strict sense an NFS system. It implements
Appletalk on Unix systems and exports drives and printers as Appletalk ones.
CAP (Columbia Appletalk) is a public domain package which has similar
services. 

Work is currently in progress to produce a software based DDP-IP package
that will connect LocalTalk Macintoshes through a Mac system with both
LocalTalk & Ethernet interfaces to Ethernet based IP systems. Hopefully the
project will be completed before October. Initial prospects are to
distribute this as shareware.
	       
-------------------------------------------------------------------------------

A-6.  What is PC-NFS as opposed to (PC)NFS?

PC-NFS is a specific NFS product for PC systems from SunSelect. PC-NFS is a
registered trademark and so should NOT be used as a generic term describing
all NFS systems on PC's. (PC)NFS is a generic term describing NFS systems on
PC's as decided upon by the members of X/Open.

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

A-7. What is TCP/IP?

Transmission Control Protocol/Internet Protocol (TCP/IP) is the main
transport protocol used on the Internet for connectivity and transmission of
data across heterogenous systems. It is an open standard which is available
on most Unix systems, VMS and other minicomputer systems, many mainframe &
supercomputing systems and some microcomputer & PC systems. 

TCP/IP is a software solution for network connectivity. There is little
assumption on the hardware system used for actual physical connections. The
most common hardware solution is Ethernet, but TCP/IP will also run on
Token-Ring, AT&T StarLAN, microwave & spread spectrum systems , LocalTalk
(needs a gateway), Serial lines (modems, serial connections) and other
systems as well. 

To run TCP/IP on a system you first need a hardware driver. On Macintosh
systems, the hardware drivers are built into the system or is provided by
the board manufacturer. On a PC system, there are different types of
hardware drivers available both commercially and via public domain/shareware
including the Packet driver specification by FTP Software, Inc., Microsoft's
Network Device Interface Specification (NDIS), & Novell's Open Datalink
Interface (ODI). Drivers for OS/2 systems are available from IBM and/or the
board manufacturer (if they support OS/2).  If a driver is not available for
your hardware, look for a shim. This is a software device which translates
between two driver specifications. There are shims for ODI-on-NDIS,
NDIS-on-Packet driver. ODI-on-Packet driver, etc.  usually publically
available.

You then need a TCP/IP stack. This is package specific usually comes with
every product. Each such stack has its own requirements for hardware
drivers. you must find a combination of driver & TCP/IP stack which is
compatible with your hardware & system. Macintosh's do not have a problem
since most Macintosh systems use the MacTCP stack which is available from
Apple and is provided with most if not all Macintosh TCP/IP packages. PC
systems have something close to a standard in TCP applications called the
Windows Sockets API (Winsock). [Note: This is not specific only to TCP/IP it
is a general standard for networking on PC irrelevant of the transport
protocol. Hence, there may be versions for NetBEUI, IPX, etc.]. The Winsock
API is avaialble in 16 bit and 32 bit versions. The 32 bit versions are for
Windows NT systems. Winsock is implemented in Dynamically Loaded Libraries
or DLLs. Currently work is under way to develop a freeware Winsock DLL but
many commercial versions are available.

With the TCP/IP stack in hand, you then need all the TCP/IP application
programs such as Telnet, FTP, mail, etc. Just about every TCP/IP package has
a corresponding set of applications although some do not provide all the
different applications available.

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

A-8. What is telnet? What is ftp?

Telnet & FTP are two TCP/IP applications for remote host access and remote
file transfer, respectively. Any host with a telnet client can connect to
any host with a telnet server. Any work done within a telnet session is
executed on the server host, thus for most intents and purposes your are on
the remote server, virtually. FTP clients can connect to FTP servers to
transfer files either direction. You can preserve the file contents
independent of the client and server hosts.

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

A-9.  What is a client? What is a server? Why do I need them?

A client application uses resources available on a remote site. This remote
site runs a server for this purpose. NFS is a client-server technology. You
need an NFS client to mount remote disks or directories. The server makes
these disks or directories available for other systems to use. For example,
If you have an NFS client on your PC, you can mount remote drives on your 
PC. However, if that PC does not have an NFS server, then you cannot make it
possible for other systems to use your local drive.

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

A-10.  Where can I get (PC)NFS cheap/free/PD?

There are currently no free or shareware NFS _client_ packages
available. Please read [A-X].

SOSS [Y-6] is a public domain NFS _server_ available by FTP.

There are, however, a few different TCP/IP packages available as shareware
and freeware such as WATTCP, NCSA Telnet, CU/TCP, WinQVT (shareware). Please
see the product list in section Z for appropriate referrences.

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

A-11. What is SOS & SOSS? Where can I get it?

SOS (stan's own server) is the original NFS server developed by See-Mong Tan
and is a public domain nfs server.

SOSS (son of stan's server) is a souped up version of SOS developed by Rich
Braun, et al with better performance capabilities.

SOS is still available although it is advised that you use SOSS when
necessary. SOSS is available at the following site:
	grape.ecs.clarkson.edu

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

A-12.  Are there any free NFS clients available for DOS?

There was once a project at the Univ. of Maryland which made an NFS client
for free distribution but is now no longer available. 

There have also been reports that NCSA Telnet may come out with an NFS
client in the future but so far there hasn't been any further news on that.

There is a client being developed for the WATTCP package by Micheal Durkin.
This will be released as shareware ($15) in executable format only. Source
code may be available depending on the authors preference.

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

A-13.  What is SLIP?

Serial Line Internet Protocol (SLIP) is a standard on the Internet for
serial line and modem connectivity between two systems. This allows any one
SLIP client to connect to a SLIP server to provide connectivity between
different IP hosts. Both systems must have TCP/IP stacks running. Certain
SLIP packages even allow the SLIP client to act as a gateway between a local
network and a remote network, ie. all machines on the local network can
connect automatically over the SLIP line to remote systems and vice versa.
SLIP packages are available for PC systems. See G-1.

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

A-14.  What is PPP?

PPP (Point-to-Point Protocol) is a direct link protocol which works over
serial lines and direct links similar to SLIP. Overall it gets more
throughput than SLIP. The remote host needs to accept PPP connections and
the local host should act as a client. 

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

Section B. Basics
=================

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

B-1. What are the different specification types of drivers available?

The following are common specification types of drivers available:

A. Packet drivers - freely available set of drivers on the net maintained by
	ftp Software and also in part by Russell Nelson of Crynwyr.

B. NDIS v2.0 & v3.0 - Network Device Interface Specification developed by
	Microsoft and 3Com. Version 2.0 is the current version for
	MS-Windows and Windows for Workgroups. Version 3.0 is the new
	specification for MS-Windows NT.

C. ODI - Open Driver Interface developed by Novell, Inc. 

D. SLIP, PPP - These are more protocol specifications for serial and
	distance links. Both are defined in the Internet RFCs. PPP is
	described initially in RFC 1172 with related descriptions in 1331-1334,
	1376-1378, and several newer ones. SLIP is described in RFC 1055.

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

B-3.  What are packet drivers? Where do I get them?

Packet drivers are the link between your Network interface card and your
TCP/IP protocol stack (of each application). They are a low level driver
specification with support for many different Network interface cards. 

The packet driver specification is maintained by FTP Software and is
available from:
	vax.ftp.com:/pub/packet-d.*

Russ Nelson of Crynwyr, Inc. (nelson@crynwyr.com) also maintains many packet
drivers. He also maintains the FAQ available for packet drivers
on comp.protocols.tcp-ip.ibmpc. This FAQ can be received by ftp from the
following sites:
	seagull.rtd.com: /pub/tcpip/other-faqs/pktdrv.faq

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

B-4.  Can I run packet drivers with (PC)NFS?

Yes. See chart G-1 for compatibility with different packages.
	
-------------------------------------------------------------------------------

B-5.  Can I run (PC)NFS over SLIP?

Yes. See chart G-1 for availability in the different products for PC
systems. 

Macintosh systems can run NFS/Share from Intercon with the InterSLIP package
copyrighted & freely distributed by Intercon available from:
	ftp.intercon.com: InterCon/sales/InterSLIP1.0fc3.sea.hqx

This will run with MacTCP 1.1.1.

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

B-6.  Can (PC)NFS run with NDIS drivers?

Yes. See chart G-1 for availability in the different products.

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

B-7.  Can I run (PC)NFS at the same time as CUTCP or NCSA Telnet?

Yes. You need to run PKTMUX.EXE. This will multiplex connections between two
different applications using packet drivers. PKTMUX allows one to run
multiple TCP/IP protocol stacks.

There is also a version of CUTCP which runs over SunSelect's PC-NFS and is
available via ftp from:
	ftp.york.ac.uk:/pub/pc/pc-nfs/cutcp/CUTCP.ZIP

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

B-8.  Can (PC)NFS run with NDIS drivers?

Yes. Please look at chart G-1 for compatibility with different products.

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

B-9.  Can I use (PC)NFS to mount a diskless PC from a remote server?

Yes. The following products have this capability:
	PC-NFS
	PC/TCP
	BW-NFS
	AIR for Windows

PC-NFS can be installed partially onto disk to access network applications
like telnet, ftp, etc. placed on a remote server.

PC/TCP also has PROM chips for ethernet cards for diskless PCs to boot with
network services.

In Europe, BOOTP PROMs are available from Dirk Keoppen [dirk@incom.de].
These PROMs support a large number of Ethernet cards and works with many
versions of (PC)NFS including that from SunSelect, FTP Software, Novell and
Microsoft LAN Manager.

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

B-10.  Can (PC)NFS run over token ring?

Yes. See chart G-1 for availability in the different products.

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

B-11.  Can I use my 3C509 Etherlink III card with (PC)NFS ?

Yes. The 3C509 has both NDIS and ODI drivers shipping with the box. Trouble is
some are not where they are supposed to be. The NDIS drivers are in the following directory on the floppy :

A:\MSLANMAN.DOS\DRIVERS\ETHERNET

Also, a packet driver is obtainable for this card (also see B-1)

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

B-12 Can I PC-NFS SLIP at higher baud rates than 9600 ?

The built-in slip driver will not allow any higher speeds than 9600, but there
is a way around this. Instead of using SLIP.SYS, you can always configure
PC-NFS in packet driver mode (look for the PKTD.SYS shim) and use a shareware
slip driver than conforms to the packet driver specification. Ask archie
about SLIPPER.EXE or ETHERSL.COM.

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

B-13 Can I access an MSCDEX CD-ROM with PC-NFS ?

No, but you can fool your PC by using an 'MSCDEX simulator', i.e. a small
utility that will redirect the interrupt used by MSCDEX and return constant
values. Does not work will all the published CD's, but is worth the try.

Mounting an ISO9660 CDROM over NFS is not always sufficient to get full access
to the application residing on it. Some utilies refer to MSCDEX for various
reasons. So, can you use the NFS-mounted volume and still have full MSCDEX
access ? No, but you can fool your PC by using an 'MSCDEX simulator', i.e. a
small utility that will redirect the interrupt used by MSCDEX and return  
constant values. Does not work will all the published CD's, but is worth the 
try. These utils are obtainable from ftp.york.ac.uk (/pub/pc-nfs/CD-rom)

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

B-14.  Can I run NDIS over Packet drivers?

Yes. You can run packet drivers along with the DISPKT9.COM shim and run the
program as a generic NDIS driver. 

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

B-15.  Which is better NDIS or ODI?

After a small discussion, it seems that ODI is generally faster and it does
not need be to loaded in the config.sys which helps enormously during
debugging and development). 

Both NDIS and ODI are widely available with most Ethernet cards and many
Token-Ring cards as well. 

ODI however has one slight problem when it comes to development. Although it
is an "open" specification and is available via ftp, Russel Nelson of
Crynwyr pointed out that:

Message-ID: <744695828snx@crynwr.com>
"
The documentation for Novell's driver development kit is available
from dev_docs/lan_drv.  This should not be mistaken for a
specification of an "open" interface.  If you want to write an "ODI
driver" (that is, the thing that adapter manufacturers ship), you
must purchase the Lan Driver Development Kit for $7,000.  When I
suggested to Novell that they should document the LSL <--> MLID
interface, they seemed somewhat bemused, as if to say "Whyever would
you want that?? -- just buy the DDK!"

Apparently, there *is* no "ODI driver" spec -- Novell doesn't even
have an internal document for the LSL <--> MLID interface.
"

You can FTP the NDIS specification from:
	vax.ftp.com

You can FTP the ODI specification from:
	sjf-lwp.sjf.novell.com:/dev_docs/{lan_drv, pstacks}/*
	[email to Dave Murphy dmurphy@novell.com]

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

Section C. Server
=================

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

C-1.  What is pcnfsd? What is pcnfsdv2? What is BWNFSD?

PCNFSD is the server software run on remote systems for service access such
as User authorization and print services. PCNFSD is freely distributed. It
was originally designed for SunSelect's PC-NFS software package but has been
accepted by the X/Open committee as a semi-standard for (PC)NFS.

PCNFSDv2 is the current version of this server software.

BWNFSD is an alternate server package from Beame & Whiteside, Inc. which is
also freely distributable.

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

C-2.  Where can I get PCNFSD for my server system?

PCNFSD has been ported to many different platforms.  The following is a list
of FTP sites for the different versions:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Platform	    	Location
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
SunOS 4.x, Solaris,	bcm.tmc.edu				
Solbourne, 		src.doc.ic.ac.uk
NeXTStep		ftp.york.ac.uk:/pun/pv/pc-nfs/RPC.pcnfs/*
Ultrix 4.2		bcm.tmc.edu
IRIX/SYSV		sgi.sgi.com:/support/pcnfsd.sysV    [unsupported]
			ftp.york.ac.uk:/pub/pc/pc-nfs/RPC.pcnfsd/*
AIX 3.2			Call IBM and ask for PTF# U412556
AIX 3.2.1		Call IBM and ask for PTF# U419359
AIX 3.2.3		Call IBM and ask for PTF# U414701
MIPS platforms		ftp.york.ac.uk:/pub/pc/pc-nfs/RPC.pcnfsd/*
IBM MVS			Call IBM and ask for PTF# UY84244 [pcnfsd v1 only]
OpenVMS 5.5		DEC TCP/IP v3.0 [product]
SCO Unix v3.2		SCO NFS [product]
HP 9000 [HP-UX 9.x]	HP-UX NFS [product]
			
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

There is a combined version of PCNFSD v2 for the following systems: Sun,
Ultrix, MIPS, SGI, BSD, SVR4 which is available from
	ftp.york.ac.uk:/pub/pc-nfs/RPC.pcnfs/pcnfsd.tar.Z

BWNFSD (V3.0f) is available from:

	dorm.rutgers.edu: /pub/msdos/bws/bwnfsd
	ftp.bws.com: /pub/bw/bwnfsd

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


-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 1993 19:21:55 GMT
From:      rawn@lead.aichem.arizona.edu (Rawn Shah)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.answers,news.answers,comp.sys.mac.comm
Subject:   NFS & TCP/IP FAQ for PCs & Macs [part 02/06]

Archive-name: pcnfs-faq/part2
Last-modified: 1993/10/28
Version: 1.5


C-4.  How can I test NFS performance?

The following information does not contain information on LADDIS which is a
newer test suite for NFS systems. Please look at C-10 for information on
LADDIS. 

The following is a post from the archives from a while back which answers
this directly:

   As it turns out, there's a surprising amount of software floating around
that looks at NFS.  Such software includes:

	nfswatch -- curses-based promiscuous NFS monitor.  This program
		prints out a running tally of how many of each type of
		request comes in, and of which file systems are the most
		heavily used.  Nfswatch can be used to look at traffic to
		individual files, too.  This is anonymously FTPable from
		icarus.riacs.edu.

	server_stat -- a NFS monitor program that runs on Encore Multimaxes.
		This shows information on hosts, users, and NFS request
		types performed.  This is capable of talking to a
		rpc.srvstatd process on another machine, though I don't know
		of other machines that support the Encore srvstatd program.

	nfsstone -- the Encore NFS benchmark, as presented in:

		Shein, B., Callahan, M., Woodbury, P., NFSSTONE: A Network
		File Server Performance Benchmark, Usenix Summer 1989
		conference proceedings, pp 269-275.

		This is a synthetic benchmark load, with an empirically-
		determined mix of operations.

	nhfsstone -- the Legato NFS benchmark.  This is also a synthetic
		load generator, based again on a particular observed
		load mix.  You can get this by sending mail like:

			To: request@legato.com
			Subject: send nhfsstone

			path path_back_to_me

		I had some problems getting this, though I was ultimately
		successful.

	NetMetrix (formerly EtherView) -- 
		a Sun-based packet spy that is capable of doing some
		characterization of NFS load and response times.  This is
		a commercial product.  For more information, contact:

			Hewlett Packard, Network Test Division
			One Tara Blvd., Suite 403, Nashua NH 03062
			(603) 888-7000
			
	LANWatch -- another packet spy, from FTP Software, Inc.  This can
		filter out NFS traffic; I don't know what can be done with
		the packets though once they're filtered out.  For more
		information, call FTP at (800) 282-4FTP, or send mail to
		info@ftp.com.

	[ There's lots of other packet spies, too, and I suspect that most
	of them can do at least a little bit with NFS packets. ]

   The problem with most of the programs above (except for the synthetic
loads, to which this just doesn't apply, since they're not NFS monitors) is
that you don't get raw data points which you can then analyze.  You get the
data that the authors thought you might want...  and which might not be what
you really want.  There's much to be said for the approach of dumping traces
and lots of timestamps into a file, then providing (a) programs that analyze
such files, and (b) the format of the files, so that people can write their
own analysis programs.  On a PC-based packet spy, this is a hard thing to
do.

   There's a fair number of people (at the major NFS server vendors, Sun,
DEC, and a few universities) who are also poking around at the problem.
Some people are looking at filesystem activity tracers, which (in addition
to being interesting research on its own) could provide still more reams of
interesting statistics when combined with a NFS tracer.

   The consensus was that the best way to trace NFS operations is to do so
via a promiscuous packet spy.  Such an approach has many advantages.  First,
if you don't have kernel sources, you can still get useful information.
Second, because you don't instrument the server kernel, you don't have to
worry about influencing the experiment in adverse ways.  However, there's
some chance (depending on your hardware and on how fast you make your
software go) that you'll drop packets.  The 'hack the server kernel'
approach won't drop any requests, but violates the above constraints.  I
suspect that the best way to gather statistics is by using *both* methods of
measurement, then comparing the results.

   I was also referred (twice) to the SunOS 4.1 NFS implementation, and in
particular the adaptive NFS retransmission code therein.  These numbers might
be interesting to see, once 4.1 is more easily available.

   Of course, the usual Unix file access pattern (i.e., lots of short-lived
files in /tmp, most of which get written, then read once, then deleted)
information applies.  This was mentioned by several people; one reference
given was:

	Floyd, Rick, Short-Term File Reference Patterns in a UNIX Environment,
	    University of Rochester Department of Computer Science TR 177,
	    March 1986.

   Another good paper (with not much data on NFS, though) is:

	Lazowska et al, "File Access Performance of Diskless Workstations",
	    ACM TOCS, volume 4, number 3, August 1986, pp 238-268.
	
   Not a whole lot was said about general models of NFS access.  Most places
that had any models had derived them from some number of studies and from
the output of nfsstat, or so it seemed.  It does seem that there's a few
general trends, however.  There are some sites (including ours, I suspect)
that fall into the low-utilization, few write model, where the server rarely
satisfies more than one client's NFS requests in some given time slot.
There's also the high-utilization, many write model, which is what I'm sure
a lot of sites see.  One responder said that once one's clients have enough
memory, the buffer cache ends up reducing the number of random reads going
on, so one is left with the reads that happen to start up a new process, and
with writes.

   Those who talked about models generally said that they think there's
almost as many models as there are networks using NFS.  I suspect that this
is true, but that perhaps some useful information (or at least methods) can
be abstracted out, regardless.

   A number of people also suggested that I talk to Legato and to Auspex and
see what they've done in this area.  I have a couple of papers from Auspex;
at a first glance, I don't think they look too closely at NFS load
characterization (at least, not as I define that), but instead concentrate
on what Auspex did to get better speed out of their NFS file server.  The
Auspex paper titled, "Benchmark Methodology and Preliminary Performance
Specifications for the Auspex NS5000 Network Server" (Bruce Nelson, Auspex
TR #2, October 1989) has more load characterization information than do the
other Auspex TRs I have, but it still doesn't have a whole lot.  (By the
way, I'm not implying that Auspex hasn't looked at load characterization,
because they obviously have.  I just don't have the fine details of their
results.)  I also did some talking with people at Legato; their comments and
models show up in the nhfsstone benchmark, or are otherwise repeated above.

	-Steve

Spoken: Steve Miller    Domain: steve@umiacs.umd.edu    UUCP: uunet!mimsy!steve
Phone: +1-301-454-1808  USPS: UMIACS, Univ. of Maryland, College Park, MD 20742

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

C-5.  What is NHFSSTONES? Where can I get it?

"Nhfsstone" (pronounced n-f-s-stone, the "h" is silent) is a
copyrighted product of Legato Systems, Incorporated and is provided for
unrestricted use and distribution of the binary program derived from
it.

nhfsstone is a NFS load generating program.  It is used on an NFS client
to generate an artificial load with a particular mix of NFS operations.
It reports the average response time of the server in milliseconds per
call and the load in calls per second.  The program adjusts its calling
patterns based on the client's kernel NFS statistics and the elapsed
time.  Load can be generated over a given time or number of NFS calls.
The current version of the program can only be compiled on 4.x BSD
based UNIX systems.

To obtain the nhfsstone source shar file, send email to
"request@Legato.COM" or {sun,uunet}!legato!request.  The Subject line
and/or body of the message should have contain the command line:

	send unsupported nhfsstone

Note the exact spelling of "nhfsstone".  To issue delivery, you should
also add a line of the form:

	path <address>

where <address> is the preferred email address to use.  Generally,
using a domain-style email address works best.  A uucp path starting
with "sun!" or "uunet!" can also be used.


Joseph Moran
Legato Systems Inc.
260 Sheridan Avenue
Palo Alto, CA  94306
(415) 329-7886
mojo@Legato.COM or {sun,uunet}!legato!mojo

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

C-7.  How many nfsd's & biod's should I run on my server?

Default number of nfsd's & biod's is 8

Suggested Equation for nfsd's is:
	[number of disks exported] + [number of network interfaces]

Suggested maximum number of nfsd's runinng on a Sun system (SunOS 4.x) without any
accelerators is 22. Any more does not help in performance.

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

C-8.  What is asynchronous I/O? How can I modify my NFS server system to use
      asynchronous I/O?

Asynchronous I/O (ASYNC) means that information comes and leaves at unannounced
intervals whereas synchronous I/O (SYNC) has a predetermined interval when
I/O can actually pass.

NFS has been used both through SYNC and ASYNC communications. The original
specification stated that SYNC I/O should be used although did not bind to
it. This results in slower communications during transfers. ASYNC creates
problems in that, if for some reason communications should fail (eg., your
NFS server crashes), there may be inconsistency in the data. The bright side
of ASYNC is that performance increases by a great deal.

Many implementations of NFS using asynchronous I/O are available. Despite
the disadvantage, the number of complaints about data loss due to this are
far fewer than the reports of performance increase. However, be warned that
asynchronous I/O is a direct violation of the NFS specification from X/Open
which states that all procedures of the NFS protocol are synchronous. This
makes such a server no longer compliant to X/Open

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

C-9.  What is a good NFS server?

Network Appliances Corp have recently come out with a product which they
call an NFS appliance, the FAServer. It is a 486 based system with an EISA
bus, 16 MB RAM, 2 MB NVRAM, and a RAID subsystem. The RAID subsystem keeps
up to 20 logical copies of the entire file system. They have a proprietory
operating system which does only simple management and disk serving. 
The pricing is about $20,000.

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

C-10.  What is LADDIS?

LADDIS is multi-vendor and vendor neutral SPEC NFS Benchmack designed by
engineers from Leato, Auspex, Data General, DEC, Interphase and Sun [LADDIS
is an abbreviation using their first letters]. This covers local Ethernet or
FDDI nets and not WAN.

An excerpt from the LADDIS abstract:
"
	The purpose of the LADDIS benchmark is to give users a credible and
	undisputed test of NFS performance, and to give vendors a publishable
	standard performance measure that customers can use for load planning,
	system configuration, and equipment buying decisions. Toward this end,
	the LADDIS benchmark is being adopted by SPEC (the System Performance
	Evaluation Cooperative, creators of SPECmarks) as the first member of
	SPEC's System-level File Server (SFS) benchmark suite."
"

LADDIS is available directly from SPEC. Here is the contact person:

	Name:	Dianne Dean (SPEC contact person at NCGA)
	Phone:	703-698-9600 Ext 318
	Fax:	703-560-2752
	Email:	spec-ncga@cup.portal.com
	Mail:	SPEC
		c/o NCGA
		2722 Merrilee Drive, Suite 200
		Fairfax, VA 22031-4499


There is about a $1000 charge for the distribution tape.

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

C-11.  What is XRemote & LBX?

These are specifications for running the X11 windows system over lower
bandwidth connections like serial lines.

XRemote is a private specification developed by NCD. Inc. It is available in
commercial packages.
LBX (Low-Bandwidth X) is the specification also contributed by NCD to the
X11 standard forthcoming next year, ie. X11R6. You can get information on
LBX via FTP from:
	export.lcs.mit.edu:/contrib/LBX-xconf93-paper.ps.Z

This is not a formal document only an informative disclosure.

Running a low bandwidth X protocol over something like Ethernet would not be
useful since the compression algorithms involved would incur additional CPU
usage and so you would not get much of a performance advantage at all.

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

Section D: Applications
=======================

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

D-1.  Where can I get mail with (PC)NFS?

POPmail versions 2 and 3 and SMTP are the most common mail protocols for 
(PC)NFS and TCP/IP systems for PCs. Please look at the chart G-3 for mail 
systems.

Here are some additional third-party mail packages that work with PC-NFS:
	a. Open Systems Mail by Pinesoft (US) [pinesoft@netcom.com]

	b. Mail-It by Unipalm (UK) [tomk@unipalm.co.uk]
		   Tom Kermeen
		   Unipalm Ltd
		   216 Cambridge Science Park
		   Milton Road
		   Cambridge CB4 4WA
		   UK
		   +44 223 420002
		   +44 223 426868 [FAX]
		[Site license is available for L5000 (five-thousand pounds)]

		Distributed in the US by:
		   Unipress Software
		   2025 Lincoln Highway, 
		   Edison, NJ 08817
		   USA
		   (800) 222-0550
		   info@unipress.com

	c. WinELM was written by Peter Churchyard of Imperial College,
	   London. It is available for winsock systems from the ftp site
		   ftp.york.ac.uk:/pub/pc-nfs/Mail/winelm.zip
		   lister.cc.ic.ac.uk:/pub/winelm
	   There are also DOS, PC-NFS and WinSock API versions there.

	d. ECSMail is a commercial package which supports IMAP & MIME
	   contact steve@edm.isac.ca. I also supports Macintosh & Unix
	   You can get a demo version of ECSMail from
		ftp.york.ac.uk:/pub/pc-nfs/Mail/ecs.zip
	   [The demo requires an IMAP daemon such as in the Pine mailer]

	e. Cin'etic Mail Manager works directly with mounted file systems
           and sends mail via different setups like rsh on PC-NFS. Its
	   publicaly availble via ftp (cmm21f.zip). You can also contact
	   them at:
		Cinetic@speedy.cam.org 
		71460,666 (Compuserve)
	   This package currently supports PathWay, PC/TCP, PC-NFS, FSUUCP
	   by Fubar Systems, UUPC/extended by Drew Derbyshire. Its
	   configuarble for other systems as well. 

In addition, for mail arrival notifiers, there is WinBiff (version 1.6)
for MS-Windows 3.x that works with PC-NFS, UUPC, Waffle and FSUUCP. This is 
available from:
	ftp.cica.indiana.edu: /pub/pc/win3/mirrors/wnbff16.zip
	wsmr-simtel20.army.mil: PD1:<MSDOS.WINDOWS> WNBFF16.ZIP

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

D-2.  Where can I get a news client for (PC)NFS?

USENET News (NNTP) clients are available specifically from:
   Super-TCP [Z-16] - Windows version
   WinQVT    [Z-22] - Windows version
   Chameleon [Z-3]  - DOS version.

There is a public domain program called WinVN which uses the Winsock API. 
This means that just about any product which has the Winsock.dll should be
able to run it. It is available from:
    sunsite.unc.edu:/pub/micro/pc-stuff/ms-windows/winsock/apps/winvn.zip

Trump and WinTrump are other popular packages for news available from
	sunsite.unc.edu:/pub/micro/pc-stuff/ms-windows/winsock/apps/*

A simple news client by Stan Barber and a client by Kjettil Otter Olsen
(with source code) are avalable from
    ftp.york.ac.uk:/pub/pc-nfs/news

WinVN is a newsreader for Windows 3.x systems publically available from:
	titan.ksc.nasa.gov: [anonymous.pub.win3.winvn]	(Its a VAX host)

Macintosh newsreaders include:
	TheNews
	Newsreader
	MacNews
	Nuntius
All are available from:
	mac.archive.umich.edu:/mac/util/comm/*

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

D-3.  Where can I get an FTP server for (PC)NFS?

The following systems have FTP servers:

BW-TCP, PC-NFS, PC/TCP, Chameleon, PathWay, Super-TCP, IBM TCP/IP, Lanera TCP

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

D-4   Where can I get RWALL for my (PC)NFS system?

As far as memory serves me there currently are no implementations of the
rwall command as in Sun ONC on (PC)NFS systems, except possibly one for
the Macintosh NFS/Share product from Intercon.

Sorry folks. If anyone has information on this one please mail me, there are
people who want to know.

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

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

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

Comments?

Geoff
"

-------------------------------------------------------------------------------
   
D-5.  Where can I get an INT-14 redirector for (PC)NFS?

INT-14 redirectors are available with various (PC)NFS products including:
	BW-NFS		[Z-2]
	PC/TCP 		[Z-14]
	Chamelon NFS    [Z-3]
	
There is a version for PC-NFS v5.0 (by Geoff Arnold) at:
	ftp.york.ac.uk:/pub/pc-nfs/utils/int14/*
	sorokin.anu.edu.au:/pub/nfs5-addons/int14.zip

An INT-14 redirectory for WATTCP is available from:
	dorm.rutgers.edu:/pub/msdos/wattcp/apps.zip

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

D-6.  Where can I get YPPASSWD for PC-NFS?

There is a version of YPPASSWD for PC-NFS v5.0 at:
      ftp.york.ac.uk:/pub/pc-nfs/utils/yppasswd/yppasswd.zip

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

D-7.  Where can I get IBM 3270 terminal for (PC)NFS?

Please see chart in section G-1 under TN3270.

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

D-8.  Where can I get X-Windows for (PC)NFS?

The following X-windows products are available:

For DOS:
Product	    	Cost	Company			Version
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Xvision		$395	VisionWare Soft, Inc	X11R5
PC-Xware 	$545	NCD, Inc.		X11R5
PC DECwindows	??	DEC			X11R4
PC Xsight	??	Locus Computing		X11R4
Micro X-Lite 	$75	StarNet Comm. Corp.	X11R4
X Appeal 	$350	Xtreme			X11R5
Xoftware	??	AGE Logic		X11R4
PC X-Kit	$249	XLink			X11R5
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For MS-Windows:
Product	    	Cost	Company			Version
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
HCL-eXceed	??	Hummingbird Software    X11R5
eXcursion	??	DEC			X11R5
MultiView/X	??	JSB Corp.		X11R4
PC-Xview	$445	NCD Inc.		X11R5
Xoftware	??	AGE Logic		X11R4
eXodus		$295	White Pine Software	X11R5
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For Macintosh:
Product	    	Cost	Company			Version
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
MacX		??	Apple Computer Corp.	X11R5
eXodus		$295	White Pines Software	X11R5
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For OS/2:
Product	    	Cost	Company			Version
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
X Windows 	$150	IBM			X11R5
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

D-10.  Where can I get a database that works with (PC)NFS?

Any database would be able to use the NFS mounted drive as long as it
recognizes it as a local drive. Most network versions of a database however
will not work unless they specifically say they support (PC)NFS & TCP/IP.
DBMS's known to work with (PC)NFS include SQL*Net (Oracle), and Sybase for
DOS. 
PC-NFS is known to work with Paradox for Windows & DOS for network file
storage. 

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

D-11.  Where can I get a WAIS client for (PC)NFS?

WAIS Manager 3.0 by Kebin Gamiel (representing MCNC CNIDR and UNC-Chapel
Hill) has recently been announced which is WinSock compliant. Features
include multi-format handling capability, relevance feedback and a new
interface with Toolbar for quicker access.

You can get this via ftp from:
  sunsite.unc.edu: /pub/micro/pc-stuff/ms-windows/winsock/apps/waisman3.zip
  ftp.cnidr.org: /pub/NIDR.tools/wais/pc/windows/waisman3.zip

There is a WAIS client for PC/TCP at:
	calvin.sfasu.edu: /pub/dos/network/pc-tcp/wais.zip

WinWAIS is another winsock version of WAIS by EINET
is available from:
  ftp.einet.net:/einet/pc/*
  sunsite.unc.edu:/pub/micro/pc-stuff/ms-windows/winsock/apps

MacWAIS is a MacTCP compatible application for System 6 and 7 by EINET:
  ftp.einet.net:/einet/mac/*

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

D-12.  Where can I get an archie client for (PC)NFS?

A ported version of c-archie is available for PC-NFS at the ftp sites:
	bcm.tmc.edu: /nfs/archie.exe
	ftp.york.ac.uk:/pub/pc-nfs/utils/archie.exe (has source as well)
This version works for PC-NFS v4.0a

There is a version for PC/TCP at:
	calvin.sfasu.edu:/pub/dos/network/ftp-pctcp/archie.zip

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

D-13.  Where can I get a gopher client for (PC)NFS?

nfsgopher is available from bcm.tmc.edu in /nfs which will work with PC-NFS
gopher for MS-Windows is available for PC-NFS systems in an alpha release
from the ftp site:
	lister.cc.ic.ac.uk: pub/wingopher/{readme.txt,gopher.exe}
	ftp.york.ac.uk:/pub/pc-nfs/utils/gophersfx.exe

source available in ftp.york.ac.uk:/pub/pc-nfs/utils/gofer.zip

HGopher (Hampson's Gopher) is a client for gopher systems. The following
version has been tested at ANU:
	sorokin.anu.edu.au: /pub/nfs5-addons/hgopher.exe
It is originally distributed from:
	lister.cc.ic.ac.uk: /pub/wingopher

There is a gopher client for PC/TCP at the following site:
	calvin.sfasu.edu:/pub/dos/network/ftp-pctcp/goph1_05.exe

gophbook from UNC is an Asymetrix Toolbox application which uses winsock.dll
and is available from the ftp site:
  sunsite.unc.edu: /pub/micro/pc-stuff/ms-windows/winsock/apps/gophbook.zip

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

D-14.  Where can I get a WWW (World Wide Web) client for (PC)NFS?

There is a version of such a client for PC-NFS at
	ftp.york.ac.uk:/pub/pc-nfs/utils/wwwpcnfs.zip

Winsock clients are now commonly available and should work with any PC
TCP/IP system which supports winsock. Some winsock clients are Cello and
NCSA Mosaic.

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

D-15 Where can I get X25 for (PC)NFS ?

The Software Forge developed a PC/TCP-IP adapter for X25, which is a hardware/
software bundle that :

- conforms to PDS specification 1.09
- conforms to RFC 877/1356 (TCP-IP over X25)
- supports PC/TCP and PC-NFS (probably any PDS-compliant software)
- does address resolution of 100 Internet adresses (expandable)
- can have up to 20 simultaneous sessions

For more information, contact UniPalm (+44(0)223250100) or unipalm@unipalm.co.uk

The Software Group Ltd also makes X.25 software for PC systems. They can be
contacted at: 
	2 Director Court, Suite 201
	Woodbridge, Ontario, 
	Canada L4L 3Z5
	(418) 856-238
	(418) 856-0242 

	or email scott@group.com

There is also an X.25 package available with Super-TCP from Frontier
Technologies [Z-16].

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

D-16 Where can I get NEWGRP.EXE for PC-NFS ?

NEWGRP.EXE is a utility written by Geoff Arnold that does the equivalent of
the Unix newgrp command. See man newgrp if you are really interested. It can
be ftp-ed from some of the ftp sites found in C-2.

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

D-17 Where can I get AUTOCONF for PC-NFS ?

AUTOCONF is a shareware utility designed and implementes by Henk Swaters that
allows system administrators to define an NIS map (pcnfs.config) that holds
the equivalent of DRIVES.BAT. The NIS map works on a user-basis and the mounting
and unmounting of existing resources is performed trough a single .EXE file.

AUTOCONF.ZIP is available on ftp.york.ac.uk in /pub/pc-nfs. You do need at least
PKUNZIP 2.04G to unzip it. What follows is the README.


AUTOCONF                                                           14-06-93
                        autoconf utility for pcnfs
                        ==========================

NAME
        autoconf.exe - configure PCNFS-client network drives and printers


DISCRIPTION
        This program is made to configure the network drives and printers
        of a PCNFS-client from the NIS database. The name of the NIS-map
        is pcnfs.config. Each line of the pcnfs.config file defines user
        or group information and has the format

                username/groupname list-of-drives/printdevices

        where list-of-drives/printdevices is either another username/
        groupname, or a network drive/printdevice: 
        
                (drive:,hostname:/path,/option,option..)
                or
                (printdevice:,hostname:printername,/option,option..)

        example:
        ----------------------------------------------------------------
        all\
                (g:,calibra:/export/MSDOS/WinEnv)
        printer_staff\
                (lpt1:,pslw1:lw1,/fmt=raw)
        smith\
                all (f:,calibra:/export/MSDOS/DosEnv)\
                printer_staff
        ----------------------------------------------------------------

        When user smith executes autoconf.exe he mounts the following
        environment:

                g:      calibra:/export/MSDOS/WinEnv
                f:      calibra:/export/MSDOS/DosEnv
                lpt1:   pslw1:lw1       /fmt=raw

USAGE
        A known user has to be logged in, otherwise the program
        terminates. If the program is executed without any options
        the username is used as keyvalue. It is possible to give
        one or more keyvalues as argument of the program. These
        arguments can be either usernames or groupnames. By Default
	the program unmounts a drive before mounting a new drive on the
        same device. The argument /n or /nounmount switches this 
        option off. The argument /h or /help prints out a help screen
        and terminates the program. There will be no mount or unmount
        command.

        example with the same auto.config as above:

                autoconf printer_staff /n 
                or 
                autoconf /nounmount printer_staff

        These equivalent commands try to mount:

                lpt1:   pslw1:lw1       /fmt=raw

        There will be no unmount command and if there is already
        a network device on lpt1: there are no changes made.


AUTHOR
        Henk Swaters Dept. of Computer Science University of Twente.
        swaters@cs.utwente.nl
        
HISTORY
        autoconf.exe 
        -------------
        14-06-1993      verion 1.0 

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

D-18. Where can I get a remote backup utility for (PC)NFS?

WATTCP has a backup utility called "rtar" with its applications
distribution. 

The following commercial packages have similar facilities:
PC/TCP, Super-TCP, BW-TCP, Lanera TCPOpen, XLink PC-Link 

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

D-19.  Which (PC)NFS packages support DNS [named]?

Please see the chart Z-3.

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

D-20.  Where can I get a traceroute program?

BW-TCP [Z-X] has a traceroute program with their package.

There is a traceroute program available for WATTCP at:
	polysla.calpoly.edu:/pub/mdurkin/trtb91b.zip

This is for an older version of WATTCP but is being converted to the new
version currently.

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

D-21.  Where can I get an LPD program?

For commercial and some PD packages which have an LPD program please look at
the chart G-4. 

There's a Winsock-compliant LPD called NLPD available via ftp from:
	sunsite.unc.edu:/pub/micro/pc-stuff/ms-windows/winsock/apps/wslpd.exe

A PC-NFS LPD version is in ftp.york.ac.uk:/pub/pc-nfs/utils

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

Section E: Problems & General Q&A
=================================

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

E-2.  Can I use DNS instead of NIS with PC-NFS?

No. PC-NFS currently only supports the Sun ONC NIS product. (Even NIS+ is
not fully compatible).

DNS is available with other packages.

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

E-3.  Why do versions of (PC)NFS not follow symbolic links?

This is because according to the NFS definition, filenames are handled by
the NFS client. In some (PC)NFS if the files in the symbolic links may not
be in the same exported directory as the directory the link is in. NFS
mounted files appear as drives on the clients and the clients cannot parse
any files which appear higher up on the tree or on a different tree segment
than that of the NFS exported drive (from the server).

Certain versions can be clever enough to counter this problem by their own
methods but it is generally accepted that (PC)NFS systems do not support
symbolically linked files.

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

E-4.  PC-NFS v4.0 has trouble with Cntl-S, Cntl-Q.

This has been fixed in release 4.0a and 5.0. For 4.0a please look at the ftp
sites [H-5]

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

E-5.  PC-NFS v4.0 has trouble with redrawing windows.

This has been fixed in release 4.0a and 5.0. For 4.0a please look at the ftp
sites [H-5]

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

E-6.   PC-NFS v4.0 doesn't allow me to access the local printer when I have
       network printers.

This is because the default setup for printers in PC-NFS v4.0 is as a
network printer. In the print manager choose the printer and change the
setup. At the bottom of the setup screen for the printer should be a
checkbox indicating that it is a network printer. Uncheck this box.

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

E-7.  I cannot delete any file that PC-NFS makes with a ~ (tilde) in it.

To get rid of the problem, in your config.sys, run pcnfs.sys as:

C:\NFS\PCNFS.SYS /c^

where c reassign the immediately following character. [In this case to the
character '^']

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

E-8.  PC-NFS says that it cannot open any more files even when the limit in 
      autoexec.bat is set higher.

PC-NFS uses its open own file limit and not the DOS system open file limit. To
modify this limit use the /f flag as such in the config.sys:

C:\NFS\PCNFS.SYS /f50

The limit here is set to 50. The maximum is 64.

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

E-9.  Can (PC)NFS mount file systems which are bigger than 2 GB?

Most server file systems do not handle such large file systems, but this is
possible with various software enhancements like Disk-Suite for Sun systems.

NFS clients on the other need not know how big the actual remote file system
is. It only receives information on how big the individual files are and not
the file system itself.

The Network Appliance server has one partition under which all drives can be
mounted for NFS exportation.

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

E-10.  What is NFS/TCP? Will it work with my NFS product?

NFS/TCP is a different type of the original NFS protocol which uses the TCP
protocol as opposed to the originally specified UDP protocol. NFS over UDP
works well over a single LAN but is as not suitable for multiple LANs or
WANs as NFS/TCP. TCP's windowing of packets capability and reliability gives
it an advantage. In UDP dropped packets are not acknowledged between the two
hosts, however, TCP retransmits all dropped packets. One more aspect of TCP
(which is more idealistic than real) is the congestion control capacity
between routers for TCP which prevents overflooding of a congested network
link. In NFS/UDP it is easy to create UDP data which look like NFS requests
from other machines. However, TCP makes it much more difficult to add
falsified packets which impersonate another machines data.

The problem with NFS/TCP is that it is incompatible with NFS/UDP. Therefore
all servers running the TCP version will be invisible to clients running a
UDP version and vice versa.

NFS/TCP is available in PC/TCP and BWNFS.

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

E-11.  What is PKTD.SYS? Where can I get it?

PKTD.SYS is a shim that allows PC-NFS to use packet drivers instead of its
native drivers. It is available from:
	bcm.tmc.edu
	src.doc.ic.ac.uk
	ftpserver.massey.ac.nz
	ftp.york.ac.uk:/pub/pc-nfs/pktd/pktd.zip

The current version is 5.0.

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

E-12.  How can I run Netware 3.xx at the same time as (PC)NFS using NDIS?

You can run the NDIS-over-ODI shim available from Novell that will let you
run netware at the same time as any other product running NDIS (ie. many
(PC)NFS products.

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

E-14.  Is it possible to modify the read & write buffer sizes in (PC)NFS?

Different (PC)NFS systems have different sizes with default at 1024 Kbytes
for both.  The standard maximum is 8 KB.

In PC-NFS, read buffer size is fixed (1024KB) but you can modify the write
size to any thing below this maximum. Currently anything less than 128 bytes
is cached into a 256 byte datagram. Anything more than this is passed as its
specific size.

PC/TCP, PathWay Client NFS & BWNFS allow modification of read & write buffer
sizes.

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

E-15.  How can I install an Ethernet board not supported by (PC)NFS?

Contributed by Farid Rahmi:

If you're installing on an IBM PC or compatible, you can use NDIS drivers in
general for your Ethernet board. 

Although I only upgraded to 5.0 after installing a beta version of 5.0
on my 3C509 PC, the procedure should still be the same :


1) Get the NDIS driver, the PROTOCOL.INI and the .NIF file from the LANMAN
   directory off the floppy that shipped with the 3C509 and copy these three
   files onto your harddisk (*NOT* in C:\LANMAN !!!, see below)

2) Select NDIS during installation.

3) This should wake up QUIKNDIS, which will transform PROTOCOL.INI for you
   and put it in C:\LANMAN together with the NDIS driver.

Three remarks :

- If you have an EISA machine and an ISA 3C509, please RTFM before complaining
  about lockups.

- I noticed that QUIKNDIS would scratch (make zero byte file) the NDIS driver
  if placed into C:\LANMAN. As mentioned, this was in the beta release.

- Too bad SunSelect couldn't ship the drivers with 5.0. Seen most of the other
  vendors ship these drivers and they are publicly available (ftp.3com.com)...


Farid (fr@sunbim.be)

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


-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 1993 19:23:15 GMT
From:      rawn@lead.aichem.arizona.edu (Rawn Shah)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.answers,news.answers,comp.sys.mac.comm
Subject:   NFS & TCP/IP FAQ for PCs & Macs [part 03/06]

Archive-name: pcnfs-faq/part3
Last-modified: 1993/10/28
Version: 1.5


E-16.  In postscript files I sometimes get a ^D before the header from my
       programs. How do I get rid of it?

This happens mostly on PC systems sending output to postscript printers. 
The ^D is the EOF character and sometimes causes a blank page to be output
by the printer before the print job. It can be disabled by the following: 

In your WIN.INI file, add below [yourprintername, port] this line:

CTLD=0

If you wish to do this permenantly for all windows systems, you can
reprogram your printer with the following piece of Postscript code (Thanks
to Mark Fleming of Queen's Univ.). Send this as a file to your printer:

%!
%%Title: CTRL-D serial EOF (End-of-File) character fixed
%%Creator: R. Mark Fleming
%%+ Queen's University at Kingston
% Check if EOF is installed, if not install it
% assumes serverloop password is the default one
currentdict     % Get current dictionary
(\004) cvn known
{       % Check if CTRL-D defined in this dictionary 
        (%% CTRL-D  procedure already installed\n %%) print
} {
        (%% CTRL-D procedure not installed!\n %%) print
        % Define IBMpc (serial) EOF character to do nothing
        serverdict  begin
        0 exitserver    % Make permanent changes
        (\004) cvn 
        {} def  % To ignore ^D at the end of prologs.
  } ifelse
%%EOF

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


Section F: Programming
======================

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

F-1.  Is there a toolkit for (PC)NFS programming? Where can I get it?

Until recently, programming toolkits were developed independently by vendors
alongside their products. Due to the efforts of different persons and
organizations there is a formal definition of MS-Windows in the Windows
Sockets API. The current version is 1.1. This is only a standard and product
vendors are allowed to distribute their own programming toolkit. Most are
now developing or selling Windoes Sockets API compatible toolkits. Please
refer to the chart G-3 for products with Windows Sockets API.

Certain libaries for mounting drivers and user authentication with PC-NFS
5.0 are available on
	ftp.york.ac.uk:/pub/pc-nfs/dnet/DNET50.tar

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

F-2.  What is Windows Sockets (winsock)? Where can I get it?

Windows Sockets is an API developed by a group of NFS vendors as a standard
for future network based communications in MS-Windows. The current version
of the API is 1.1. Further information for this is available on request.
Mail all questions and comments to "winsock@microdyne.com". To join the
mailing list, mail to "winsock-request@microdyne.com". Windows Sockets API
documentation and related documents are available by ftp to: 
	microdyne.com: /pub/winsock
	sunsite.unc.edu		[Mirror site of the above address and much
				faster and up 24 hrs]

Peter Tatham (developer of the Trumpet newsreader) has developed an alpha
release of winsock.dll which uses a packet driver as the network driver. Its
currently available from ftp.utas.edu.au:/pb/trumpet. This winsock will be
used in the developement of WinTrumpet.

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

F-3.  What is the latest version of the NFS protocol?

The current official version of the NFS protocol is version 3. It has just
recently come out and is being tested at this years Connectathon.

A Postscript file is available from:
	ftp.uu.net:/networking/ip/nfs/NFS3.spec.ps.Z
	bcm.tmc.edu:/nfs/nfsv3.ps.Z
	gatekeeper.dec.com:/pub/standards/nfs/nfsv3.ps.Z

All comments and questions should be mailed to: nfs3@eng.sun.com

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

F-4.  What is new in version 3 of the NFS protocol?

New features of version 3 are:
 - 64bit support
 - exclusive creates,
 - asynchronous writes (I guess its official now Vernon)
 - improved attribute caching
 - the "ACCESS" command works on the server attributes as well
 - relaxed transfer size restrictions.
 - reduced required "GETATTR" operations.

More information to come later.

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

F-5.  What is the current RPC version? Where can I get it?

The current version of RPC is 4.0.  It is available at the ftp sites:
	bcm.tmc.edu
	src.doc.ic.ac.nz
	ftpserver.massey.ac.nz

There is a version 4.0 which works with WATTCP which is available from
	polyslo.calpoly.edu:/pub/mdurkin/rpc01a.zip

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

F-6.  Where can I get the XDR/RPC definition for PCNFSD?

The .x file in the current source kit is available by FTP from:
       bcm.tmc.edu
       src.doc.ic.ac.uk
       ftpserver.massey.ac.nz
       sunsite.unc.edu:/pub/micro/pc-stuff/ms-windows/winsock/gen/spry-rpc.zip 

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

F-7.  What RFC's describe the NFS protocol? Where can I get these RFC's?

RFC's (Requests for Comments) are standards approved by the IETF (Internet
Engineering Task Force) which maintain order on protocols and information
technology affecting on the Internet. There are about 1500 or more Internet
RFC's and many more drafts & proposals.

There are three RFC's currently related to the NFS protocol:

RFC 1094 - NFS: Network File System Protocol Specification
RFC 1057 - RPC: Remote Procedire Call Specification Version 2 
		[supercedes RFC 1050]
RFC 1014 - XDR: External Data Representation Standard

These RFC's are available by ftp from:
        NIC.DDN.MIL
	seagull.rtd.com: /pub/tcpip/papers

or by mail server from:
	SERVICE@NIC.DDM.MIL
	with subject "HELP"
	or retrieve with "RFC index"

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

F-8.  How can I tell if a program is NFS mounted?

Here's a message which discusses C code and methods of doing this:

In article <21egppINN5li@hoss.usl.com> mdash@usl.com (-candee-+Scheer M.D.)
writes: 
>By happy (?) coincidence, both NFS (at least implementations based closely
>on the Sun reference port) and RFS assume that (1) local file systems have
>major device numbers where the high bit is off, and (2) the client is
>therefore free to play in the namespace of devs with the high bit on.
>Clients of both types synthesize devs with the high bit on.  I'm aware of
>no environment that breaks assumption (1).

We're aware of several.  We've been down that route and abandoned it
several years ago.  While this is true of faithful SVRx (where I'm not
sure whether "x" includes any 4) ports with RFS, it breaks on many other
machines.  Including SunOS, which uses a major number that is determined
at driver configuration time to denote NFS mounted files.  If I recall
correctly, out-of-the-box, the magic major number is 20 on SunOS, but may
change on reconfig.  Other machines where I'm fairly sure that the highbit
kludge doesn't work are Pyramid DCOSX, AIX3.  It's been a while...

If I have to, I could confirm and expand the list by pawing thru
our SCCS history databases.  Please don't make me - it's scary in there ;-)

Furthermore, st_dev will not change between different NFS mounts.
Thus st_dev:st_ino cannot be unique.

If you're on a SVR3'ish port, there is a macro in sys/types.h (or param.h)
analogous to major() and minor().  I seem to recall it is called "bmajor()".
If you're on a system that has bmajor(), you can use it - I remember it
masking off the upper bit of a major number.  So you can say:

	if (major(x.st_dev) != bmajor(x.st_dev))
		file is remote
		
If it doesn't, you have to experiment and keep your fingers crossed.

I hate to say this, but there is no easy way to do this universally.
We ended up having to read the mount tables and match path prefixes.
Yuck.  #defines up the wazzoo.

I suggest you start reading about getmntent() and analogues, and parse
the file system type fields.  If performance isn't particularly critical,
it may be easier to popen /etc/mount and parse the output:

    f = popen("/etc/mount", "r");
    while(fgets(buf, sizeof(buf), f)) {
	...
    }
    pclose(f);

If you use getmntent() (or /etc/mount kludge), and get a reasonable stat()
st_ino value for each file, you can use a "mount number":st_ino as a unique
key.  But you cannot guarantee that a single file has only one
key (multiple NFS mounts of a directory heirarchy).

You may also have to resolve symlinks depending on how your application
works.  This isn't a lot of fun either.

If you merely have to determine whether the occasional file is
remote or not, just "df <file>" it, and parse the output.
Grotty, effective, reasonably portable, and *usually* reliable.
But we know systems that can't even get this right...

[On HPUX, use "bdf" not "df" ;-)]
-- 
Chris Lewis; clewis@ferret.ocunix.on.ca; Phone: Canada 613 832-0541
Psroff 3.0 info: psroff-request@ferret.ocunix.on.ca
Ferret list: ferret-request@ferret.ocunix.on.ca

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

Section G: Product Features Comparisons
=======================================

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

G-1.  Driver support comparison chart of different products.

  Additional codes:
    s = supported with a "shim" (perhaps some "y" should be "s", tell me)
    m = "must be used with" as opposed to "also works with"

                     Drivers Included          Interfaces Supported
                    -------------------    -----------------------------
           Stack             Token         Packet
ID        Provided  Ethernet  Ring FDDI    Drivers  NDIS  SLIP  PPP  ODI
--------- --------  -------- ----- ----    -------  ----  ----  ---  ---
AIR          y         y                              y               y
PC/TCP       y         y       y              y       s     y    y    s
Chameleon    y         y       y     y        s       y     y    n
Super-TCP    y         y       y     n        y       y     y    x    y
IBM/DOS      y         y       y              s       y     y    n    n
BW           y         y       y              y       y     y    n    y
Distinct     y         y       y     n        y       y     y    y    y
Pathway      y         y       y              y       y     y         y
PathWay.OS2  y         y       y              n       y               y
PC-NFS       y         y       y              s       y     y    n    y
LWPD         y         y       y              s       s     y    y    y
HP           y         y       y              y       y     n    n    s
NCSATel      n         n       n              m
CUTCP        n         n       n              m
QVT/Net      n         n       n              m
MSLanMan               y       y                      y
TTCP                   y       y              y       s     n    n    s
TCPOpen	     y	       y       y	      y	      y	    y    n    y
WinNT        y         y       y              n       y     n    n
Piper/IP     y         y       y                      y     y         y
ICE-TCP      y         y                      y

Notes:
  Many packages include drivers for many different network adapters,
  and/or can use interfaces to existing drivers.  Packet driver
  compatibility implies NDIS and ODI compatibility through the use of
  dis_pkt and odipkt.

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

G-2.  Protocol support comparison chart of different products.


  It is presumed that a TCP/IP package supports TCP, IP, UDP, ICMP, and
  ARP, so these are not listed.

ID          BootP Client  RARP    DNS    NetBIOS (2)
---------   ------------  ----  -------  -------
AIR		 n	    n      y        y
PC/TCP           y                 y        y
Chameleon        y                 y        n
Super-TCP        y          y      y        y
IBM/DOS          y                 y        y
BW               y          y      y        y
Distinct
Pathway          y                 y        y
PathWay.OS/2     y                 y        y
PC-NFS           y(3)       y      n        y
LWPD             y          y      y        y
HP               n                 y        y
NCSATel          n                 y
CUTCP            y          n      y
QVT/Net          y                 y
TTCP             n(1)       y      y        n(1)
TCPOpen		 y	    y	   y	    y
WinNT            n          n      y        y
Piper/IP                           y        y
ICE-TCP          ?

  Notes: (1) Version 2.0 will have bootp support.
         (2) RFC 1001/1002 NetBIOS over TCP/IP, not level 3 coexistance
             with NetBIOS over NetBUI.
	 (3) PD Bootp workaround by Thomas Dwyer III available from:
		ftp.york.ac.uk:/pub/pc-nfs/utils/bootp.exe

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

G-3.  MS-Windows applications and support chart of different products.

  Columns:
     All Apps  -- all applications are Windows based
     Some Apps -- some are Windows, some are DOS or character
     All DLL   -- stack is implemented as "100% Windows DLL" code
     WinSock   -- supports Windows Socket API (1.1)
     VxDev     -- includes a virtual device drive to support DOS apps
                     running under Windows

ID          All Apps  Some Apps  All DLL    WinSock   VxDev
---------   --------  ---------  --------   -------   -----
AIR	       n           y         y         y   
PC/TCP         n           y         n         y        y
Chameleon      y           n         y         y
Super-TCP      y          (1)        y(1)      y        y
IBM/DOS        n           y         n(2)      y
BW             n           y         n         n(3)
Distinct       y           n         y         y
Pathway        y			       n(3)
PathWayOS/2    y           n         n         
PC-NFS         n           y         n         y
LWPD           n           y         n         n(3)
HP             n           n         n         n
NCSATel        n           n         n         n
CUTCP          n           n         n         n
QVT/Net        y           n         n         n
TTCP           n           y         n         n(3)
TCPOpen	       n	   y	     n	       y
Piper/IP                             n         y
WinNT          n(4)        n(4)      n(4)      y

 Notes:
  (1) Super-TCP/NFS includes DOS based applications and an optional TSR.
  (2) The stack is protected mode code that sits entirely in extended
      memory except for a small interface TSR.
  (3) Winsock is coming RSN, as an update or in the next version.
  (4) Windows NT doesn't run on top of DOS, and TCP/IP is part of the
      system.  Some of the applications are graphical, many utitities
      character-based.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

  Additional codes:
     d = DOS or character-based application
     w = Windows based application

                              FTP                      NNTP  SNMP   NFS
ID        Telnet TN3270  client server  SMTP POP (3)  Client Agent Client
--------- ------ ------  ------ ------  ---- -------  ------ ----- ------
AIR	   d w    d w     d w     w      w    w3                    d w
PC/TCP     d w     d      d w     d      d   d2 d3       d     y    d w
Chameleon   w      w       w      w      w   w2          n     y      x
Super-TCP   w      w       w      w      w   w2 w3       w     w    dx wx
IBM/DOS    d w    d w     d w     d     d w  d2          n     y      x
BW         d w    d w     d w    d w     w   w2 w3       n     y      x
Distinct    w      n       w      w
Pathway    d w    d w     d w     d                            d     d w
PathWayOS2  y      y       y                                   y      y
PC-NFS     d w     x      d w     d     d w  d23w23      n     y     d w
LWPD       d w    d wx    d w    d w     n     n         n     y      x
HP          d              d
NCSATel    d w    (5)     d w     w      n     n         n     n      n
CUTCP       d      d       d      d      n     n         n     n      n
QVT/Net     w      n       w      w      n     w         w     n      n
TTCP v2.0   (1)           d w
TCPOpen	    w      w      d w     w      w     w3        n     n     d w
WinNT       w      n      d(4)   (6)     n     n         n     y
Piper       y      y       y      y                      y     y      y

 Notes: (1) terminal emulation products sold separately
        (3) POP (Post Office Protocol): 2 = version 2, 3 = version 3,
             and implies an SMTP client to send mail
        (4) "d" here means "character based"
        (5) get TN3270 (CUTCP) package from Clarkson University
        (6) server for NT will be in production version

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

G-4.  Utilities available with different products.

                                          setclock
ID         ping lpr lpd finger talk whois (rdate)  rcp rsh rexec stats
---------  ---- --- --- ------ ---- ----- -------- --- --- ----- -----
AIR	     y            y                  y      y   y    y 
PC/TCP       y   y   x    y      n    y      y      y   y    y     y
Chameleon    y   x   n    y      n    y      n      n   n    n     y
Super-TCP    y   x   x    y      y    n      n      y   y    y     y
IBM/DOS      y   y   y    y      n    n      y      y   y    y     y
BW           y   y   y    y      y    y      y      y   y    n     y
Distinct     y                                                     y
Pathway      y   y        y      n    n      n      y   y    n     n
PathWayOS/2  y   y                                                 y
PC-NFS       y  (3)       y      n    y      y      y   y    n     y
LWPD         y   y   n    y      y    n      n      y   y    y     y
HP           y   n   n    n      n    n      n      y   y    n     n
NCSATel     (1)  y   n    y      n    n      y      n   y    y     n
CUTCP        n   y   n    n      n    n      n     (2)  n    n     n
QVT/Net      n   y   n    n      n    n      n     (2)  n    n     n
TTCP         y   y   y    y                                        y
TCPOpen      y   y   y    y           y      y      y   y    y     n
WinNT        y   y   n    y      n    n      n      y   y    y     y
Piper        y   y   y    y      n    y      y      y   y    y     y

 Notes: (1) although NCSA Telnet does not come packaged with many
            utilities, many are available on various FTP servers.
       (2) has an RCP server, but not a client.
       (3) printing suported via pcnfsd (in common with most other
           products)

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

G-5.  Telnet features of different products.

             Terminal Emulation           Builtin      3270 options (1)
          -----------------------  INT14  FTPserv  ----------------------
ID        VT100 VT220 3270 tk4010  Redir    (4)    models X-streams graph
--------- ----- ----- ---- ------  -----  -------  ------ --------- -----
AIR	    y     y     y                    y       
PC/TCP      y     y     y     n      y       y        y       y       n
Chameleon   y     y     y     n              n        y       n(3)    n
Super-TCP   y     y     y     n      y      n(2)      n       n       n
IBM/DOS     y     y     y     n             n(2)      y       y       n
BW          y     y     y            y      n(2)      y       n       n
Distinct
Pathway     y     y     y            y
PathWayOS2  y     y     y     y                       y       y       y
PC-NFS     d w   d w    x           (5)      n
LWPD        y     y     x            y       y        y       y       n
HP
NCSATel     y     n     n     n      n
CUTCP       y     n     y     y      n       y        n       n       n
QVT/Net     y     y     n     n      n       n
TTCP
TCPOpen     y     y     y     n              y        y
WinNT       y           n     n              n        n       n       n
Piper       y           y     n      y      

 Notes:
  (1) models -- can emulate different 3270 models
      X-streams -- supports extended data streams
      graph -- supports 3270 graphics (either vector or symbol sets)
  (2) A separate FTP server runs in the background (without Windows).
  (3) A patch is available for extended data streams, but it did not
      work for me (cjs).
  (4) Built-in FTP server doesn't have much utility for Windows based
      telnet since an FTP server can be running the same time as Telnet.
  (5) Will be available shortly (as unsupported add-on)

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

G-6.  Support for other network protocols on the same wire

	   Novell  Banyan      MS-LAN	                Windows 4
Product	   Netware VINES  X.25 Manager Appletalk DECnet Workgroups Lantastic
-------    ------- ------ ---- ------- --------- ------ ---------- ---------
AIR	      y            n               n       n                   
PC/TCP        y      y     y      y        n       n         y         
Chameleon                  y                                            
Super-TCP     y      y     y      y        n       y         y        y
IBM/DOS                                    n                            
BW            y                            n                 y                   
Distinct      y                                                        
Pathway       y      y            y        y(o)    y(o)                
PathWay.OS/2  y      y            y        n       n         
PC-NFS        y      n     y(t)   y        n       n         y        y
NFS/Share     n      n     n      n        y       y         n        n
LWPD          y            y(t)            n                           
HP                                         n                           
NCSATel       n      n     n      n        y(o)    n         n        n
CUTCP         n      n     n      n        y(o)    n         n        n
QVT/Net       y(s)         n                                 y(s)
TTCP                                                                   
TCPOpen       y      y            y                          y        y
WinNT         y                   y        n       n         y         
Piper/IP      y      y            y        n                

  (o) option
  (t) third party software
  (s) Use a shim

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

G-7.  Features of X servers.

	   X11			    	       Window            Dev.
Product	 Release  Fonts  XDMCP  ICCCM   Video  Manager  XRemote  Kit  Winsock
-------  -------  -----  -----  -----  ------- -------  -------  ---  -------
eXceed      5              y      y     xevs8t    m        y      y      y
eXcursion   5      s              y               w               
eXodus	    5              y      y     vsx      mod       y             n
X-Lite      4                            vs      mod       n      n      n  
X-WIN	    5		   y	        vhs      mod       n      n      y
Multiview   4      b       y                      w        n      n      n
Xware       5     stb      y      y    cevs8txo  mow       y      y      y
Xview       4              y      y    mcevs8tx   mo       y      y 
XLink       5     sdp                    vso8                     y      n
DECWin      4     sa       n      y      ev8o              n      n      n
Xsight      4                            evh      w        n             y
Xappeal     5                     y      vs       od       n      n      n
Xoftware    5      s       y      y      evs8    mow       n      y      y
Xvision     5     satb     y      y              od        y      y      y
IBM X-OS/2  5              y      y     evs8xo    p        n      y      y 
---------------------------------------------------------------------------

Key:
Fonts: s - SNF, a - adobe, t - TrueType, b - BDF, p - PCF, d - SPD

Video: e - EGA, v - VGA, s - SVGA, m - mono, 8 - 8514, t - TIGA, x - XGA
       c - CGA, h - Hercules, o - others (MCGA, DIGA, Japanese, etc)

Window Manager: m - Motif, o - OpenLook, d - DECWindows, w - MS-Windows, 
		p - Presentation Manager

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

Section H: Information Sources
==============================

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

H-1.  CHEST - Council for Higher Education Software Transfers

Chest is run in the United Kingdom for all higher educational bodies for the
provision of educational software pricing. The run an information service
called NISS [telnet niss.ac.uk] which is full of useful information on
software deals. Their current director is Mike Johnson. Each educational
site has a local representative. Users wanting to deal should contact their
local representative. The address for the CHEST & NISS Centre is given below:

	CHEST & NISS Centre,
	University of Bath,
	Bath BA2 7AY,
	UK

	+44 (0) 225 826042

There is a discussion list associated with the CHEST product deal at
mailbase@mailbase.ac.uk and Chest-Xwindows@mailbase.ac.uk. They have
associated archives full of information. To join the list you send a message
to mailbase@mailbase.ac.uk with the message body containing 
"subscribe chest-pcnfs (real name)"

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

H-2.  X/Open.

The X/Open Company is an international group of vendors which acts as a
standards body for API system compatibility of different platforms. They
create the X/Open Portability Guide (XPG) which includes a description for
portability of a Unix system. The following are the addresses, phone and FAX
numbers for the X/Open Company:

X/Open Company Ltd.                  X/Open Company Ltd.
Apex Plaza, Forbury Rd.,             Karufuru-Kanda Bldg., 9F
Reading, Berkshire RG1 1AX           1-2-1 Kanda Suda-Cho
United KIngdom                       Chiyoda-Ku, Tokyo 101, Japan
Phone: +44 734 508311                Phone: +81 3 251 8321
FAX:   +44 734 500110                FAX:   +81 3 251 8376

X/Open Company Ltd.                  X/Open Company Ltd.
1750 Montgomery Street,              1055 Washington Blvd., 6th Floor
San Francisco, CA 94111              Stamford, CT 06901
USA                                  USA
Phone: +1 (415)773-5383              Phone: +1 (203)975-7778
FAX:   +1 (415)421-4278              FAX:   +1 (203)975-7744

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

H-3. Books.

Bloomer, John
"Power Programming with RPC"
O'Reilly & Assoc, 1992
ISBN 0-937175-77-3
US$29.95
---
This covers the details of distributed application developement using RPCs. 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Comer, Douglas E.
"Internetworking with TCP/IP Volume I: Principles, Protocols and 
Architecture" 
Second edition, Prentice Hall, 1991.
ISBN 0-13-468505-9
---
One of the best referrences on TCP/IP with good examples
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Comer, Douglas E., Stevens, David L.,
"Internetworking with TCP/IP Volume II: Design, Implementation and
Internals"
Prentice Hall, 1991.
ISBN 0-13-472242-6
---
Followup to Comer's very successful Vol 1. Descriptions on specific
applications and services
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Comer, Douglas E., Stevens, David L.,
"Internetworking with TCP/IP Volume III: Client-Server Programming
and Applications" (BSD Socket Version)
Prentice Hall, 1993
ISBN 0-13-474222-2
---
Book 3 has a good description on network programming via RPC & TCP/IP
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Corbin, John,
"The Art of Distributed Programming-Programming Techniques for Remote
Procedure Calls"
Springer-Verlag, New York, New York. 1991.
ISBN ??
---
Basic description of RPC and XDR and how to program distributed applications
using them. 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Engst, Adam
"The Internet Starter Kit for Macintosh"
Hayden Books, Indianapolis, 1993
ISBN 1-56830-064-6
US$29.95
Canada $37.95
---
Adam has outdone himself in this whimsical starter book for Macintosh users
wanting to know about the Internet and how to connect to it. A must read
book if you're a novice.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Hunt, Craig
"TCP/IP Network Administration"
O'Reilly & Assoc., 1992
ISBN 0-13-015389-3
---
Another in O'Reilly's System administration series. Good practical
referrence for sysadmins.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Kehoe, Brian
"Zen and the Art of the Internet"
Prentice-Hall, 1992
ISBN 0-13-010778-6
---
A comprehensive Internet book for beginners. It can be ftp'd from
world.std.com:/obi/Internet/zen-1.0 as well
It is available in Microsoft Rich Text Format (as in the Help format) from:
ftp.york.ac.uk:/pub/pc-nfs/doc/zen10.hlp

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Krol, Ed
"The Whole Internet: User's Guide & Catalog"
O'Reilly & Assoc, 1992
ISBN 1-56592-025-2
---
A good introduction to the Internet covering the basics such as email and
news and expands into new developments as well.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

LaQuery, Tracy, Ryer, Jeanne C.
"The Internet Companion: A Beginner's Guide to Global Networking"
Addison-Wesley, 1993
ISBN 0-201-62224-6
---
Another introductory book for novices on Internet services. The book informs
users on how to find information.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Malamud, Carl 
"Analyzing Sun Networks." 
Van Nostrand Reinhold, 1991.
ISBN ??
---
Mr. Malamud is a very well known author on networking standards and this
book gives a good description of Sun's ONC.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Miller, Mark A.
"Troubleshooting TCP/IP"
ISBN ??
--
Teaches how to analyze TCP/IP problems and discusses platforms and case
studies.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Rose, Marshall T.
"The Simple Book: An Introduction to Management of TCP/IP-based Internets"
Prentice Hall
ISBN ??
--
The first of Mr Roses books on Network management. A new edition is coming
out soon, I think.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Rose, Marshall T. 
"The Internet Message: Closing the Book on Electronic Mail"
Prentice Hall
ISBN 0-13-092041-7
--
A good book on Internet mail systems by a very enjoyable author. Great for
developers not users.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Santifaller, Michael 
"TCP/IP and NFS." 
Addison Wesley, 1991.
ISBN ??
---
No info. opinions welcome.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Stern, Hal 
"Managing NFS and NIS." 
O'Reilly & Associates, 1991.
ISBN 0-937175-75-7
---
Very handy troubleshooting book on NFS & NIS problems
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Stevens, W. Richard,
"Unix Network Programming"
Prentice Hall, 1990.
ISBN 0-13-949876-1
---
A good book on the details of Unix network systems with good exercises. Mr
Stevens is a very well known author on Unix systems. The source code and
errata list are available from ftp.uu.net:/published/books
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Stephen Roge
"Unix System V Network Programming" 
Addison-Wesley, 1993
[Brand new book (July 93), I have not read it yet. Any opinions welcome]

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

H-4.  Related papers (published)

Glover, Fred,
"TNFS Protocol Specification,"
Trusted System Interest Group, INTERNET-DRAFT, May 24, 1992.
--
Proposed draft standard for security extensions to NFS.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Israel, Robert K., Sandra Jett, James Pownell, George M. Ericson,
"Eliminating Data Copies in UNIX-based NFS Servers,"
Uniforum Conference Proceedings, San Francisco, CA, February 27 - March 2,1989.
--
Describes two methods for reducing data copies in NFS server code.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Jacobson, V.,
"Congestion Control and Avoidance,"
Proc. ACM SIGCOMM `88, Stanford, CA, August 1988.
--
The paper describing improvements to TCP to allow use over Wide Area
Networks and through gateways connecting networks of varying capacity. This
work was a starting point for the NFS Dynamic Retransmission work.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Juszczak, Chet,
"Improving the Performance and Correctness of an NFS Server,"
USENIX Conference Proceedings, USENIX Association, Berkeley, CA, June 1990,
pages 53-63.
--
Describes reply cache implementation which avoids work in the server by
handling duplicate requests. More important, though listed as a side-effect,
the reply cache aids in the avoidance of destructive non-idempotent
operation re-application-improving correctness. 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Kazar, Michael Leon,
"Synchronization and Caching Issues in the Andrew File System,"
USENIX Conference Proceedings, USENIX Association, Berkeley, CA, Dallas
Winter 1988, pages 27-36.
--
A description of the cache consistency scheme in AFS. Contrasted with other
distributed file systems.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Macklem, Rick,
"Lessons Learned Tuning the 4.3BSD Reno Implementation of the NFS Protocol,"
Winter USENIX Conference Proceedings, USENIX Association, Berkeley, CA,
January 1991.
--
Describes performance work in tuning the 4.3BSD Reno NFS implementation.
Describes performance improvement (reduced CPU loading) through elimination
of data copies. 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Mogul, Jeffrey C.,
"A Recovery Protocol for Spritely NFS,"
USENIX File System Workshop Proceedings, Ann Arbor, MI, USENIX Association, 
Berkeley, CA, May 1992.
--
Second paper on Spritely NFS proposes a lease-based scheme for recovering
state of consistency protocol.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Nowicki, Bill,
"Transport Issues in the Network File System,"
ACM SIGCOMM newsletter Computer Communication Review, April 1989.
--
A brief description of the basis for the dynamic retransmission work.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Pawlowski, Brian, Ron Hixon, Mark Stein, Joseph Tumminaro,
"Network Computing in the UNIX and IBM Mainframe Environment,"
Uniforum `89 Conf. Proc., (1989)
--
Description of an NFS server implementation for IBM's MVS operating system.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[RFC1014]	Sun Microsystems, Inc.,
"External Data Representation Specification,"
RFC-1014, DDN Network Information Center, SRI International, Menlo Park, CA.
--
Proposed standard for canonical format for data exchange, used with RPC.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[RFC1057]	Sun Microsystems, Inc.,
"Remote Procedure Call Specification,"
RFC-1057, DDN Network Information Center, SRI International, Menlo Park, CA.
--
Remote procedure protocol specification.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[RFC1094]	Sun Microsystems, Inc.,
"Network Filesystem Specification,"
RFC-1094, DDN Network Information Center, SRI International, Menlo Park, CA.
--
NFS version 2 protocol specification.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh, B. Lyon,
"Design and Implementation of the Sun Network Filesystem,"
USENIX Conference Proceedings, USENIX Association, Berkeley, CA, Summer 1985.
--
The basic paper describing the SunOS implementation of the NFS version 2
protocol, and discusses the goals, protocol specification and trade-offs.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Srinivasan, V., Mogul, Jeffrey C. 
"Spritely NFS: Implementation and Performance of Cache Consistency Protocols",
WRL Research Report 89/5, Digital Equipment Corporation Western Research
Laboratory, 100 Hamilton Ave., Palo Alto, CA, 94301, May 1989.
--
This paper analyzes the effect of applying a Sprite-like consistency
protocol applied to standard NFS. The issues of recovery in a stateful
environment are covered in [Mogul]. 

Electronically available: ftp gatekeeper.dec.com:/pub/DEC/WRL/WRL-TR-89.5.ps.Z
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Mogul, Jeffrey C. 
"A Recovery Protocol for Spritely NFS",
WRL Technical Note 27, Digital Equipment Corporation Western Research
Laboratory, 100 Hamilton Ave., Palo Alto, CA, 94301, April 1993.
--
No abstract.

Electronically available: ftp gatekeeper.dec.com:/pub/DEC/WRL/WRL-TN-27.ps.Z
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

X/Open Company, Ltd.,
"X/Open CAE Specification: Protocols for X/Open Internetworking: XNFS",
X/Open Company, Ltd., Apex Plaza, Forbury Road, Reading Berkshire, RG1 1AX,
United Kingdom, 1991.
--
This is an indispensable reference for NFS version 2 protocol and
accompanying protocols, including the Lock Manager and the Portmapper. 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

X/Open Company, Ltd.,
"X/Open CAE Specification: Protocols for X/Open Internetworking: (PC)NFS 
Developer's Specification",
X/Open Company, Ltd., Apex Plaza, Forbury Road,
Reading Berkshire, RG1 1AX, United Kingdom, 1991. 
--
This is an indispensable reference for the PC implementation of the NFS
version 2 protocol. 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Hall M., Towfiq M., Arnold G., Treadwell D., Sanders H.
"Windows Sockets: An Open Interface for Network Programming under Microsoft
 Windows, version 1.1"
1992.
--
This is the specification of the Windows Sockets API which is the current
standard for Windows PC network socket calls. A must read for current
developers. 

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

H-5.  FTP Sites

The official FTP sites for comp.protocols.nfs are:
	bcm.tmc.edu:		/nfs
	ftpserver.massey.ac.nz
	src.doc.ic.ac.uk

FAQ draft current location:
	seagull.rtd.com:	/pub/tcpip/FAQ.pcnfs.v1.5.Z or pcnfsfaq.zip

Other FTP sites:
	calvin.sfasi.edu:	/pub/dos/network/ftp-pctcp
	dorm.rutgers.edu: 	/pub/msdos/bws
	ftp.bws.com: 		/pub/bw
	ftp.cica.indiana.edu
	ftp.cnidr.org: 		/pub/NIDR.tools/wais/pc/windows
	ftp.com
	ftp.netmanage.com
	ftp.novell.com:
	ftp.york.ac.uk:		/pub
	grape.ecs.clarkson.edu
	lister.cc.ic.ac.uk
	microdyne.com: 		/pub/winsock
[RFCs]	nic.ddn.mil:
	seagull.rtd.com: 	/pub/tcpip
	sgi.sgi.com
[ODI]	sjf-lwp.novell.com:
	sorokin.anu.edu.au:     /pub/nfs5-addons
	sunsite.unc.edu: 	/pub/micro/pc-stuff/ms-windows/winsock
	vax.ftp.com	
       
-------------------------------------------------------------------------------

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 1993 19:24:22 GMT
From:      rawn@lead.aichem.arizona.edu (Rawn Shah)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.answers,news.answers,comp.sys.mac.comm
Subject:   NFS & TCP/IP FAQ for PCs & Macs [part 04/06]

Archive-name: pcnfs-faq/part4
Last-modified: 1993/10/28
Version: 1.5



H-6.  Related FAQs, USENET lists, email lists etc.

You can find FAQs, FAQlets, and other lists on USENET related to the topic
of PC's and TCP/IP Networks in general at the following sources:

A. Comp.protocols.tcp-ip.ibmpc FAQlet by Bernard Abouba
   This covers details of running the IP protocols and intermixing different
   packages on IBM PC & compatible systems. It is posted bi-weekly on the
   corresponding USENET group. You can also FTP a copy from the following
   site:  
	netcom1.netcom.com: /pub/mailcom/IBMTCP
	
B. "Features of TCP/IP Packages for DOS and Windows" (Version 0.5 5/13/93)
   by C.J.Sacksteder
   This is another comparison of TCP/IP packages for DOS and MS-Windows PC
   systems. It is posted to comp.protocols.tcp-ip.ibmpc.

C. Packet Drivers FAQ by Russell Nelson
   This covers questions concerning the installation, maintainence and
   compatibility of the Packet Drivers suite available as freeware on the
   Internet. It is posted to comp.protocols.tcp-ip.ibmpc.

D. Windows Sockets API FAQ	
   This covers questions on the Windows Sockets API standard. There is also
   a USENET newsgroup for this: alt.winsock. The FAQ is available on the
   newsgroup and also from the official site for the standard:
	microdyne.com: /pub/winsock/FAQ/FAQ

E. Windows Sockets API mailing list
   This mailing list can be joined by email request to:
	winsock-request@microdyne.com

F. Sun RPC on Windows
   This mailing list discusses Sun's Open Network Computing RPC's running on
   Windows. You can subscribe by mailing to:
	rpc4win-request@wco.ftp.com

G. NFS version 3 mailing list
   The mailing list for the new NFS specification can be joined my emailing: 
	nfs3@eng.sun.com

H. The UK CHEST program mailing list
   This mailing list contains information on (PC)NFS distributed by CHEST
   [Z-1]. Email to:
	mailbase@mailbase.ac.uk
     with a header "subscribe chest-pcnfs (real name here)"

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

H-7.  Glossary

These are brief descriptions of the terms used in PC & TCP/IP networking.

ANSI	American National Standards Institute. A standards making body of
	the US Federal system.
	
API	Application Programming Interface.

AppleTalk A proprietory network protocol developed by Apple Computers, Inc.
	and available on Macintosh systems.

ARP	Address Resolution Protocol. Nodes use these to determine the
	hardware address of a given IP address if directly available.
	Described in RFC 826.

BOOTP   Bootstrap Protocol. This allows a client to determine its IP address
	given its hardware address (to some BOOTP server). Described in RFC
	1084. 

client	A program which is used to communicate with another which provides 
	special services (eg. an NFS client communicates with an NFS server
	to mount remote file systems locallly.)

DECNET	A proprietory networking system developed by Digital Equipment Corp.

DLL	Dynamically Linked Library. This is a set of shared functions and 
	procedures used by applications that can be loaded or unloaded at
	any time by the applications. Many TCP/IP packages now come as DLLs. 

DNS	Domain Naming System/Server. This is a system of Internet hosts
	which provide IP name to IP address resolution. Described in RFCs
	1034 and 1035.

Email	Electronic Mail. This is a method of communication electronically
	using different methods of delivery. On the Internet the email
	protocol most commonly used (and the standard) is SMTP.

Ethernet This is a physical and data link layer system connecting hosts in
	a bus-topology network. It is described by IEEE 802.3 and the DIX
	(Digital, Intel, Xerox) Ethernet II specifications. Both are
	compatible on the same physical wire but differ slightly in utility.

FDDI	Fibre Distributed Data Interface. This is a physical layer and data
	link layer standard for a fibre optic ring-topology network as
	approved by ANSI. 

finger	A remote check utility to see users and hosts.

FTP	File Transfer Protocol. This is an application to transfer files
	from one IP host to another. The client initiates a connection to
	the server and sends commands to it to indicate which files and the
	method of transfer.

gopher	An client-server networked information service.

Host	A general referrence to a computer system on a network.

hostname On IP networks, this refers to the English (sort of) name given to
	the machine. Can be the same as IP name.

ICMP	Internet Control Message Protocol. This is a diagnostic protocol for
	IP data delivery used by various programs such as Ping. Described by
	RFC 792.

Internet The Internet is a very large system of networks spanning the globe.
	The word "internet" (with small 'i') is also used to describe a WAN.

IP	Internet Protocol. The transport layer which describes a packet
	format for data to pass on a TCP/IP network and on the Internet.
	Described in RFC 791.

IP name The Englishlike name given to an IP host.

IP address The "dotted-decimal" format identifier for each IP host. Eg.
	192.0.0.2 

IPX	Internet Packet Exchange. Novell's Netware packet delivery system
	similar in concept to IP.

ISDN	Integrated Services Digital Network. A hardware description for
	direct links between two areas by way of special telephony.

LAN Manager A proprietory networking system developed by Microsoft.

LocalTalk Apple Computer's proprietory cabling scheme for connecting Macintosh
	systems together. The Appletalk software protocols run over LocalTalk.

login	To connect to a host.

logout	To disconnect from a host.

LPD	Line Printer Daemon. This is a print server for requests by LPR from
	other hosts on the network. Described in RFC 1179.

LPR	Line Printer. This was originally a Unix system command which has
	expanded to include network printing as well on hosts with the LPD

MHS	Mail Handling System. A email distribution protocol similar to SMTP.

MIME	Mail Interface Multimedia Extensions. This is a newer email protocol
	which actually resides above the delivery protocol and describes the
	content format of the email message. It provides extensions for 
	multimedia email. Described by RFC 1341, 1344, 1426, 1428, 1437, 

Netware	A protprietory networking system developed by Novell, Inc.

NDIS	Network Driver Interface Specification. This is an data-link layer
	interface for different systems using a network device. Described by
	the NDIS papers by Microsoft and 3Com.

NFS	Network File System. Please see (A-X).

NIC	Network Information Center of the Internet: internic.net

NIS	Network Information System. This is Sun Microsystems version of
	coordination of network information like hostnames and account
	information. Partially similar to DNS.

NNTP	Network News Transfer Protocol. This is the distribution method
	protocol for USENET newsservice between servers and newsreaders
	(clients). Described in RFC 977 & 1036.

ODI	Open Data-Link Interface. Novell's data-link layer interface similar
	to NDIS for systems using the network interface.

OSI	Open Systems Interconnect. An alternative to the IP suite of
	protocols developed by the International Standards Organization
	(ISO). ISO has its own set of protocols available in the Blue Book. 

Packet Drivers  These are series of software for the data-link layer
	interface, similar to NDIS and ODI but on a lower level for
	programmability. Described by the Packet Driver Specification by
	John Romkey of ftp Software, Inc. (see B-3)

PCNFSD	The daemon utility for authorization of PC-NFS systems. Version 2 is
	the current common usage version.

Ping	This is a utility for checking reachability between Internet hosts.

POP	Post Office Protocol. This is a protocol for server-based e-mail
	packages. Described by POP2 & POP3 descriptions: RFC 918, 937, 1081,
	1082, 1225

PPP	Point-to-point Protocol. A data link layer for connecting two hosts
	directly by serial, modem, or wide-area links. It can carry IP and
	other protocols. Described (for IP) by RFC 1331-1333.

RARP	Reverse Address Resolution Protocol. This is used by hosts to map a
	given hardware address to an IP address. Described by RFC826

RCP	Remote Copy. This utility allows a user to copy files from one host
	to another on a TCP/IP network. 

REXEC	Remote Execute. This utility allows a user to execute commands on a
	remote host from a local host over a TCP/IP network. 

RFC	Request For Comments. The set of standards and protocol definitions 
	now approved by the Internet Engineering Task Force which describes
	the Internet and all its protocols.

.rhosts	This is a file which contains permissions for different accounts
	and hosts to access that user account. Used by RCP, REXEC, RLOGIN
	and RSH.

RLOGIN	Remote Login. This is a application program to connect to remote IP
	hosts similar to the Telnet program. Described by RFC 1258, 1282

RSH	Remote Shell. This allows a user to open a shell on a remote system
	over a TCP/IP network. 

SLIP	Serial-Line Internet Protocol. This is a data-link layer describing 
	Internet connectivity via a serial line or modem between two hosts.
	It is similar to PPP. Described in RFC 1055.

SMTP	Simple Mail Transfer Protocol. The common protocol used in TCP/IP
	networks and the Internet for email delivery. Described by RFC 821.

SNMP	Simple Network Management Protocol. The first version of the network
	management protocol which allows monitoring hosts from remote.
	Described by RFC 1067, 1098, 1157

SNMPv2  SNMP Version 2. This is the latest version of the SNMP protocol
	which is compatible with the original version but includes many
	extensions such as security. Described by RFC 1444, 1446, 1447,
	1448, 1450

tar	A Unix backup utility both local and remote.

TCP	Transmission Control Protocl. This is a connection oriented protocol
	which provides reliable communication between two IP hosts.
	Described by RFC 793.

Telnet	This is a remote connectivity application between IP hosts.
	Described by RFC 764, 854.

Token-Ring This is a physical and data-link layer description for a
	ring-based topology network. 

topology  A somewhat visual description of a network wire system.

TSR	Terminate and Stay Ready. This is a DOS based program which stays in
	memory after it is started and allows the user to continue using
	other DOS programs.

UDP	User Datagram Protocol. This is a connectionless communication
	protocol providing non-reliable data delivery between IP hosts.
	Described by RFC 768

USENET	The news system on the Internet providing information by users of
	the network.

UUCP	Unix to Unix Copy Program. This is a protocol for network
	connectivity by non-interactive distribution of files.

VTxxx   A series of terminal types developed by Digital Equipment Corp.
	which has become a de facto standard.

VxD 	Virtual Device Driver. This is a driver specification which allows
	DOS applications to access network services in MS-Windows.

WAIS	Wide Area Information Services. Another networked information
	service. This one uses the Z39.50 document format for storage.

WINSOCK Windows Sockets API. Please see (F-2).

WWW	World Wide Web. Yet another networked information service.

X.25	A network layer protocol developed by ISO and part of the OSI suite. 

Xserver A program which allows the user to display X windows applications.

Xwindows A networked windowing system commonly found on many workstations
	and Unix systems
	
-------------------------------------------------------------------------------

Section Y: Third Party & Related Software
=========================================

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

Y-1.  eNFS: INTERSTREAM

Company       :	INTERSTREAM, Inc.

Contact	      : 
		
Phone         :	(800) 677-7876
		(412) 323-8000

FAX	      : (412) 323-1930

Email         :	info@interstream.com
		
Postal mail   : INTERSTREAM, Inc.
		1501 Reedsale St.
		Pittsburgh, 
		PA 15233-2329
		USA

Product	      : eNFS

Current Version: ??

Pricing	      : $995 [desktop]
		$1995 [server]

Support	      : ??

Systems	      : SPARCstation 1, 2, SPARCserver 490,690

Services      : server: optimized server board for NFS
		
Size	      : -

Features      : -

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

Y-2.  Multinet: TGV, Inc

Company       :	TGV, Inc.

Contact	      : SALES@TGV.COM or as call and ask for a salesperson.
		
Phone         :	(800) TGV-3440
		(408) 427-4366

FAX	      : (408) 427-4365

Email         :	info@tgv.com	[general questions]
		sales@tgv.com	[sales questions]
		service@tgv.com [technical questions]
		
Postal mail   : 603 Mission St
		Santa Cruz, 
		CA 95060
		USA

Product	      : Multinet, NFS Server, NFS Client, MultiWare NetWare server
		for VMS

Current Version: 3.2 

Pricing	      : call for quotation

Support	      : support contract available, Call.

Systems	      : Any VAX/VMS system V5.0 and later.
                Any OpenVMS AXP system V1.0 and later.

Services      : [call for customization]
		
Size	      : [depends on configuration]

Features      : (NFS Server option supports pcnfsd v2)
		Very complete ONC implementation.


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

Y-6.  SOSS: Rich Braun

Company       :	--

Contact	      : Richard Braun [rbraun@spdcc.com]
		
Phone         :	--

FAX	      : --

Email         :	rbraun@spdcc.com
		stan@cs.uiuc.edu
		
Postal mail   : --

Product	      : SOSS [Son of Stan's Server]

Current Version: 3.2

Pricing	      : free

Support	      : none

Systems	      : MS-DOS 5.x

Services      : server: nfs
		
Size	      : ??

Features      : uses packet drivers. Available from FTP site:
			grape.ecs.clarkson.edu

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

Y-7.  TCPWare for VMS: Process Software Corp.

Company       :	Process Software Corp.

Contact	      : 
		
Phone         :	(508) 879-6994

FAX	      : 

Email         :	
		
Postal mail   : 959 Concord St.
		Farmingham,
		MA 01701
		USA

Product	      : 

Current Version:

Pricing	      : 

Support	      : 

Systems	      : 

Services      : 
		
Size	      : 

Features      :

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

Y-12	MacPPP

Company       :	Merit Network & Univ. of Michigan
		Larry Blunk, Eric Schneider

Contact	      : 
		
Phone         :	

FAX	      : -

Email         :	
		
Postal mail   : -

Product	      : MacPPP

Current Version: 1.1

Pricing	      : free. Available from:
			merit.com:/pub/ppp/macppp.hqx

Support	      : none

Systems	      : Macintosh systems w/ MacTCP 1.1.1

Services      : Point-to-point Protocol driver
		
Size	      : 

Features      : Async serial line connection for Macintosh systems.

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


Section W:  E-mail Software
===========================

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

W-.  CliqAccessories : Quadratron Systems

Company       :	Quadratron Systems

Contact	      : -
		
Phone         :	(805) 494-1158 (California)

FAX	      : (805) 494-1721

Email         :	kathyb@quad.com
		
Postal mail   : Quadratron Systems
		141 Triunfo Canyon Rd.
		Westlake Village,
		CA 91361

Product	      : CliqAccessories

Current Version: 

Pricing	      : $645

Support	      : 

Systems	      : DOS

TCP/IP support: ?

Mail Protocol : SMTP, MHS

Mail Filtering: available

Features      : calender/schedule application, phone book, notepad, calculator

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

W-. Higgins Group Productivity Software: Enable Software

Company       :	Enable Software

Contact	      : -
		
Phone         :	(800) 888-0684 (US)
		(518) 877-8600 (New York)

FAX	      : (518) 877-5225

Email         :	?
		
Postal mail   : Enable Software
		313 Ushers Rd
		Northway Lake,
		NY 12019

Product	      : Higgins Group Productivity Software

Current Version: 2.5

Pricing	      : $695 (8 users)

Support	      : ?

Systems	      : DOS

TCP/IP support: ?

Mail Protocol : Proprietory, SMTP, MHS, X.400/XAPI

Mail Filtering: available

Features      : Calender/schedule software
		Forms processing

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

W-. Linkage: Concentric Technologies

Company       :	Concentric Technologies

Contact	      : -
		
Phone         :	(800) 800-3649 (US)
		(703) 264-8900 (Virginia)

FAX	      : (703) 648-0032

Email         :	?
		
Postal mail   : Concentric Technologies
		12007 Sunrise Valley Dr. 
		Ste 440
		Reston, VA 22091

Product	      : Linkage

Current Version: 4.0

Pricing	      : $69.50

Support	      : ?

Systems	      : DOS, Windows/NT

TCP/IP support: ?

Mail Protocol : SMTP, MHS, X.400/XAPI, UUCP

Mail Filtering: available

Features      : incoming fax to mailbox ability
		voice mail notification.

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

W-.  OpenMail : Hewlett-Packard, Inc.

Company       :	Hewlett-Packard, Inc.

Contact	      : -
		
Phone         :	(800) 752-0900 (US)

FAX	      : -

Email         :	-
		
Postal mail   : HP
		Cooperative Computing Systems Division
		19490 Homestead Rd.
		Cupertino, 
		CA 95136

Product	      : OpenMail

Current Version: ?

Pricing	      : $14 - $50

Support	      : ?

Systems	      : DOS, Macintosh

TCP/IP support: ?

Mail Protocol : SMTP, X.400/XAPI, MAPI, VIM

Mail Filtering: available

Features      : phone book, bulletin board

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

W-. PathWay Messenger : The Wollongong Group

Company       :	The Wollongong Group

Contact	      : Marty Udisches 
		(martyu@twg.com)
		
Phone         :	(415) 962-7202
	      	(800) 962-8649 (California) [toll-free]
       	      	(800) 872-8649 (US)	    [toll-free]
		+1 519 747-9900  (Canada)
		+1 32-27-18-0311 (Europe)

FAX	      : (415) 962-0826 (US)

Email         :	sales@twg.com
		
Postal mail   : The Wollongong Group, Inc.
		1129 San Antonio Road
		Palo Alto, CA   94303
		USA	

Product	      : PathWay Messenger

Current Version: 1.0

Pricing	      : $195

Support	      : call

Systems	      : 80x86 DOS 3.3 +

TCP/IP support: Wollongong PathWay Access

Mail Protocol : SMTP, POP2, POP3, IMAP

Mail Filtering: available

Features      : NETNEWS bulletin board

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

W-.  PC-Eudora: Qualcomm Software, Inc.

Company       :	Qualcomm Software, Inc.

Contact	      : -
		
Phone         :	-

FAX	      : -

Email         :	pc-eudora-info@qualcomm.com
		
Postal mail   : ?

Product	      : PC-Eudora
		Eudora (for Macintosh)

Current Version: 11.10

Pricing	      : free. Available via FTP from:
			ftp.qualcomm.com:/pceudora/windows

Support	      : pc-eudora-bugs@qualcomm.com

Systems	      : 80x86 w/ DOS 3.x

TCP/IP support: builtin + packet drivers

Mail Protocol : SMTP, POP2, POP3

Mail filtering: ??

Features      : POP2/3 news client

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

W-. SelectMail : SunSelect

Company       :	SunSelect

Contact	      : -
		
Phone         :	(800) 24-SELECT (US)
		(508) 442-2300 (Massachussets)

FAX	      : (508) 250-2300

Email         :	-
		
Postal mail   : SunSelect
		2 Elizabeth Drive,
		Chelmsford,
		MA 01824-4195

Product	      : SelectMail

Current Version: 

Pricing	      : $180

Support	      : call

Systems	      : DOS 3.3 +

TCP/IP support: PC-NFS

Mail Protocol : SMTP, POP 2, POP 3

Mail Filtering: none

Features      : independant message folders
		deferred semdomg
		automated scheduler and backup

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


Section X:  X-windows Software
==============================

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

X-1.  eXceed: Hummingbird Communications Ltd

Company       :	Hummingbird Communications Ltd

Contact	      : -
		
Phone         :	(416) 470-1203 [US & Canada]
		+41 22 7331858 [Europe]

FAX	      : (416) 470-1207 [US & Canada]
		+41 22 7336403 [Europe]

Email         :	sales@hcl.com
		
Postal mail   : 2900 John Street, 
		Unit 4, Markham,
		Ontario, L3R 5G3
		Canada
	
		37-39 rue de Vermont,
		1202 Geneva,
		Switzerland

Product	      : HCL eXceed/W

Current Version:

Pricing	      : ??

Support	      : site license available in UK from Chest

Systems	      : MS-Windows 3.x

Services      : clients: telnet, FTP, Launch Pad (Menuing facility), Xtrace
			(protocol tracing)
		servers: X11R5 (support for scalable fonts, font servers,
			XDMCP security)
		
Size	      : 

Features      : 24-bit color & plane mask support
		supports 15 different TCP/IP transports & DECnet
		Xlib, Xt intrinsics, Xaw (Athena Widgets) & Xmu (Motif) 
		libraries
		HCL-eXceed Plus - DOS-based X server with local window
		manager and support for EGA, VGA & SVGA
		HCL-eXceed HiRes - same as "Plus" but also supports 8514A,
		XGA, TIGA 2
		HCL-eXtend - UNIX host based X clients for accessing DOS
		services 
		HCL-eXceed/Xpress - High performance X server over phone
		lines
		HCL-eXceed/NT - X server for PC's running Windows NT
		HCL-eXceed/NT-XDK - X Development Kit for Windows NT

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

X-2.  eXcursion for Windows: Digital Equipment Corp.

Company       :	DEC

Contact	      : 
		
Phone         :	

FAX	      : 

Email         :	
		
Postal mail   : 

Product	      : eXcursion for Windows

Current Version: 1.0

Pricing	      : 

Support	      : 

Systems	      : 80x86 w/ 2MB RAM & DOS 3.0 & higher & MS-Windows 3.0 or higher

Services      : 
		
Size	      : 7-15 MB [on disk]

Features      : Works with:
		   Pathworks for DOS (DECnet, TCP/IP)
		   PC/TCP
		   3Com 3+Open TCP 
	        cut & paste between Xwindows & MS-Windows
		SNF font compiler
		keyboard redefinition
		three button mouse emulation.

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

X-3.  eXodus: White Pines Software, Inc.

Company       :	White Pines Software, Inc.

Contact	      : 
		
Phone         :	(603) 886-9050

FAX	      : (603) 886-9051

Email         :	sdarling@wpine.com
		
Postal mail   : White Pine Software, Inc.
	        40 Simon Street, Suite 201
	        Nashua, NH 03060-3043
		USA

Product	      : eXodus for Macintosh
		eXodus for MS-Windows
		(also available eXodus for NeXTSTEP)

Current Version: 5.0 

Pricing	      : eXodus for Macintosh  : $296 /copy
		eXodus for MS-Windows : $449 /copy

Support	      : 

Systems	      : Macintosh w System 6.x & higher or A/UX, MS-Windows 3.x

Services      : server: X11R5 
		
Size	      : 

Features      : XDMCP security, ICCCM compliant, XRemote
		Backing store support, Multiple X screen support, Font
		servers, rootless & rooted windows
		Supports Motif, OpenLook, DECWindows
		 eXodus for Macintosh supports:
			  MacTCP, Novell TCPort/LAN Workplace, TSSnet (Thursby
			  Software Systems), DECnet (CommUnity-Mac), DECnet
			  (Pathworks), ADSP (Pathworks), Appletalk.
			MultiFinder support, 
			System 6.x or later
			eXodus I for Macintosh runs without FPU (MacIIsi,
			  LC, LCII, LCIII, 512k, etc.)
			eXodus II for Macintosh requires an FPU (most other
			  Macs) 
	         eXodus for MS-Windows

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

X-4.  Micro X-Lite: StarNet Communications Corporation

Company       :	StarNet Communications Corporation

Contact	      : Dick Montgomery (dick@starnet.com)
		
Phone         :	(408) 739-0881		

FAX	      : (408) 739-0936

Email         :	microx@starnet.com
		
Postal mail   : StarNet Communications Corporation
		3073 Lawrence Expressway
		Santa Clara, CA 95051

Product	      : Micro X-Lite, X-enlite, X-DOS, X-WIN

Current Version: X-Lite - 	1.7.2 
		 X-enlite - 	1.5.3
		 X-DOS    -	1.7.2
		 X-WIN	  - 	2.5.4

Pricing	      : X-Lite - 	$75
		X-enLite -	$150
		X-DOS -		$345
		X-WIN - 	$425

Support	      : call or support@starnet.com

Systems	      : 80x86 w/ 640 KB & DOS 3.1 or higher (X-Lite)
		80386 w/ 2MB RAM & DOS 3.1 & higher (X-enlite, X-DOS)
		80386 w/ 4MB RAM & Win 3.x (X-WIN)

Services      : servers: X11R4 (w/ builtin TCP/IP)
		X-WIN: X11R5 
		
Size	      : X-Lite 2MB [on disk]
		X-DOS, X-enLite - 4MB [on disk]
		X-WIN - 5 MB [on disk]

Cards	      : 3Com 3C501, 3C503 (Etherlink II), 3C505, 3C523
        	Cabletron 1000, 2000, & 3000
        	Micom-Interlan NI5010 & NI5210
        	Western Digital WD80003E
        	Novell NE-1000 & NE-2000
		Packet driver supported cards

Features      : Supports StarNet TCP/IP (integrated), BW-TCP, PC/TCP, Novell
		LWP, PC-NFS, Lanera TCPOpen, Winsock 1.1
		Support for Motif, OpenLook & DECWindows.
		Graphics cards supported: 
		  Ahead V5000, ATI 18800, Everex VP, Everex VGA, Genoa 6400, 
		  Paradise 900C00, 900C11, 900C30, STB EM-16, Trident
		  8800CS, ET-3000, ET-4000, Video7 HT208, Video7 V7VGA,

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

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 1993 19:25:33 GMT
From:      rawn@lead.aichem.arizona.edu (Rawn Shah)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.answers,news.answers,comp.sys.mac.comm
Subject:   NFS & TCP/IP FAQ for PCs & Macs [part 05/06]

Archive-name: pcnfs-faq/part5
Last-modified: 1993/10/28
Version: 1.5



X-5.  MultiView/X: JSB Corporation

Company       :	JSB Corporation

Contact	      : 
		
Phone         :	(800) 359-3408 [US]
		(408) 438-8300 [US, Calif]
		+44 0625 433618 [UK]

FAX	      : (408) 438-8360

Email         :	
		
Postal mail   : 

Product	      : MultiView/X

Current Version:

Pricing	      : 

Support	      : call

Systems	      : 80x86 w/ DOS 3.x & higher & MS-Windows 3.x

Services      : server: X11R4 (full font library, XDMCP)
		
Size	      : 

Features      : Supports
		  RS232 direct & modem connections
		  3Com 3+Open TCP,
		  BW-TCP,
		  D-Link TCP/IP for DOS,
		  PC/TCP,
		  HP Arpa Services for DOS,
		  IBM AIX access for DOS,
		  Locus TCP/IP,
		  MS LAN Manager for Unix,
		  Novell LAN Workplace for DOS,
		  SCO Xenix-Net,
		  SunSelect PC-NFS,
		  Ungermann-Bass Net/One,
		  Wollongong PathWay for DOS,
		  
		Support for passive telnet, rsh, rexec, & XDMCP startup
		modes
		BDF to Windows font compiler

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

X-6.  PC-Xware & PC-Xview : NCD, Inc.

Company       :	Network Computing Devices, Inc.

Contact	      : Tom Holder
		
Phone         :	(800) 697-7638 [US, NCD sales]
		(503) 641-2200 [US, PC-Xdivision]
		0628-822228    [UK sales]
		+03 5276 2411  [Japan sales]

FAX	      : (503) 643-8642

Email         :	thom@pcx.ncd.com
		
Postal mail   : Network Computing Devices, Inc.
		PC-Xdivision
		5990 SW Gemini Drive
		Beaverton, Oregon 97005
		USA

Product	      : PC-Xware for Windows 
		  "      NetPack     - Chameleon additions
		  "      NetPackNFS  - Chameleon NFS additions
		  "	 Remote      - Xremote (X over Serial lines) version

		PC-Xview for DOS     - X11R4 compatible, DECwindows support,
		   		       Graphics(CGA,MGA,EGA,VGA,SVGA,8514/A,  
  				       TIGA,DGIS,XGA)
			"	  Xremote edition

		XRemote Host Software

Current Version:

Pricing	      : 
						     Multi-user
	PC-Xware for Windows	Part #   List   20-49  50-99  100-199  200+
	+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
	PC-Xware		PC2510	$545    $327   $289    $245    $218
	PC-Xware NetPack	PC2530	$735    $441   $404    $382    $360
	PC-Xware NetPackNFS	PC2540  $795    $477   $437    $413    $390
	PC-Xware Remote		PC2520  $275    $179   $171    $162    $154

	PC-Xview for DOS	PC1270  $445	$267   $236    $200    $178
	PC-Xview for DOS: 	PC1290  $199	$129   $123    $117    $111
	  PC-Xremote Edition

	XRemote Host Software:  PC3020	$100
	  PC Edition

	Manuals
	-------
	PC-Xware for Windows	PC2510-2 $25
	PC-Xview for DOS	PC1270-2 $25

Note: All PC-X software is shipped single media (3.5") except PC-Xview for
DOS (dual). To order 5.25" media include and additional line item with the
product part number and a "-M".

Multi-User licenses includes one set of software and one manual for on-site
installation by system administrator.
To order Multi-user licenses, add a "-S" to the part number and note the
quantity desired. For multi-user licenses over 500 copies, contact the
PC-Xdivision. 

The price for expanding an existing multi-user license is based on the total
number of seats at a site after ther expansion, not on the current number
being added. To order an expansion, add a "-SA" to the part number and note
the current number being added and the original multi-user license
identification number.
	   
Support	      : 

Annual Maintenance
------------------
Annual maintenance provide multi-user customers with periodic software
updates. The rates are 15% of the multi-user license total. Customers with
colume packaged product in excess of 20 seats may also purchase Annual
Maintenance at 15% of the equivalent Multi-user License total. Bothe
Multi-User and packaged product customers receive one copy of the disks and
documentation for each update. When adding additional seats, the cost is
1.25% of the additional seat cost, product number; to order additional
maintenance to an existing agreement, add a "-AA" to the product number. In
both instances, Multi-User customers must include their license
identification number.

Systems	      : DOS 3.2x or higher (for PC-Xview for DOS),
	        MS-Windows 3.x (for PC-Xware for Windows) with:
			80386
			4 MB RAM

Services      : clients: terminal emulation (VT 100, 102, 220, 320), 
			 NFS (optional), FTP (optional), telnet,
			 SMTP, POP2, SNMP, window managers (NCDwm,
			 MS-Windows, Host-based [OpenLook, Motif, etc])
		servers: X11R5 (Font server support w/ TrueType & ATM for
			 Windows, XDMCP support, Backing store, Save under
			 and shape extension support) for Windows version,  
			 X11R4 for DOS version, XRemote 
		
Size	      : 5 MB [on disk] 

Features      : Uses NetManage TCP/IP product for communication.
		DECnet support via DEC PathWorks.
		Supports CGA, EGA, VGA, SVGA, XGA, TIGA, 8514/a, Japanese
 			Graphics mode
		Third-Party TCP/IP include:
			Beame & Whiteside Software, Ltd.
			DEC
			Frontier Technologies Corp.
			FTP Software, Inc.
			Hewlett-Packard Corp.
			Microsoft Corp.
			Novell, Inc.
			Sun Microsystems, Inc.
			Ungermann-Bass, Ltd.
			The Wollongong Group, Inc.
			3Com Corp.
			Windows Sockets API
		Can be run from a server.
		cut & paste between Xwindows & MS-Windows
		Administration & configuration:
		   License server capability
		   Remote configuartion cia NCDware User Services
		   SNMP with NCD MIB extensions for X

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

X-7  PC X-Server & PC-Link: XLink

Company       :	XLink

Contact	      : 
		
Phone         :	(408) 263-8201

FAX	      : (408) 263-8203

Email         :	
		
Postal mail   : XLink
		741 Ames Ave.,
		Milpitas CA 95035
		USA

Product	      : PC X-Server
		PC-Link

Current Version:

Pricing	      : PC X-Server	$249
		PC-Link		$99

Support	      : 

Systems	      : 386 w/ 4 MB, DOS 3.3 

Services      : clients: telnet (vt 52, 100, ANSI), FTP, TFTP, NFS, Tar
		servers: X11R5 (PC X-Server)
		
Size	      : 2 MB [on disk] 

Features      : Supports NDIS, ODI, SLIP, Packet drivers
		Supports S-3 based adapters, 8514 based adapters, 
		SVGA [Paradise/Western Digital WD90C00/11/30/21,
		OAK 067/077, Trident 8900/9000, Tseng ET3000/ET4000, ATI
		Wonder, Cirrus Logix 542x, Video 7 HT208/209/216] & VGA
		X server recognizes SNF, PCF & SPD fonts

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

X-8.  PC Xsight: Locus Computing Corporation

Company       :	Locus Computing Corporation

Contact	      : -
		
Phone         :	(800) 955-6287 [US]
		(213) 670-6500 [US, Calif]
		+44 296 89911  [UK]

FAX	      : -

Email         :	-
		
Postal mail   : 9800 La Cienega Blvd.
		Inglewood, CA 90301
		USA
		
Product	      : PC Xsight

Current Version:

Pricing	      : 

Support	      : 

Systems	      : 8088, 8086, 80x86, DOS 3.1 or later
		
Services      : 
		
Size	      : 512 KB base memory, 896 extended memory,
		1 MB [disk usage]

Cards	      : Excelan EXOS 205/205T
		3Com 3C501
		Western Digital WD8003E
		Micom NI5210
		Multitech 5220

Features      : supports 2 or 3 button mouse
		EGA, VGA, Hercules, AT&T 6300



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

X-9.  PC DECWindows Motif : Digital Equipment Corporation

Company       :	Digitial Equipment Corporation

Contact	      : 
		
Phone         :	

FAX	      : 

Email         :	
		
Postal mail   : PC DECWindows Development
		Digital Equipment Corporation
		30 Porter Rd.
		Littleton, MA 01460
		USA

Product	      : PC DECWindows Motif

Current Version: 3.0

Pricing	      : 

Support	      : 

Systems	      : 

Services      : 
		
Size	      : 

Cards	      : ??

Features      : Supports EGA (16 col. & mono), MCGA, VGA (16 color & mono)
		 enhanced VGA (800x600 16 color & mono), 8514/a (1024x768 
		 16/256 color)
		X11 Release 4 server
		integrated memory manager
		Font compiler for Adobe Bitmap Distribution files
		Supports TCP/IP & DECNET from DEC.

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

X-10.  Reflection X : Walker, Richer & Quinn

Coming soon

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

X-11.  X Appeal : Xtreme s.a.s.

Company       :	Xtreme s.a.s.

Contact	      : Giovanni Novelli
		
Phone         :	-

FAX	      : +39 586-502310 [Italy]

Email         :	xappeal@xtreme.it
		
Postal mail   : Xtreme s.a.s.
		Livorno, Italy

Product	      : X Appeal

Current Version: 1.3

Pricing	      :			   Price per copy for 
	 Product        1 copy  20 copies  50 copies  100 copies  200 copies
	====================================================================
	X Appeal        US$250    US$218     US$184     US$150	  US$117

	unlimited site license: US $30,000

	additional 30% off for educational institutions.

	Demo versions available from:
		garbo.uwasa.fi: pc/demo/{xap13exe.zip, xap10fon.zip}

Support	      : -

Systems	      : 386SX or higher w/ 2MB RAM (4MB rec.) & DOS 3.3 or higher

Services      : X11R5 (inc. PEX, font server, european keyboard layouts, XDMCP)
		
Size	      : ~ 3MB [on disk]

Cards	      : packet driver support.

Features      : TCP/IP included.
		Support for OpenWindows, DECWindwos fonts
		Support for MIT X-Authorization (Magic cookie)
		Graphics support: SVGA (256 col.), Ahead V5000B, C&T 82C452,
		NCR 77C22E, Genoa (6400), Oak Tech. (OTI-067),
		Paradise/Western Digital WD90C00, Trident 8900, 
		Trident 8900C,  Tseng Labs (ET3000, ET4000).

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

X-12.  Xoftware : AGE Logic, Inc.

Company       :	AGE Logic, Inc.

Contact	      : Craig  A. Schmidt, VP Marketing
		Scott Sabul
		
Phone         :	(619) 455-8600
		(619) 565-7373

FAX	      : (619) 597-6030

Email         :	sales@age.com
		
Postal mail   : AGE Logic, Inc.
		9985 Pacific Heights Blvd.
		San Diego, CA 92121-4337
		USA

Product	      : Xoftware for DOS
		Xoftware/32 for MS-Windows
		Xoftware/32 for MS-Windows NT 
		Xoftware for Windows Desktop Edition (DT).

Current Version: DOS - 1.4
		 Windows - 2.02
		 Windows DT - 1.7
		 Windows NT - 1.0

Pricing	      : Xoftware for DOS - $195
		Xoftware/32 for Windows - $395
		Xoftware/32 for NT - $495
		Xoftware for Windows Desktop Edition - $195
		  
Support	      : telephone support 7am-5pm (PST), BBS

Systems	      : 80386 w/ 2 MB RAM & Windows 3.x or higher (Windows ver)
		80286 w/ 2 MB RAM & DOS 3.1 or higer (DOS ver.)
		x86 or MIPS R4000 systems (NT ver)

Services      : server: X11R5 server
		
Size	      : 2 MB [disk space]

Cards	      : depends on Network software used:
		  3Com 3+Open TCP 1.2 or higher
		  DEC Pathworks TCP/IP 1.1 or higher
		  PC/TCP 2.05 or higher
		  Novell LAN Workplace 4.01 or higher
		  SunSelect PC-NFS 3.5 or higher
		  Wollogong PathWay 2.05 or higher
		  Ungermann-Bass Net/ONE TCP 16.5 or higher
		  Wollongong WinTCP 1.1 or higher
		  Wollongong PathWay Access 4.1.1 or higher
		  Walker Richer, Quinn TCP 2.0 or higher
		  winsock version available (call AGE)

Features      : Hotkeys to DOS & MS Windows
		Motif, OpenLook, DECWindows support
		International keyboard support
		Full SNF font library
		Supports EGA, VGA, SVGA, 8514
		XDMCP support, 32 bit Xserver.

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

X-13.  X/Vision: Visionware

Company       :	Visionware 

Contact	      : A. Rodriguez [US]
		
Phone         :	(800) 949-8474 [US]
		(415) 325-2113 [US, California]
		+44 532 788858 [Europe]

FAX	      : (415) 325-8710 [US]
		+44 532 304676 [Europe]

Email         :	vware@visionware.co.uk
		
Postal mail   : VisionWare
		1020 Marsh Road, Suite 220
		Menlo Park, CA 94025
		USA
		
		57 Cardigan Lane
		Leeds LS4 2LE
		UK

Product	      : X/Vision

Current Version: 5

Pricing	      : $395 single. site licenses available (call)

Support	      : unlimited toll-free telephone support dor all VisionWare
		products 

Systems	      : MS-DOS 3.0 or later, MS-Windows 3.x, Windows NT
		1.2 MB 5.25" or 1.44 MB 3.5" floppy drive
		2MB of RAM required; 4MB recommended

Services      : clients: object-oriented desktop (drag & drop facility),
                        VT320 emulation, REXEC, RSH, RLOGIN and telnet,
			file transfer & local printing 
		server: X11R5 server (fonts, font server & XDMCP security)

Size	      : 

Features      : Optimized serial communication support via XRemote support
		Comprehensive 24-bit color support
		Automatic network protocol detection and configuration
		Automatic font substitution as well as standard MIT fonts
		(75 & 100 dpi), DECwindows and Open Look. TrueType and
		Adobe fonts can be mapped.
		SHAPE extensions, XRemote support.
		Will work with the following systems:
			Beame & Whiteside TCP/IP
			DECnet
			Excelan LAN WorkPlace 3.5
			FTP PC/TCP 2.05 & 2.03/4
			Hewlett Packard ARPA Services 2.0 & 2.1
			Locus TCP/IP for DOS v1.0 & 2.0
			NetManage Newt & Chameleon
			Novell LAN WorkPlace for DOS 3.5 & 4.0
			Novell Netware
			Sun PC-NFS v3.5 & 4.0
			Ungermann-Bass NET/One TCP-PC 16.4
			Wollongong PathWay 2.0
			Wollongong WIN/TCP for DOS
			Windows Sockets Interface
			3Com TCP 1.2 (3+Open)
		
-------------------------------------------------------------------------------

X-14.  X-Windows for OS/2: IBM

Company       :	IBM

Contact	      : -
		
Phone         :	(800) IBM-CALL

FAX	      : (303) 440-1639

Email         :	-
		
Postal mail   : 

Product	      : IBM X-Windows for OS/2  (PTP# 02G6980)

Current Version: 1.2.1

Pricing	      : $150 X-Windows
		$350 X-Windows & TCP/IP for OS/2 [TCP/IP package required to
		run] 

Support	      : call

Systems	      : 80386SX or higher w/ 6MB RAM & OS/2 2.x 

Services      : server: X11R5 (font library & compiler)
		
Size	      : 

Features      : Support for EGA, VGA, SVGA, XGA, 8514/a, any other OS/2
		  supported cards
		Requires IBM OS/2 TCP/IP
		Other modules available: NFS, Programmers Toolkit (RPC,
		  sockets API, resolver API, Kerberos, etc.)

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

Section Z: Organizations, Products & Other Information sources
==============================================================

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

Z-1.  AIR for Windows: SPRY, Inc.

Company       :	SPRY, Inc.

Contact	      : -
		
Phone         :	(206) 447-0300

FAX	      : (206) 447-9008

Email         :	sales@spry.com
		
Postal mail   : 316 Occidental Avenue South
		Seattle, Washington 98104
		USA

Product	       :AIR for Windows

Current Version:

Pricing	      : single copy = $162 (UniDirect price, NOT list)
		10-more     = less than $100

Support	      : 

Systems	      : MS-Windows 3.1

Services      : clients: telnet (vt220), FTP, LPR, Ping, NFS client
		(option), (support for TN3270, X-servers, SQL databases)
		AIRMAIL (smtp)
		
Size	      : 

Features      : supports ODI & NDIS
		Windows Sockets support.

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

Z-2.  BW-NFS & BW-TCP: Beame & Whiteside

Company       : Beame & Whiteside Software Ltd.

Contact       : Terry Woloszyn

Phone         : (919) 831-8989

FAX           : (919) 831-8990

Email         : sales@bws.com

Postal mail   : Beame & Whiteside Software Ltd.
		706 Hillsborough St.
		Raleigh, North Carolina
		USA, 27603-1655

Product       : BW-TCP, BW-NFS, BW-NFS for Lan WorkPlace, Boot Proms

Current Version: BW-TCP and BW-NFS version 3.0, BW-NFS for LWP v2.3

Pricing       : 
		Order #         Description                     Purchase 
                		                              Price per Copy 
		============================================================
		BW310           BW-TCP                          $245.00
		BW410           BW-NFS                          $349.00
		BW420           BW-NFS for LAN WorkPlace        $245.00
		BW430           BW-NFS for Ungermann-Bass       $245.00
		BW511           BW-BOOTP PROM (WD80x3)           $50.00
		BW512           BW-BOOTP PROM (3C501)            $50.00
		BW551           BW-BOOTR PROM (WD80x3)           $50.00
		BW552           BW-BOOTR PROM (3C501)            $50.00

		"Right to Copy" discounts are offered for all products
		except for BW-BOOT PROMS.  Discounts are calculated by the
		number of individual copies ordered multiplied by the
		purchase price per copy minus the discount level percentage.

		    Example:  BW-NFS required for 37 computers (Level 2)
                      37 x $349.00 = $12,913.00 - 36% ($4,648.68) = $8,264.32
	
Description   Level  Level  Level   Level    Level   Level     Level   Level
                1      2      3       4        5       6        7        8

No. of Copies  5-19  20-49  50-99  100-249  250-499  500-749  750-999  1000+
Discount        30%    36%    39%     46%      55%      62%      66%    69%

		FOB Shipping Point
		All pricing is quoted in United States dollars.
		Shipment (unless otherwise requested): UPS Air.
		Prices subject to change without notice.
		Media (unless otherwise requested): 3«"

Support       : we do offer a maintenance and support agreement (if you
		would like further info I can fax it to you), phone support
		is through the telephone number above or by email at 
		support@bws.com, 
		Ftp sites are:  
			dorm.rutgers.edu 	and 
			ftp.bws.com

Systems       : DOS 3.1 and above, DRDOS 6.0, MS-Windows 3.x

Services      : client: NFS (up to 24 disks, 8 printers), telnet (vt52,
			vt100, vt220),  TN3270, FTP, ping, TFTP, XMODEM, 
			 Kermit, finger, whois, nslookup, traceroute
			(TROUTE), talk, POP2/3, SMTP, BW-TAR, COM14

		server: ftpd, fingerd, lpd, tnamed, talkd/ntalkd, cookied,
			telnetd, inetd, snmpd

Size          : BW-TCP 26K typical configuration, loadable high
		BW-NFS 30K typical configuration, loadable high
		approx 2 MB on hard disk

Features      : BW-NFS includes BW-TCP product.
		NDIS/Packet/ODI drivers supported, co-existance with
 		Novell, SLIP, Boot PROMs, third party applications - x vendors
		currently have a sockets diskette that we will ship if asked
		for, WINSOCK support within one month.
		First INETD for Windows. Supports TELNETD with remote logins
		as virtual DOS windows.
		Supported Network Interface cards:
			3Com 3C501, 3C503
			SMC Elite Series,
			NDIS, ODI, Packet driver, SLIP, Token-Ring Interfaces
		Minimum Configuration required:
			IBM PC or 100% compatible with 256K Ram
			One floppy disk drive

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

Z-3.  Chameleon NFS: NetManage, Inc.

Company       :	NetManage, Inc.

Contact	      : Zvi Alon & Fritz Mueller
		Jerry Kenny
		
Phone         :	(408) 973-7171

FAX	      : (408) 257-6405

Email         :	support@netmanage.com
		
Postal mail   : NetManage, Inc.
		20823 Stevens Creek Blvd,
		Cupertino, CA 95014
		USA

Product	      : Chameleon NFS

Current Version: 3.10

Pricing	      : Site License pricing available on request.
	
	Product				Price	Product #
	====================================================
	Chameleon			$400	P/N CHAM-001
	ChameleonNFS			$495	P/N CHNS-001
	Xsession			$445
	Chameleon32 (NT Developer rel)	$495	P/N IPXL-001
	IPX/Link (Netware option)	$150
	NEWT-SDK (req. Chameleon)	$500
	RPC-SDK	(req. Chameleon & NEWT)	$500
			
Support	      : support@netmanage.com
		(408) 973-7171 [9am-9pm (EST), weekdays]
		quarterly newsletter.
		FTP server (ftp.netmanage.com)
		Maintanence contracts are available which give free support
		and free upgrades for 1 year.

Systems	      : MSDOS 5.x, Windows 3.x

Services      : client: telnet (vt 52, 100, 220, ANSI), TN3270, FTP, TFTP,
			SMTP, POP2, SNMP, Ping, BIND, NFS, Finger, Whois,
			BOOTP, Statistics, IP Routing
		server: TFTP, FTP, NFS, DNS, SMTP, POP2, SNMP Agent

Size	      : 6KB (RAM), 3 MB of disk space

Features      :	100% DLL
		5 minute installation
		All applications are Windows based
		supports Ethernet, Token-Ring, FDDI, NDIS, SLIP, X.25
		WinSock API, Berkeley 4.3 sockets API, ONC RPC/XDR,
		and WinSNMP API tools available
		Works concurrently with Netware, LAN MAnager, Vines, etc.
		Up to 64 concurrent sessions.
		Overnight delivery
		PC X server and DOS based product are available
		A product for Windows NT is available.

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

Z-4.  CU/TCP: Clarkson University

Organization  :	Clarkson University & Rutgers University

Contact	      : -
		
Phone         :	-

FAX	      : -

Email         :	
		
Postal mail   : -

Product	      : CU/TCP 

Current Version: 2.5

Pricing	      : free. Available from the following sites:
			ftp-ns.rutgers.edu:/pub/msdos/cutcp/current/*

Support	      : none

Systems	      : MS-DOS

Services      : clients: telnet (vt100), TN3270, FTP, SLIP 
		servers: ftpd (during open connections only)

Size	      : 

Features      : works with the following drivers:
			3c503, appletalk, slip, WD8003
		works with Packet drivers, ODI
		

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

Z-5.   Distinct TCP

Company       :	Distinct Corp.

Contact	      : -
		
Phone         :	(408) 741-0781

FAX	      : -

Email         :	mktg@distinct.com
		
Postal mail   : Distinct Corp.
		14082 Loma Rio Drive,
		Saratoga, 
		CA 95070
		USA

Product	      : Distinct TCP

Current Version: 3.02

Pricing	      : 

Support	      : 

Systems	      : 

Services      : 
		
Size	      : 

Features      : supports Ethernet, Token-Ring, packet drivers, NDIS, SLIP,
		PPP, ODI

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

Z-7.  LAN Workplace: Novell, Inc.

Company       :	Novell, Inc.

Contact	      : -
		
Phone         :	(800) 772-UNIX

FAX	      : -

Email         :	
		
Postal mail   : Novell, Inc.
		122 East 1700 South,
		Provo,
		UT 84606
		USA

Product	      : LAN Workplace

Current Version: 4.1r8

Pricing	      : 

Support	      : 

Systems	      : 

Services      : 
		
Size	      : 

Features      : support Ethernet, Token-Ring, packet drivers (shim), NDIS
		(shim),	SLIP, PPP, ODI

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

Z-8.  NCSA Telnet: National Center for Supercomputing Applications

Company       :	National Center for Supercomputing Applications

Contact	      : -
		
Phone         :	-

FAX	      : -

Email         :	
		
Postal mail   : 

Product	      : WinTel v1.0b.1 (MS-Windows version)
		NCSA Telnet (DOS version)
		NCSA Telnet (Macintosh version)

Current Version: 2.5

Pricing	      : free. Available from the following sites:
			zaphod.ncsa.uiuc.edu:/PC/Telnet/msdos
			zaphod.ncsa.uiuc.edu:/PC/Telnet/windows

Support	      : none.

Systems	      : MS-DOS, MS-Windows, MacOS

Services      : clients: telnet (vt100), TN3270, FTP, SLIP 
		servers: ftpd (during open connections only)

Size	      : 

Features      : works with the following drivers:
			3c503, appletalk, slip, WD8003
		works with Packet drivers

-------------------------------------------------------------------------------
Z-9.  NFS/Share: Intercon Systems Corp

Company       :	Intercon Systems Corp.

Contact	      : sales@intercon.com
		
Phone         :	(703) 709-55000

FAX	      : (703) 709-5555

Email         :	sales@intercon.com
		
Postal mail   : 950 Herndon Pkwy,
		Suite 420
		Herndon,
		VA 22070
		USA

Product	      : NFS/Share

Current Version: 1.3

Pricing	      :

	Number of Copies	Cost
	===============================
	1 copy 			$295
	10-user bundle 		$2,495 
	25-user bundle 		$4,995 
	50-user bundle 		$8,900 
	100-user bundle 	$14,950 

	educational discounts available.


Support	      : First 90 days of support free;
		Extended support may be purchased separately
		Technical support: (703) 709-5520 or
				   tech@intercon.com

Systems	      : Macintosh II series, System 6.05 or later

Services      : NFS/Share: NFS client for Macintosh systems.
		
Size	      : 212 KB 

Features      : Simple to use--Files from the remote systems take on the 
		familiar format of the Mac documents you always use. There 
		are no new operating procedures or software systems to
		learn. Certain text files, such as UNIX, are accessible 
		from any Macintosh editor or word processor.

		Macintosh resident--Once you have the physical link to the 
		network and NFS/Share, you need nothing other than access 
		to NFS servers on the network. NFS/Share works with
		Macintosh computers and is completely System 7.0 compatible.

		Access multiple remote machines easily--Just go through Apple's 
		Chooser and you are there. A list of available servers or
		remote systems appears in a pop-up window. You can access
		several remote machines at the same time, and, just like
		your hard drive, they appear as icons on your desktop.

		Apple standard--NFS/Share uses Apple's defined standards 
		(AppleSingle or AppleDouble) for representing files for
		foreign file systems.

		Simultaneous access--Multiple users can easily access the same 
		information at the same time without the need for different
		mounting points.

		Security maintained--User authentication is done through Sun 
		Microsystems' NIS (Yellow Pages), PCNFSD, or BWNFSD. Each
		user is presented with lists of access or mounting points
		automatically.


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

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 1993 19:26:50 GMT
From:      rawn@lead.aichem.arizona.edu (Rawn Shah)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.answers,news.answers,comp.sys.mac.comm
Subject:   NFS & TCP/IP FAQ for PCs & Macs [part 06/06]

Archive-name: pcnfs-faq/part6
Last-modified: 1993/10/28
Version: 1.5



Z-10.   NS & ARPA Services: Hewlett-Packard

Company       :	Hewlett-Packard

Contact	      : -
		
Phone         :	(408) 725-8111

FAX	      : 

Email         :	
		
Postal mail   : Hewlett-Packard
		19420 Homestead Rd., 
		Cupertino, 
		CA 94014
		USA

Product	      : NS & ARPA Services

Current Version: 2.5

Pricing	      : 

Support	      : 

Systems	      : 

Services      : 
		
Size	      : 

Features      : supports Ethernet, Token-Ring, packet drivers, NDIS, ODI (shim)

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

Z-11. PathWay Access & Client NFS:The Wollongong Group, Inc.

Company       :	The Wollongong Group, Inc.

Contact	      : Marty Udisches
		(415) 962-7226 
		martyu@twg.com
		
Phone         :	(415) 962-7202
	      	(800) 962-8649 (California) [toll-free]
       	      	(800) 872-8649 (US)	    [toll-free]
		+1 519 747-9900  (Canada)
		+1 32-27-18-0311 (Europe)

FAX	      : (415) 962-0286 (US)

Email         :	sales@twg.com

Postal mail   : The Wollongong Group, Inc.
		1129 San Antonio Road
		Palo Alto, CA   94303
		USA	
		
Product	      : PathWay Access & Client NFS [PathWay product line]

Current Version: 2.0

Pricing	      : PathWay Access - $350 (multi-copy pricing - call)
		Client NFS - $95
		API Developer's Kit for DOS/Windows - $200
		
Support	      : call

Systems	      : MS-DOS 5.x, MS-Windows 3.x

Services      : clients: telnet (vt 100, 200, 320, 330) IBM TN3270 (model 2
			- 5), IBM 3179g, Tektronix 4010, FTP, mail,
			newsreader, scripting language. NFS, LPR 
		servers: ftpd, 

Size	      : 50-60 KB (in RAM)

Features      : adjustable read & write block sizes
		available standalone or as option to Pathway Access TCP/IP
		package.
		similar functionality, look-and-feel & API compatibility
		across DOS, MS-Windows, Macintosh, OS/2, OpenVMS.
		Support for ODI, NDIS, PDS, ASI, ODI/NDIS, SLIP, PPP,
		IPX/NDIS, IP/IPX, IP/NetBIOS.
		Support for Etherenet, Token-Ring, Async, X.25

Special	      : for Pathway Access: 30-day free evaluation copy.

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

Z-X.   PathWay Access for Macintosh: The Wollongong Group

Company       :	The Wollongong Group

Contact	      : George Stump & Marty Udiches
		(gstump@twg.com & martyu@twg.com)
		
Phone         :	(415) 962-7202
	      	(800) 962-8649 (California) 
       	      	(800) 872-8649 (US)	    
		+1 519 747-9900  (Canada)
		+1 32-27-18-0311 (Europe)

FAX	      : (415) 962-0286 (US)

Email         :	sales@twg.com

Postal mail   : The Wollongong Group, Inc.
		1129 San Antonio Road
		Palo Alto, CA   94303
		USA	
		
Product	      : PathWay Access & Client NFS [PathWay product line]

Current Version: 

Pricing	      : Access for Macintosh - $295
		Client NFS	     - $295

Support	      : call

Systems	      : Macintosh II series

Services      : clients: telnet (vt 100, 200, 320, 330) IBM TN3270 (model 2
			- 5), IBM 3179g, Tektronix 4010, FTP, mail,
			newsreader, scripting language. NFS, LPR 
		servers: ftpd, 

Size	      : -

Features      : Supports Ethernet.

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

Z-12.  PathWay Access for OS/2: The Wollongong Group

Company       :	The Wollongong Group

Contact	      : Jeff Oxendine
		(415) 962-7143 
		
Phone         :	(415) 962-7202
	      	(800) 962-8649 (California) [toll-free]
       	      	(800) 872-8649 (US)	    [toll-free]
		+1 519 747-9900  (Canada)
		+1 32-27-18-0311 (Europe)

FAX	      : (415) 962-0286 (US)

Email         :	sales@twg.com

Postal mail   : The Wollongong Group, Inc.
		1129 San Antonio Road
		Palo Alto, CA 94303-4310
		USA	

Product	      : PathWay Access for OS/2

Current Version: ?

Pricing	      : ?

Support	      : call

Systems	      : IBM PS/2 or 386 w/ 1MB RAM, OS/2 2.x

Services      : clients: telnet (vt 100, 220, 240, 320, 340, IBM 3278,
			 3179G, Tektronix 4105, 4010), FTP, DNS, LPR, Ping,
			 Stat 
		
Size	      : At least 2 MB [on disk], 80 KB [average, RAM]

Features      : Supports NDIS & ODI for Ethernet & Token-Ring
		Supports Netware, LAN Manager, VINES, IBM LAN Server
		Keyboard remapping.
		Supports NetBIOS, SNMP, SNAP, ARP
		Up to 12 concurrent terminal connections
		API Developrs Tool Kit available; this includes BSD 4.3
		Sockets, 32 bit DLL.
		Online help available.
		Service Scripting capabilities.

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

Z-13. PC-NFS: SunSelect

Company       :	SunSelect

Contact	      : John Keyes
		(508) 442-0546
		john.keyes@east.sun.com
		
Phone         :	(800) 24SELECT
		(508) 442-0000

FAX	      : (508) 250-5068

Email         :	
		
Postal mail   : SunSelect, 
		2 Elizabeth Drive,
		Chelmsford,
		MA 01824
		USA

Product	      : PC-NFS

Current Version: 5.0

Pricing	      : 

	Description			Order        List/Discount 
					Number	     Price/Category
	-----------------------------------------------------------

	PC-NFS 5.0			PCN-P	         $435/B	   
	PC-NFS 5.0 single license	PCN-W	         $365/B	   
	PC-NFS 5.0 Base Pack		PCN-B**	         $105/B	   
	PC-NFS 5.0 25 user license	PCN-L25**      $5,535/B    
	PC-NFS 5.0 100 user license	PCN-L100**    $12,990/ND   
	PC-NFS 5.0 500 user license	PCN-L500**    $48,650/ND   
	PC-NFS 5.0 upgrade		PCN-PF	          $80/ND   
	PC-NFS 5.0 site upgrade		PCN-PSITEF     $4,050/ND   
	PC-NFS 5.0 documentation	PCN-D	          $75/ND   
	(minimum order quantity 10)

	**L25, L100, L500 require a Base Pack

Support	      : Compuserve: "go sunselect"
		Internet Ftp sites:
			bcm.tmc.edu
			src.doc.ic.ac.uk
			ftpserver.massey.ac.nz
			ftp.york.ac.uk
		A 5 year site license is available in the UK from Chest [Z-28]

Systems	      : MS-DOS 5.x, MS-Windows 3.x
Services      : clients : NFS, telnet (vt 52, 100, 220, 320), rsh, rcp,
			  rexec, ping, nfsping, NIS, netstat
		servers : ftp, print server (optional), SNMP (optional)
		other: Windows Sockets ABI

		
Size	      : 80-90 KB (RAM usage) [can be loaded high], 
		requires 3.5 MB free disk space for new install, 6.0 MB for
		Windows install.

Features      : ISO-9660 CD-ROM, OS/2 FAT support.
		Coexists with: Windows for Workgroups, Netware 3.x, NetBIOS
		ODI drivers, NDIS drivers, packet drivers.
		Ethernet, Token-Ring, SLIP
		Support for Solaris 2.x (Solaris-on-Intel version
		forthcoming)
		Remote server-based Licensing management.
		WinSock API support.
		Minimum requirements:
			IBM PC w/ 640 KB RAM
			MSDOS 3.3
			3.5 MB for DOS install, 6.0 for MSWindows install
		Supported boards:
			3Com 3C503, 3C505, 3C523,
			Ungerman-Bass PC-NIC
			Western Digital WD8003E
			Racal Interlan NT5010
			IBM Token-Ring Network 16/4 Adapter for (AT & MCA
			buses)
		NDIS compatible supported boards:
			3C501, 3C503, 3C505, 3C507, 3C523
			WD8003E/A, WD8003E/B
			NE1000, NE2000
			Xircom Ethernet Adapters
			3Com TokenLink AT bus

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

Z-14.  PC/TCP: FTP Software, Inc.

Company       :	FTP Software, Inc.

Contact	      : Chip Sparling
		chip@ftp.com
		(508) 685-3300
		(508) 794-4477 [FAX]
		
Phone         :	(508) 685-4000	- general information
		(508) 685-3300	- sales informaiton
		(800) 282-4FTP	- sales
		(508) 685-3600	- technical support
		(800) 282-4FTP  - support

FAX	      : (508) 794-4477  - sales
		(508) 794-4484  - techincal support
		(508) 794-4488  - general

Email         :	info@ftp.com	- general information
		sales@ftp.com	- sales information
		support@ftp.com	- technical support
		
Postal mail   : ftp Software, Inc.
		2 High Street
		North Andover, MA 01845
		USA
		
Product	      : PC/TCP

Current Version: 2.2

Pricing	      : $400		- single copy
		$175/copy	- 20-49 copies
		$150/copy	- 50-99 copies
		$130/copy	- 100-499 copies
		$110/copy	- 500-999 copies
		$99/copy	- 1000 or more copies

Support	      : Support & upgrade of multiple copy sites handled through
		maintenance contract
		Techincal support bulletin board: (508) 659-6240
		Internet FTP servers:
			ftp.com		- 3rd party applications
			vax.ftp.com	- Specifications, drivers,
			 		  newsletters, etc.

Systems	      : MS-DOS 5.x, MS-Windows 3.x, OS/2 2.0

Services      : clients: NFS, telnet (vt 52,100,220), TN3270, ftp, ping, 
			 inet, email (POP2/3, PCmail, SMTP), finger, whois, 
			 nicname, setclock, host, bootp, rsh, rexec, rcp,
			 tar, news, cookie, printing (LPR, LPQ, LPRM)
		servers for DOS/Windows: ftp, tftp, SNMP, SMTP
		servers for OS/2: ftp, tftp, SNMP, LPD, finger, bootp,
			 inetd, DNS, mail, rexec, telnet
		
Size	      : "standard" (4 NFS mounts, 6 TCP connections) = 125KB
		Using EMM = 26KB

Features      : many 3rd party applications use this as transport: network
		management tools, X-windows, databases, multimedia & imaging
		packages, etc.
		OS/2 version supports NDIS for SLIP, Ethernet & Token-Ring
		DOS version supports Packet Drivers, NDIS drivers, ASI
		drivers, ODI drivers for DIX & 802.3 Ethernet, Token-Ring,
		SLIP, PPP & X.25
		Also known to work for 802.7 (broadband/CATV), AX.25 (packet
		radio), FDDI, ISDN & possibly SMDS.
		Co-exists with Banyan Vines, LanManager, Windows for
		Workgroups, and Netware. 
		RFC compliant NetBIOS interface
		PC/TCP BootPROMs available for Ethernet cards.

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

Z-15.  Reflection Network Series : Walker Richer & Quinn

Company       :	Walker Richer & Quinn, Inc.

Contact	      : -
		
Phone         :	(800) 926-3896 [US]
		(206) 324-0407 [Washington, US]
		+31 70 356 0963 [Europe]

FAX	      : (206) 322-8151
		+31 70 356 1244 [Europe]

Email         :	-
		
Postal mail   : Walker, Richer & Quinn, Inc.
		2815 Eastlake Ave. East,
		Seattle, Washington 98102
		USA
	
		Buitenhof 47,
		2513 AH Den Haag,
		The Netherlands

Product	      : 

Current Version:

Pricing	      : 

Support	      : 

Systems	      : DOS, MS-Windows 3.x & Macintosh

Services      : client: LAT, Telnet, NS/VT, FTP
		
Size	      : 

Features      : versatile command language
		Supports Ethernet,Token-Ring
		Supports NetBIOS & Berkeley Sockets.
		Option for Netware, LAN Manager, Banyan VINES
		Xwindows option coming soon.

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

Z-16.  Super-TCP:Fontier Technologies Corp.

Company	      : Frontier Technologies Corporation

Contact       : Debbie Ramirez

Phone         : (414) 241-4555 ext. 210

FAX           : (414) 241-7084

Email         : tcp@frontiertech.com

Postal mail   : Frontier Technologies Corporation
		10201 N. Port Washington Rd.
                Mequon, 
		WI  53092  
		USA

Product       : Super-TCP/NFS for Windows

Current Version: Version 3.00

Pricing       : List Price: $495.00 with NFS, 
		$395.00 without NFS. 
		NetBIOS option - $295
		LPD option - $395
		PPP option - $95
		ONC option - $695
		X.25 option - $2495  (hardware inc.)
		Developers toolkit - $695
		Site licenses available. (call)

Support       :  9am-6pm (EST), phone, email (Internet, Compuserve), bbs

Systems       : 286 & above w/ 2 MB RAM MS-Windows 3.x, MSDOS 3.3  above

Services      : Client: telnet (VT220, VT320, tn3270), nfs, ftp, tftp,
			lpr, talk, nntp, pop 2/3, smtp (MIME extensions), bootp
			rcp, rsh, rexec, ping
        	Server: nfs, ftp, tftp, talk, smtp, snmp, modem, optional
			lpd

Size          : Takes only 3K DOS RAM. 5MB free hard disk space needed.

Features      : NDIS, ODI, ASI, PDS, SLIP, PPP (optional),  X.25
		(optional);		
		100% DLL in Windows or TSR for DOS;
		Sun ONC RPC/XDR API; NetBIOS API; Windows Sockets API v1.1;
		Coexists with NetWare, LAN Manager, Banyan Vines, DCA 10Net,
		DECNET.
		VxD Virutal Driver
		Super-TCP has the first Windows Email with support for MIME
		binary file attachments.

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

Z-17. 	TCP/IP for DOS: IBM

Company       :	IBM

Contact	      : Jeff Wheeler [Atlanta, US]
		
Phone         :	(800) IBM-CALL
		(800) IBM-3346

FAX	      : (404) 238-1054

Email         :	-
		
Postal mail   : IBM
		Dept. E15,
		P.O. Box 12195,
		Research Triangle Park,
		NC 27709
		USA

Product	      : TCP/IP for DOS (Product # 02G7087)

Current Version: 2.1

Pricing	      : ??

Support	      : ??

Systems	      : MS-DOS 5.x, MS-Windows 3.x

Services      : clients: telnet (vt100,vt220), TN3270, TFTP, FTP,  
			NFS (optional),	REXEC, RSH, LPR, SMTP, POP 2/3
		servers: FTPD, LPD

Size	      : ??

Features      : supports Ethernet, Token-Ring, packet drivers (shim), NDIS,
		SLIP
		Programmers Toolkit available (Product # 02G7088)
		NFS Kit available (Product # 02G7089)

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

Z-19.  TCPOpen : Lanera Corporation

Company       :	Lanera Corporatopm

Contact	      : 
		
Phone         :	(408) 956-8344

FAX	      : (408) 956-9343

Email         :	lanera@netcom.com
		
Postal mail   : Lanera Corp.
		516 Valley Way,
		Milpitas,
		CA 95035
		USA

Product	      : TCPOpen

Current Version: ??

Pricing	      :  

Single-User License
===================

-----------------------------------------------------------------------------
Product                 Code            Software/Manuals        Manuals Only
-----------------------------------------------------------------------------
TCPOpen/Kernel          TKER            $ 95.00                 $30.00
TCPOpen/Standard        TOPN            $145.00                 $40.00
TCPOpen/Plus            TPLU            $195.00                 $50.00
TCPOpen/SDK             TSDK            $295.00(see note)       $50.00
-----------------------------------------------------------------------------

TCPOpen/Standard: TCPOpen/Kernel + TCP/IP applications + Softerm
TCPOpen/Plus:     TCPOpen/Standard with NFS client module
TCPOpen/SDK:      TCPOpen/Standard with Software Development Kit

Quantity Discount
-----------------
15% for quantity of 2 to 5
20% for quantity of 5 to 10
25% for quantity of 20 or more (site license is recommended).

University Discount
-------------------
25% discount

Site License
============
A site license allows for a specified number of copies to be made of the
software and corresponding manual for use on any system owned by the
purchaser.  Only one copy of the software and the corresponding manual is
provided.  Additional copies of the manual can be separately ordered at the
price shown above.

Site license requires a purchase of an updates and support policy.

----------------------------------------------------------------------------
   Quantity                         Per-User Pricing
                         Kernel         Standard        Plus
                         (TKER)          (TOPN)         (TPLU)
----------------------------------------------------------------------------
   10 - 49              $50.00          $70.00          $90.00
   50 - 99              $40.00          $60.00          $80.00
  100 - 499             $30.00          $50.00          $70.00
  500 - 999             $20.00          $40.00          $60.00
 1000+                  $20.00          $30.00          $50.00
----------------------------------------------------------------------------
Site License Expansion
----------------------
An existing site license can be expanded at a later time.  The per-copy
cost of the additional license is based on the final total number of copies
at the time of expansion.


Support	      : 

Free 90-day telephone support and unlimited fax/Internet E-mail support
for all single-user licenses.  One-year update fee and unlimited telephone
support for single-user license is $100.00.

One year of unlimited telephone support and updates is at the cost of 20% of
the Site License purchase price.

Due to high cost of oversea support, International (single-user license)
users will receive direct support from local dealers/resellers unless the
purchase is made directly with Lanera or a support contract is purchased.
However, Internet E-mail support is always available to all users.


Systems	      : DOS, MS-Windows 3.x

Services      : 
  NFS client Module: NFS v2 implementation, up to 15 drives.
  TCP/IP: ftp client/server, TFTP client/server, telnet, rlogin, print
	  utilities, r-utilities (rsh, rexec, etc), finger, whois, remote
	  Tar, bootp
  Softerm: vt (52, 100-series, 220/240, 320/340), IBM 3101 < 10/20,
	  IBM-ANSI, TN-3270, ANSI-terminal, kermit, Xmodem, Ymodem
		
Size	      : kernel : 72 KB (RAM)

Features      : NDIS, Packet drivers, ODI drivers. SLIP
		co-existence with Netware, LAN Manager, Workgroups,
		Lantastic, Vines, InvisibleLAN
		TCPOpen/SDK with Windows Sockets API 1.1 DLL available.

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

Z-20.  TTCP: Turbosoft Pte Ltd.

Company       :	Turbosoft Pte Ltd

Contact	      : -
		
Phone         :	+61 2 552 1266 (Australia)

FAX	      : -

Email         :	info@abccomp.oz.au
		
Postal mail   : Turbosoft
		248 Johnston St.,
		Annandale,
		NSW  2038
		Australia

Product	      : TTCP

Current Version: 1.2r2

Pricing	      : 

Support	      : 

Systems	      : 

Services      : 
		
Size	      : 

Features      : supports Ethernet, Token-Ring, packet drivers, NDIS (shim), 
		ODI (shim)

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

Z-21.  WATTCP : Erick Engelke

Company       :	-

Contact	      : Erick Engelke
		
Phone         :	-

FAX	      : -

Email         :	N/A 
		
Postal mail   : N/A

Product	      : WATTCP programming libraries
		WATTCP applications

Current Version: July 1993

Pricing	      : free. FTP from:
		  dorm.rutgers.edu: /pub/msdos/wattcp/{wattcp.zip,apps.zip} 

		The WATTCP Programming Manual is priced as following:
		Visa/MC/AE/Cheque/Check/Money Order	US$40
		  or Purchase Order			US$60
		+ shipping/handling (US or Canada)	US$5
		  or Airmail elsewhere			US$10
		
		Credit card sales can be made entirely by email.

Support	      : none.

Systems	      : MS-DOS w/ Packet Drivers

Services      : clients: telnet, TN3270, ftp, ping, bootp, finger, smtp
		servers: telnetd, ftpd, smtpd, 
		
Size	      : 30-55 KB 

Features      : Separate programmers referrence is available. It was written
		by Erick Engelke (designer of WATTCP) and has many of the
		popular WATTCP applications. The manual provides a tutorial
		to programming under WATTCP with various related topics and
		a complete referrence section. To order the manual please
		mail: 
	       		WATTCP Programmers Manual
			c/o Supro Network Software, Inc.     
			P.O. Box 18, Warsaw, Ontario
			Canada 	KOL-3A0
		
			(705) 652-1572

		or email:   
			wattcp@snsi.com

		Pricing is as above.

		NOTE: Supro cannot answer any questions about this software
		and the author does not provide the documentation. Please do
		not use the above email address for support questions.

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

Z-22.  WinQVT/Net: QPC Software

Company       :	QPC Software

Contact	      : - 
		
Phone         :	

FAX	      : (716) 377-8305

Email         :	djp@troi.cc.rochester.edu
		
Postal mail   : 

Product	      : WinQVT/Net

Current Version: 3.93

Pricing	      : free

Support	      : none

Systems	      : MS-Windows 3.1

Services      : VT (52, 100, 220), POP mail client, newsreader, FTP, FTPD
		
Size	      : 

Features      : uses packet drivers only

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

Z-X.  Fusion : Pacific Softworks

Company	      :  Pacific Softworks

Contact       :  Sales 
 		
Phone         :  (800)541-9508	
 
FAX	      :  (805)484-3929
 
Email         :  sales@nrc.com 
		 cust-support@nrc.com	
 		
Postal mail   :	Pacific Softworks, Inc.
		4000 Via Pescador, 
	   	Camarillo, CA 93012-5049
 
Product       : FUSION for DOS 
 
Current Version: 3.4
 
Pricing      : Single prices
              TCP/IP                 $349.00
              TCP/IP w/IPX           $399.00
              IPX only               $149.00
              PDS option w/WINSOCK   $200.00 
              PC-Xview & TN3270 also available

           Multiple pricing (right to copy), 5 copies to 1,000+
              PC/NFS         ranging from $250 - $90 each
              PDS/WINSOCK    ranging from $495 - $195 each
              PC-Xview & TN3270 also available
 
Support       : Tech. phone line  (805)484-1609, 90 days free tech. support
           	Univ. discount 33%
 
Systems       : All AT-compatible PCs including 286, 386 and 486 systems
           	with minimum 4 MB of free hard disk space.
           	DOS 3.x-6.0, MS Windows 3.1
 
Services      : clients: FTP, Telnet (vt 220), rcp, rlogin, rsh, rshd,
			ruptime, rwho, NFS Client 
		servers: FTPD
 		
Size	      : 136 KB Conventional memory, can be loaded into Upper memory
              	for most system configuration
           	4 MB hard disk space
 
Features      : NDIS support on the following Ethernet Boards
                3COM: 3C 501, 503, 505, 507, 509 and 523
              	Accton: EtherCoax-   8W EN1808, 8WB EN1818, NE2 EN1606
                                     16N EN1603, HP EN1620
                        EtherPocket- CX/10T
                        EtherPair-   8W EN1807, 8WB EN1817, NE2 EN1605
                                     16N EN1602, HP EN1619
                Cabletron: E2020-X
       	        Digital: EtherWORKS LC DE100, Turbo DE200, MC DE210
                       DE100, DE200 with ROM chip
              	D-Link: DE-100, DE-200, DE-300
                Novell: NE 1000, NE 2000
              	Spider: Ethernet Card
              	Standard Micro: 8003, 8013
              	Western Digital: WD 8003E, 8003W/A, 8003E/A, 8013EBT,
                               WD 8003WT, WD8003ET/A, WD8013W
              	Xircom: Pocket Adapter PE108
	        Direct Board Drivers for Western Digital WD8003
           	Token Ring Boards supported: 3COM 3c603 Tokenlink
           	IPX co-existence
           	X Window terminal for DOS and MS Windows with PC-Xview            
           	DOS PDS (Programmer's Development System) with Microsoft
           	   and Borland compilers
           	Support of WINSOCK API with WINSOCK.DLL  
           	Highly portable source code available

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

Z-25.  ICE.TCP	: James River Group

Company       :	James River Group, Inc.

Contact	      : -
		
Phone         :	(619) 339-2521

FAX	      : 

Email         :	jriver@jriver.com
		
Postal mail   : 125 N. First St.
		Minneapolis,
		MN 55401

Product	      : 

Current Version:

Pricing	      : 

Support	      : 

Systems	      : 

Services      : Telnet (Wyse60, ANSI), LPR, LPD
		
Size	      : 

Features      : works with Novell.

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

Z-26.  Piper/IP		IPswitch, Inc.

Company       :	IPswitch, Inc.

Contact	      : Bob MacFadgen
		
Phone         :	(617) 942-0621

FAX	      : (617) 246-2975

Email         :	bob@ipswitch.com
		ub@ipswitch.com
		
Postal mail   : 333 North Ave.
		Wakefield
		MA 01880      

Product	      : Piper/IP for DOS & Windows, 
		Vantage/IP for OS/2
		Catipult Netware-TCP/IP gateway

Current Version: 1.0, 1.0, & 1.3 (respectively)

Pricing	      : 

Piper/IP pricing
Part #		Description				Price
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PIP-100		1 user TCP/IP DOS & Windows Pkg		$375
		 & Piper/IP kernel
PIP-105		5 user   "				$1195
PIP-110		10 user "				$1995

PIP-200		1 user kernel only			$175
PIP-205		5 user kernel only			$745
PIP-210		10 user kernel only			$1225

PIP-310		Netbios option				$85
PIP-320		NFS client and server for kernel opt.	$99

Vantage/IP pricing
Part #		Description				Price
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
VAN-100		1 user kernel & apps for OS/2		$395
VAN-105		5 user   "				$1475
VAN-110		10 user  "				$2565

VAN-310		Netbios option				$95

Catipult line packages
Part #		Description				Price
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CAT-100		30 user Netware-TCP/IP gateway		$2975
CAT-145		45 user   "				$4275
CAT-160		60 user   "				$5375

CAT-315		15 user upgrade for gateway 		$1495
CAT-330		30 user    "				$2675

Site licensing
++++++++++++++
Users                 20-49   50-99   100-249   250-499   500-999   1,000+

PIP-Sxxx  (per user)  $170    $150    $125      $105      $95       $89
PIP-SKxxx (per user)  $87     $80     $69       $59       $54       $49
PIP-SBxxx (per user)  $43     $39     $34       $29       $26       $23
PIP-SFxxx (per user)  $49     $45     $39       $33       $30       $27
VAN-Sxxx  (per user)  $195    $175    $145      $120      $108      $99
VAN-SBxxx (per user)  $50     $45     $39       $33       $30       $26

[xxx = kernel + apps; Kxxx = kernel only; Bxxx = Netbios option; F = NFS option]

Pricing for additional copies for a site license is based on the aggregate
number of copies in the site license. The 12% annual support fee is prorated
so that support for all copies ends at the same time.

Developers Kit
--------------
IPS-200		Ipswitch developers kit w/ berkeley sockets for      $475
		Catipult, Vantage & Piper/IP. MS-C/C++ or Borland

Support	      : call.

Systems	      : Piper/IP: 80x86, 1.5 MB, DOS 3.1
		Vantage/IP: any OS/2 capable system, 4MB (OS/2 1.x) 8MB(OS/2
		2.x) & OS/2 1.x or 2.x.

Services      : Piper/IP: rlogin, telnet (vt102), tn3270, lpq,lpr,lprm,
		rexec, rsh, rcp, ftp, tftp, pipernb &upipernb (netbios),
		[chmod, ls, nfsmount, pnfs/upnfs, xomap] (NFS), ntpr,
		ntprint, mt, rtpcp, tar, finger, whois, red (news), catmail,
		pcmailer, fingerd, ftpd, nfsd, rexecd, routed, rshd, snmpd,
		telnetd, tftpd, arp, ifconig, setclock, route, netstat,
		nslookup, pink, tracetoute, ripquery, snmpd

		Vantage/IP: all the above + talk, otalk, mail, reposito,
		popper

		Note: NFS client and server are part of Vantage/IP and a
		separate option for Piper/IP.
		
Size	      : 6K in DOS (rest loadable high)

Features      : works with Netware, LAN Manager, LAN Server, VINES.
		one of the most complete list of applications I've seen.
		

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


-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 1993 09:15:12 -0800
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: X.25 through tcp-ip

In article <BOB.93Nov2114443@volitans.morningstar.com> Support@MorningStar.Com (MST Tech Support Group) writes:
>
>
>QLLC may have been a bad idea, or at least a bad implementation of a
>useful (not necessarily good) idea.  Yes, multiple layers of
>encapsulation may be ugly and it sometimes makes my head swim, but
>it's certainly not something to discard out of hand.  For just about
>anything you can think of doing with a network, someone will find
>themselves backed into a situation (usually political :-) where
>they'll welcome even the ugliest hacks.

   Sad but true.  I've seen SNA shoehorned onto ethernet, tcp/ip on
   SNA, bisync 3270 on X.25, X.25 on X.25, and my favorite practical
   joke, ANYTHING on ISDN.  >:-)


   The things desperate network types will do to connect whatever you
   have thru whatever you got.



-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Tue, 02 Nov 1993 11:28:43 -0800
From:      wcheung@sdcc13.ucsd.edu (Wilson Cheung)
To:        comp.protocols.tcp-ip
Subject:   Re: Can u explain how to set up POP-3 please or reference.

In article <Oct.31.10.55.55.1993.4681@gandalf.rutgers.edu>,
mayshah@gandalf.rutgers.edu (Mayank Shah) wrote:

> dan@c-mols.siu.edu (Dan Ellison) writes:
>
> Could someone tell me where I can get popper?

Popper 1.831 beta is available via anonymous FTP from:

ftp.cc.berkeley.edu:/pub/pop/popper/popper-1.831beta.tar.Z

-- 
Wilson Cheung
wcheung@sdcc13.ucsd.edu

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 1993 11:56:24 -0800
From:      schmidt@liege.ics.uci.edu (Douglas C. Schmidt)
To:        comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Getting protocol options via TLI

Hi,

	Does anyone happen to know the appropriate incantations to get
the current value of protocol options via the TLI API?  Basically, I'd
like something that behaved along the lines of getsockopt() from the
sockets API.  After reading the man page, it isn't clear that the
T_NEGOTIATE, T_CHECK, or T_DEFAULT flags to t_optmgmt() do exactly
what getsockopt() does.

	Thanks for any hints!
	
		Doug
-- 
Douglas C. Schmidt
Department of Information and Computer Science
University of California, Irvine
Irvine, CA 92717. Work #: (714) 856-4105; FAX #: (714) 856-4056

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Nov 1993 22:42:08 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: definition of 'internet'

In article <18822@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
   >>I have always called the Internet: "A network of interconnected networks
   >>using TCP/IP"
   >>
   >    Or uucp, or kermit, or......

   Umm, at least the way I've heard it used, *the* Internet refers
   only to those machines connected via TCP/IP.

I use the term "big-I Internet" to refer to the aggregation of those
networks containing systems on which users can say "ping nic.ddn.mil"
and get back something meaningful - that is, those networks with IP
connectivity to the rest of the things that claim to be connected to
the big-I Internet.

   I would be nice if somebody could come up with a name for the set
   of all machines that can exchange email, which is what I assume you
   are referring to (there already *is* a name for the set of all
   machines that can exchange netnews - "USENET").

I use the term "little-i internet" to refer to any aggregation of
networks containing systems that can meaningfully exchange information
with systems on other networks.  These services may be limited to
e-mail, and users on those networks may not be able to exchange e-mail
with users on networks connected to the big-I Internet.  The important
thing is that they're doing something outside the boundaries of their
own LAN.

Others have used other terms for similar things.  A long-ago paper
from Purdue used the term "catenet", coined from "concatenated
networks".  John Quarterman &c call it the "Matrix".
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221-2856      +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Nov 1993 23:44:20 GMT
From:      kap@controls.ccd.harris.com (Kurt Post)
To:        comp.protocols.tcp-ip
Subject:   Setting up source routing for a socket


Does anyone out there know if it is possible to set up source routing for a TCP or UDP
socket?

I think it could be done for UDP if you opened a RAWIP socket and bult the IP header
yourself.  Unfortunately this won't work for TCP sockets.

Here is an outline of how I'm trying to do it now?

char    ipopt_a[40];
int      optlen;
.........
ipopt_a[0] = IPOPT_LSRR;            /* IP options code for loose source route */
ipopt_a[1] = 8;                     /* length of this option */
ipopt_a[2] = 4;                     /* Initial value of POINTER field */
ipopt_a[3] = 0;                     /* filler */
*((u_long *)(ipopt_a + 4)) = inet_addr(argv[2]);   /* set first/only mandatory hop */
ipopt_a[8] = 0;                     /* IP options code for end of options */
optlen = 9;
if(setsockopt(sockfd,IPPROTO_IP,IP_OPTIONS,ipopt_a,optlen) < 0)
{
    perror("Error from setsockopt(IP_OPTIONS) error = ");
}
....

When you send on this socket the UDP packet goes out of the default interface instead
of the interface specified in argv[2].  There are no errors returned.

If you follow up the setsockopt() with a getsockopt() the results depend on the OS
the program is run on.  On an IBM RS/6000 running AIX 3.2 the getsockopt() call
returns the options set with setsockopt().  On a Sun running Solaris 2.2 the 
getsockopt() call returns 0 in optlen.

Am I doing this the wrong way?  Is it even possible?

Thanks

Kurt

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 1993 13:14:01 -0800
From:      heffron@falstaff.css.beckman.com (Matt Heffron)
To:        comp.protocols.tcp-ip
Subject:   Re: Question about subnetting.

In <svanarts.59.2CD6718E@lmsc.lockheed.com> svanarts@lmsc.lockheed.com (Scott VanArtsdalen) writes:

>I have a small problem that I hope to have solved.  I was hoping a 
>subnet.expert could give me some advice on what I propose to do.  
 
>I was given a block of IP addresses by our company's net.nazi for our new 
>ethernet lan/wan.  We have about 10 small sites around the campus here to 
>link up to our host site.  The block of addresses (changed here to protect 
>the innocent) is 129.197.222.0-254.  
 
>I know that in order to effectively use the routers I will need to subnet.  
>The subnet mask I came up with is 255.255.255.240 using the first 4 bits of 
>the last octet as networking bits.  So this should give me 16 networks with 
>16 hosts on each, right?

Actually, I think its 16 networks of 14 hosts on each.  The host numbers
0 and 15 on each subnet are reserved

>Also, since our host site will have more than 16 hosts, I'll have to use 
>about 3 of these for the host site alone.  Will this present a problem for 
>the routers?  Say 129.197.222.1-15, .16-32, .33-47 are all local networks.  
>Can each of these subnets be on the same segment?

Yes, but you'll probably need to have the router exist as an address on
each of the subnets (using secondary addresses), to do the subnet-to-subnet
relaying.

A suggestion:  establish a numbering convention for all the router IP
numbers.  Ours here is, to use the highest legal host number in the
subnet, that way you always know what the default route address should
be from any host in the network, given it's IP number and subnetmask.
(E.g. for my host with IP 134.217.81.7, and mask 255.255.255.0, my
default route is 134.217.81.254.  On another segment, 134.217.201.10 with
subnetmask 255.255.252.0, the default route is 134.217.203.254)

>Lastly, I'm also assuming that the netmask has to be the same across the 
>entire network.  Correct?

Nope, if the routers can work with differing masks on different interfaces,
and you are very careful to setup the address space to make sure routing by
subnet number works correctly on each of the segments.

>I'm a little new to this but I think that I may have finally grasped the 
>concept of subnetting.  Any advice, confirmations, or heavy petting would be 
>appreciated.
 
>Thanks for your time.

I'm not a GURU, but I'm not a rookie, either.

>--------------------------------------------------------------------------    
>    \    /\                                           Aeronca 7AC Champ
>     \  /__\                                          =(*)= N3115E =(*)=
>Scott \/an  \rtsdalen                                "The Boonie Bouncer"
>--------------------------------------------------------------------------
>        Opinions expressed here do not necessarily reflect those of
>           Lockheed Missiles & Space Co., Inc. or its management.   =*
>--------------------------------------------------------------------------
-- 
Matt Heffron                      heffron@falstaff.css.beckman.com
Beckman Instruments, Inc.         voice: (714) 961-3128
2500 N. Harbor Blvd. MS X-10, Fullerton, CA 92634-3100
I don't speak for Beckman Instruments unless they say so.

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 1993 08:23:07 -0500
From:      tmaynard@news.delphi.com (TMAYNARD@DELPHI.COM)
To:        comp.protocols.tcp-ip
Subject:   Re: Newbie needs a dummy.net IP address

spp@zabriskie.eecs.berkeley.edu (Steve Pope) writes:

>gary@sci34hub.sci.com (Gary Heston) writes:
 
>> TMAYNARD@delphi.com writes:
>> 
>>> I'd like to set up an internal network (never seen outside the 
>>> corporation) and use a dummy, Class B address.  Then I can reserve 
>>> my precious NIC-legal
>>> Class C addresses for hosts that actually connect to the Internet.
>>
>> Sorry, it's not allowed. There's no way under current network software
>> to make this work, unless you keep it physically isolated as well--as
>> in passing email to and from it via a uucp link. Otherwise, 
>> you'll never get it to work reliably.
 
>I'm not an expert, but I disagree with this pessimistic 
>view.  For awhile, at my site, we did exactly what TMAYNARD
>suggested.   A set of "internal" addresses was given to
>ALL hosts, and a subset of these also had an assigned Internet
>address from our class-C group.   So long as the mailhosts
>are all Internet hosts, mail works fine.  Using uucp would be
>silly.
 
>You must of course never route packets from the internal-only
>host address to/from the outside world.  And 
>the IP addresses you use internally are unavailable as
>external destinations -- but that hardly will cause problems,
>just use something unassigned.
 
>I believe the only thing you will find impossible to do
>is nameservice.  
 
>Steve

Time for me to jump back in here.  I appreciate the commentary, but I'm
left confused.  Is there some difference between having two, legal NIC
addresses and one legal address and one bogus address?

Won't I have all these same difficulties _anytime_ I have to support
two networks at my site?  (Legal or not?)

I believe I have located an assigned IP address that will never appear
on the Internet (128.66.0.0, Assigned to IANA as NET-TEST-B).  If this
qualifies as my "reserved" IP address (and thus never does appear on
the net), what problems could I have?

Remember, I'm a complete novice...our Internet connection is probably a
year away, but the foundation needs to be laid now and I don't want
to come back and re-do it all.  Give it to me straight!  I can take it.

73,
Tom Maynard		TMaynard@Delphi.Com
Sr Systems Programmer	USNCCN3R@IBMMAIL.COM
Nalco Chemical Company
Naperville IL


-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 1993 02:12:44 GMT
From:      csehm@perot.mtsu.edu (Mr. Erik Moe)
To:        comp.protocols.tcp-ip
Subject:   Tcp Push?

How does one flush TCP data and send it to the receiver?

Erik Moe

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 1993 10:47:44 -0500
From:      martinw@epenviron.eapi.com (Martin Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet or Token-ring ?

kater@wsuhub.uc.twsu.edu writes:

i had to make the same descision earlier this year.  i went with ethernet.
we have pc's and and as/400 on tr and a sun/pc e-net network.  i went with
e-net because of price ( around 1/2 by the time you have cable, software
and card), flexability in topology and in types of machines supported.
>Hi,
 
>We have several small networks at our workplace. Some of them are Ethernets
>running TCP/IP and some are Token-rings. Now we would like to integrate these
>smaller nets into one big network. 
 
>Which protocol should we go for--Ethernet or token-ring.
>What are their pros and cons? What should be the basis of our decision ?
>Are there any papers published on their comparitive study.
 
>I hope this is the proper newsgroup for such a question.
 
>Thanks for your time.
>--------------------------------------------------
>Email:kater@wsuhub.uc.twsu.edu
 

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Nov 1993 02:33:57 GMT
From:      neesonc@qdpii.ind.dpi.qld.gov.au (Colin Neeson)
To:        comp.protocols.tcp-ip
Subject:   Protocol Analyser

I currently use Intel's NetSight Analyst as my protocol analyser on the
network I am currently using.  Unfortunately I use Win QVT/Net for mail, 
telnet, lpr, etc.  If I open up a DOS shell in Windows and try to run NSA, 
either the packet driver is unable to be set to promiscuous (sp?) mode,  
or Windows barfs altogether.  

I can understand why this happens (basically), but this is not the point
of this post. 8-).

Does anyone out there know of a WINDOWS protocol analyser that would be 
comparable to NSA or any of the DNPAP (excellent) products?  WIN/QVT requires
a shim for the packet driver so this may cause problems for other packages
to run.....

Either e-mail or post for other people's information?

(ps: I'm not bagging win/QVT - it's a grouse bit of gear! Just in case somone
got the wrong idea about para 1 8-)


----------------------
                                           | "That's the sort of blinkered 
Colin Neeson                               |  philistine, pig-ignorance I've
DPI (QLD) Water Resources                  |  come to expect from you
North Region                               |  non-creative garbage...."
Australia                                  |
                                           | (and if it's not quoted word for
email: neesonc@qdpii.ind.dpi.qld.gov.au    |  word _don't_ tell me about it!)

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 1993 03:02:28 GMT
From:      gah@cco.caltech.edu (Geln A. Herrmannsfeldt)
To:        comp.protocols.tcp-ip
Subject:   Re: ping's maximum packet size

Our machines will ping up to around 2000.  They do fragment!

It may not get to 2048, I don't know.

-- glen

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 93 08:52:24 CDT
From:      rsl11@kuhub.cc.ukans.edu
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Running WinQVTnet with Novell...

Hello there,

	I am right now running Win QVT 3.93 packet driver version and I also 
would like to connect to a Novell Fileserver. For Novell one needs to load 
the 2 programs 

		ipx.com and net5.com

(I guess for net5.com you can substitute netx.com where x specifies
version????).

	My PC is connected to an Ethernet backbone and so does the Novell
Fileserver.

	   My questions are:

1. Do I need any other programs that make QVT and Novell work together besides
ipx.com and net5.com? How about the program ipxpkt.com? Would that be a better
substitute for ipx.com?

2. In other words, what do i need to be able to run QVT and Novell?

3. Are there any conflicts when running these 2 programs?

	I would appreciate any relevant response.

Thanks, Chris


Please E-mail: rsl11@kuhub.cc.ukans.edu
	

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Nov 1993 04:19:09 GMT
From:      axb@defender.dcrl.nd.edu (Arindam Banerji)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP (or any dynamic IP address assignment) *Through* a Router

Why not keep the IP addresses on the mobile devices fixed and use a Mobile -IP 
implementation (based on something like Loose Source Routing) ? This 
approach does have its problems(especially, since many IP implementations 
ignore the loose source option in the IP header) but it is certainly an 
effective solution. IBM demonstrated the use of this technology at this 
year's Workshop on Mobile Computing.  

axb 
Arindam Banerji 
axb@cse.nd.edu 

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 1993 04:33:48 GMT
From:      cslip@ee.lbl.gov (Craig Leres)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   LBL CSLIP 2.7 is now released

I just placed cslip-2.7.tar.Z in the anonymous ftp directory of
ftp.ee.lbl.gov. When retrieving this compressed tarchive, don't forget
to set binary mode. This package should work without too much trouble
on BSD derived systems and is known to work with SunOS 4. But
unfortunately, Solaris 2 is NOT supported.

There are two important changes in this release:

    - Rewrote the input code to chain (up to 2) clusters so we can
    handle larger MTUs. With a cluster size of 1024 bytes (standard on
    most systems), the old code could only accept input packets of 772
    or less bytes. This prevented it from interoperating with some
    systems; for example, the Annex release 6.2 was hardwired with a
    MTU of 1006. The new code can handle 1796 bytes and accommodates
    other systems using cavernous MTUs. (See the comments before the
    definition of SLMTU in if_sl.c for an explanation of why a larger
    MTU hurts interactive response without improving performance.)

    - Fixed a bug found by Ian Donaldson (iand@labtam.labtam.oz.au);
    since "fast" queue packets are always sent first, packet order is
    not guaranteed and so you can't compress the connection id. There
    is also a new kernel config option, SL_NOFASTQ, that allows you to
    disable the "fast" queue and enable connection id compression.

One other change of note is the addition of SunOS 4 loadable driver
support, thanks to Dean R. E. Long (dlong@cse.ucsc.edu). See the file
CHANGES for a complete list of changes between CSLIP 2.6 and CSLIP 2.7.

		Craig

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 93 09:46:45
From:      amoss@picton.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip
Subject:   How to bind to a broadcast address on SunOS 4.1.3?

Hello,

I'm trying to change xntpd (with it's author's permission) to bind to various
broadcast addresses but my test programme keeps failing.  It will succeed only
when binding to INADDR_ANY (0.0.0.0),  even though xntpd itself somehow manages
to bind to the "right" address (net.0).

Can someone shed some light on this please?

Thanks in advance,

--Amos

Here is the test programme (which works better on SGI's, btw)
----------------------------------------------------------------------
#include <stdio.h>

#include <sys/types.h>
#include <sys/socket.h>

#include <netinet/in.h>

main ()
{
	int s0, fromlen;
	struct sockaddr_in addr;
	char buf[BUFSIZ];

	if ((s0 = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
		perror ("socket");
		exit (1);
	}

	addr.sin_family = AF_INET;
	addr.sin_port = htons(123);
	addr.sin_addr.s_addr = 0xffffffff;

	printf ("trying [%s]\n", inet_ntoa(addr.sin_addr));

	if (bind(s0, (struct sockaddr *)&addr, sizeof (addr)) < 0) {
		perror ("bind");
		exit (1);
	}

	for (;;) {
		fromlen = sizeof (addr);
		if (recvfrom (s0, buf, sizeof (buf), 0,
		    (struct sockaddr *)&addr, &fromlen) < 0) {
			perror ("recvfrom");
			continue;
		}

		printf ("[%s]\n", inet_ntoa(addr.sin_addr));
	}
}
----------------------------------------------------------------------
--
--Amos Shapira (Jumper Extraordinaire) | "Of course Australia was marked for
C.S. System Group, Hebrew University,  |  glory, for its people had been chosen
Jerusalem 91904, ISRAEL                |  by the finest judges in England."
amoss@cs.huji.ac.il                    |                         -- Anonymous

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Nov 1993 08:28:34 GMT
From:      gmtwong@ntuvax.ntu.ac.sg
To:        comp.protocols.tcp-ip
Subject:   Help on "Wireless LAN"

I don't whether this is the right group or not. I'm currently exploring
in the areas of "wireless LAN" in GHz region (microwaves). I find it hard
to get articles or papers. I'm looking for reports on the advancements in
this areas and the problems like mutipath causing Intersymbol Interference
(ISI) and solving the problems thru atenna design or spread spectrum analysis.
If you come across any such good articles, please email to me.

Thanks

(I have some articles but they are in late 91s)

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Nov 1993 09:11:53 GMT
From:      johan@spird.jos.ec.lu.se  (Johan Svensson)
To:        comp.protocols.tcp-ip,comp.protocols.nfs,comp.sys.novell
Subject:   Re: IPX, TCP-IP, NFS, X-Windows, MS Windows concurrently

In article <2apltp$b8o@genesis.ait.psu.edu> fiend@fubar.bk.psu.edu (Ron Woodley) writes:

>> I am looking for some suggestions, recommendations, assistance, etc. in 
>> selecting a software package which will be able to do all of the following
>> simultaneously under MS-DOS 5.0+ and MS Windows 3.1:
>>         Connect to a Novell server via IPX
>>         Connect to multiple Unix servers via TCP/IP
>>         Mount NFS volumes
>>         Run X-Windows based applications from a Unix server
..
..
>> Ron Woodley
>> 

We are running FTP Sotfware's PCTCP, that supplies the TCP/IP-
stack and Interdrive for NFS-mounting and lpr'ing. We run PCTCP
on ODI and are connecting fine to three NetWare 3.11-servers
simultaneously. As for the X-Windows connectivity, we've tested
four different packages: Visionware's XVision, Hummingbird's 
HCL Exceed, NCD's PC-XView and PC-XWare. The latter is a port
from NCD's X-terminal software and is (very) superior (indeed)
in comparison with the rest of the bunch. PC-XWare is approx.
twice as fast and it has got a VERY nice interface - you can
choose between MS Windows and NCD's "X-Windows"-style Windows-
Manager (very neat).
   By an X-Package as above, you can connect to several UNIX-
hosts and now your spec. is fulfilled! The prices for the X-
Packages are more or less the same for all brands and if you
for some reason (God forbid!) decide not to use PC-XWare, I
would clearly recommend HCL Exceed/W - it's not bad at all
either.

With ODI, PCTCP and PC-XWare running on a 486-based PC, you'll
get a very competent setup - with NCD as Window-Manager I have
difficulties to say I'm not running on a speedy X-terminal
if it wasn't for MS Word and Excel and the connectevity to
Novell. This combination would be the best X-mas gift to
anyone searching for R*E*A*L connectivity!

/Regards!

______________________________________________________________
Johan Svensson           Email:   johan@spird.jos.ec.lu.se
JoS-Ware Comp Tech       Address: Box 739, 220 07 LUND, SWEDEN
Tel: +46-46-104505       Fax:     +46-46-188445


-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Nov 1993 10:58:26 GMT
From:      albertk@cs.kun.nl (Albert Koppes)
To:        comp.protocols.tcp-ip
Subject:   Extensive use of PUSH on large network, feasible ?

In an application we are planning the use of
the TCP PUSH mechanism to implement a kind
of message boundary keeping, and to
avoid applications to implement this.

Therefore, every SEND will use the PUSH
mechanism. 
I have the impression that the use of PUSH will
put some burden on the TCP-stack, as more interupts
are generated.

Is somebody familiar with this
PUSH-ing of data if it is extensively used ? And
in general is it really a good method of keeping
message boundaries ?

Thanks for any suggestions 





-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 93 19:51:20 -0500
From:      glazer@ohstpy.mps.ohio-state.edu (JON GLAZER)
To:        comp.protocols.tcp-ip
Subject:   Looking for sendmail/SMTP formats.


I am looking for some good documentation on all the sendmail/smtp 
address headers.  I am talking about the headers found in a given email
message that can be utilized on most systems.  Now I was once told to
get RFC221 and I looked all over and all the major sites that cary 
thousands of RFCs that I've found don't have this one.

Is there a newer/better document for this?  Where can I  get it?

Thanks!!
Jon



-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Nov 1993 12:42:45 GMT
From:      jshaw@actrix.gen.nz (Jim Shaw)
To:        comp.protocols.tcp-ip
Subject:   Re: X.25 through tcp-ip

Please excuse the commercial nature of the response, but:

My company has software that lets you route X.25 between Suns using TCP/IP
over any intermediate network. It also enables the Sun(s) to switch X.25 
calls between local X.25 links. Number of links is hardware limited only
(eg 14 X.25 lines into an SS2)

Email me at jims@optimation.co.nz for more info.

Cheers, Jim



-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Nov 1993 12:43:15 +0000
From:      bob@sensorat.demon.co.uk (Bob Rowland)
To:        comp.protocols.tcp-ip
Subject:   Books on programming for TCP/IP ?

Hi everybody,
             Can anyone help this newbie and recommend any good books
that cover developing software for SLIP and TCP/IP on UNIX or POSIX. Anything 
in this area will be a great help.
Can you please e-mail any info. to Bob@sensorat.demon.co.uk. 
Thanks in advance.

-- 
Bob Rowland

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 93 13:13:52 GMT
From:      mcla@bits.alcbel.be (CLAEYS Marc)
To:        comp.protocols.tcp-ip
Subject:   Routers in parallel

Hi all,


Consider the next configuration :

Two lan's : LAN1 and LAN2.
On each lan 2 hosts : HOST11 and HOST12 on LAN1
		      HOST21 and HOST22 on LAN2

Two routers in parallel between LAN1 and LAN2: R1 and R2, viz:


	+--------+      +--------+
	| HOST21 |      | HOST22 |
	+----+---+      +----+---+
	     |               |
	     |               |
	    -+---------------+-  LAN2
	     |               |
	     |               |
	+----+---+      +----+---+
	|   R1   |      |   R2   |
	+----+---+      +----+---+
	     |               |
	     |               |
	    -+---------------+-  LAN1
	     |               |
	     |               |
	+----+---+      +----+---+
	| HOST11 |      | HOST12 |
	+--------+      +--------+


	On HOST21
	route add HOST11 R1 1
	route add HOST11 R2 1
	route add HOST12 R1 1
	route add HOST12 R2 1

	On HOST22
	route add HOST11 R1 1
	route add HOST11 R2 1
	route add HOST12 R1 1
	route add HOST12 R2 1

	On HOST11
	route add default R1 1
	or
	route add default R2 1

	On HOST12
	route add default R2 1
		or
	route add default R1 1

Given that all connections are initiated by HOST11 or
HOST12 (i.e. hosts on LAN1), has the configuration above
any chance to work? Why (not?).

Thanks in advance for replying.

Marc.


--
An optimist is a colleague that is not well informed.

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Nov 1993 14:41:19 GMT
From:      svanarts@lmsc.lockheed.com (Scott VanArtsdalen)
To:        comp.protocols.tcp-ip
Subject:   Question about subnetting.

I have a small problem that I hope to have solved.  I was hoping a 
subnet.expert could give me some advice on what I propose to do.  

I was given a block of IP addresses by our company's net.nazi for our new 
ethernet lan/wan.  We have about 10 small sites around the campus here to 
link up to our host site.  The block of addresses (changed here to protect 
the innocent) is 129.197.222.0-254.  

I know that in order to effectively use the routers I will need to subnet.  
The subnet mask I came up with is 255.255.255.240 using the first 4 bits of 
the last octet as networking bits.  So this should give me 16 networks with 
16 hosts on each, right?

Also, since our host site will have more than 16 hosts, I'll have to use 
about 3 of these for the host site alone.  Will this present a problem for 
the routers?  Say 129.197.222.1-15, .16-32, .33-47 are all local networks.  
Can each of these subnets be on the same segment?

Lastly, I'm also assuming that the netmask has to be the same across the 
entire network.  Correct?

I'm a little new to this but I think that I may have finally grasped the 
concept of subnetting.  Any advice, confirmations, or heavy petting would be 
appreciated.

Thanks for your time.

--------------------------------------------------------------------------    
    \    /\                                           Aeronca 7AC Champ
     \  /__\                                          =(*)= N3115E =(*)=
Scott \/an  \rtsdalen                                "The Boonie Bouncer"
--------------------------------------------------------------------------
        Opinions expressed here do not necessarily reflect those of
           Lockheed Missiles & Space Co., Inc. or its management.   =*
--------------------------------------------------------------------------

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Nov 1993 16:44:46 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: X.25 through tcp-ip

In article <2apa94$19l@pyrnova.mis.pyramid.com> lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:
   In article <CFLynM.L3t@festival.ed.ac.uk> ercm20@festival.ed.ac.uk (Sam Wilson) writes:
      In article <2amf9t$m0e@pyrnova.mis.pyramid.com> lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:
         In article <jpringle.4.2CCC4A42@silver.sdsmt.edu> jpringle@silver.sdsmt.edu (Jerl Pringle) writes:
            Does anyone have a solution for running x.25 traffic on
            tcp-ip?
      
         Normally it is done the other way around.... tcp/ip being
         higher protocol layers than X.25, tcp/ip is run on top of
         X.25 as a link layer.

      But not always - you may want to carry X.25 traffic over an IP
      based backbone.  Cisco have a 'proprietary but not secret'
      method of doing this and there's an effort in the IETF to
      standardise 'anything over IP', I believe.  So far as I know you
      can only do it Cisco to Cisco at present.

   Oh, be still my heart.  Just what I always wanted....to carry a
   Link Layer's traffic over a network layer.

See RFC-1241 and research.att.com:dist/smb/pnet.ext.ps.Z for some good
uses for this sort of thing.  We do it with PPP over TCP too.

   One would think that IBM's little practical joke called QLLC would
   have served as an object lesson in not doing this....oh well.

QLLC may have been a bad idea, or at least a bad implementation of a
useful (not necessarily good) idea.  Yes, multiple layers of
encapsulation may be ugly and it sometimes makes my head swim, but
it's certainly not something to discard out of hand.  For just about
anything you can think of doing with a network, someone will find
themselves backed into a situation (usually political :-) where
they'll welcome even the ugliest hacks.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221-2856      +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Nov 1993 17:07:15 GMT
From:      vesku@kcl.fi (Vesa . Sarkela)
To:        comp.protocols.tcp-ip
Subject:   Re: How to read any packet in the ethernet

In <hunenr.37.0@cis.corp.medtronic.com> hunenr@cis.corp.medtronic.com (Roger Hunen) writes:

>In article <1993Oct26.194928.10458@litwin.com> hoang1@litwin.com (Ted Hoang) writes:
>#Could someone explain how to read any packet (TCP, UDP, IP, IPX ...) directly
>#from the ethernet. Should I use open(), socket(), or none_of_the_above()...?
>#How could I read this packet from beginning (byte 0)? 
>#
>#I post this question because I plan to write a program which monitor my network
>#at home and can't afford to buy a Sniffer.

From comp.protocols.tcp-ip.ibmpc Wed Aug 25 21:31:09 1993
--- begin included text -----

We have made available a new release of Fergie, an ethernet monitor and frame
grabber that supersedes The Beholder and Gobbler.

I include the README here

-- snip,snip --
25 august 1993				Delft, The (N)etherlands
==============

We have made one last effort to put together our rather popular
ethernet sniffer software for the DOS environment, and made new
binaries with some small bug fixes, and a full source code
distribution. 

Since the DNPAP research group has moved on to more current topics
(SNMP/RMON etc.), we are no able to fully support this software (we
never have anyhow). But, we are willing to keep distribution going and
regulate any new enhancements made by other developers.
A mailing list exists:

	  fergie@dnpap.et.tudelft.nl 

Any questions about the Fergie Software can be send there. I you want
to be added to this list, you can send a mail to:

	  request@dnpap.et.tudelft.nl

OK, what software are we talking about:

	 Fergie.exe	 - the DNPAP ethernet monitor, using packet drivers
			   to capture frames from the net. Statistics 
			   are displayed on the screen. 
			   It can run either standalone or
			   using SNMP. It supersedes
			   out previous monitors Netmon, Spectre and
			   Beholder.

	Gobbler.exe	 - the DNPAP frame grabber and displayer. 

Where can you get it:

	  dnpap.et.tudelft.nl:/pub/Fergie/frgbin2.zip

	  	contains the executables of Fergie and Gobbler with
		some configuration and documentation files.

	  dnpap.et.tudelft.nl:/pub/Fergie/frgsrc2.zip

	  	contains full source code. You will need
		a Borland C compiler to compile it. We are 
		very interested to be kept informed  on further
		developments, and people who succeed in recompiling
		the software. So if you do, send a mail to
		fergie@dnpap.et.tudelft.nl

Luck, and keep us informed.

Jan

ps.	If you  use out software, you are bound to the BeerWare
	License Agreement. In short, this means that if you ever meet one
	of the DNPAP developers, you'll have to buy him a beer.
	(the term BeerWare is by somebody else, but i've forgotten 
	 who. If i ever meet him, i'll buy him a beer).

-- Ir. Jan van Oorschot.          --- Email: J.P.M.vOorschot@et.tudelft.nl --
-- Data Network Performance Analysis Project                               --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --
--- end included text ------
--

Vesa Sarkela                       Oy Keskuslaboratorio
Vesa.Sarkela@kcl.fi   The Finnish Pulp & Paper Research Institute
Vesa.Sarkela@csc.fi
-- 

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 1993 17:09:40 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: ping's maximum packet size


Ciscos are happy to emit PINGs of up to 18024 bytes.  I have
found this capability to be very useful in debugging our network.

A constrained PING that can only emit 1500-byte packets, separated
by 1-second intervals, will typically fail to reveal such problems
as too-small interframe gaps, inadequate receive buffer space, etc.
It is also much less likely to reveal a too-large collision domain.

The Cisco PING sends asynchronous back-to-back packets (send an ICMP
packet, receive a response, send another packet ...)  This allows
for a very large amount of user-like data to be delivered through
the network in a very short period of time.

I use 8192-byte PINGs very frequently in order to prove network
paths, and in order to ferret out subtle misconfigurations or 
hardware errors.  The behavior of Cisco's 8192-byte PING is a
close approximation of that of NFS as defaultly configured (six
back-to-back full-length frames, minimally spaced), and so is
an excellent simulation of the most grievous sort of real user
traffic.

So, yes, I would say that there are strong reasons why PING should
not be artifically constrained as to its packet size, but should
be able to take advantage of IP fragmentation to really give a 
network a workover.

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721

P.S. Credit to Charles Hedrick for mentioning the value of using
Cisco's 8192-byte PING as an industrial-strength testing tool.

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 1993 04:20:48 -0600
From:      ccaajac@ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: X.25 through tcp-ip

|>    Sad but true.  I've seen SNA shoehorned onto ethernet, tcp/ip on
|>    SNA, bisync 3270 on X.25, X.25 on X.25, and my favorite practical
|>    joke, ANYTHING on ISDN.  >:-)

sad  but true that the US telco's use the 8kbps spare out of 64kbps when they offer 56kbps for data, for PRIVATE stupid broken signalling- the failure to adopt true isdn in
the US widespread could be construed as restraint of trade by european companies that
make isdn kit:-) [not serious - there are soem very good us people doing isdn stuff!!]

isdn in europe is really quite useful, and a 2*64kbps dial up service is quiteacceptable for NFS and X traffic from home, with vat for audio instead of the phone....

isdn is a very good way to get some use out of the phone system for the Interne
before the Internet completely takes over:-)

-- 
jon crowcroft (hmmm...)

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Nov 1993 18:55:28 GMT
From:      rwpratt@novell.com (Robert Pratt)
To:        comp.protocols.tcp-ip
Subject:   Re: Protocol Analyser

In article <CFuF4M.4tG@qdpii.ind.dpi.qld.gov.au> neesonc@qdpii.ind.dpi.qld.gov.au (Colin Neeson) writes:
>Does anyone out there know of a WINDOWS protocol analyser that would be 
>comparable to NSA or any of the DNPAP (excellent) products?
 ...
>Colin Neeson                               |  philistine, pig-ignorance I've
>email: neesonc@qdpii.ind.dpi.qld.gov.au    |  word _don't_ tell me about it!)
   
    To the best of my knowledge, LANalyzer for Windows is the only Windows
based network analyzer out today.  It runs on top of ODI drivers, and provides
protocol decodes for the TCP/IP, NetWare, and Appletalk suites.
    There are other DOS-based analyzers besides Intel, including Triticom,
FTP, and others, but none of them are Windows products.
    Of course, since LANalyzer uses ODI drivers instead of packet
drivers, I'm not sure how it will complicate the QVT/NET situation
you're trying to resolve, but good luck :-)

Bob
 
Bob Pratt                               | voice     : (408) 473-8274
Novell, Inc.                            | Fax       : (408) 435-1706
2180 Fortune Drive, San Jose, Ca. 95131 | Internet  : rpratt@Novell.com
Disclaimer:  I do not speak for Novell in any way, shape, or form.
"Cuius testiculos habes, habeas cardia et cerebellum."
        -- (Terry Pratchett, Small Gods)

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Nov 1993 19:31:52 GMT
From:      lawson@netcom.com (Steven Lawson)
To:        comp.protocols.tcp-ip
Subject:   Opinions on TCP/IP stacks

I need anyones opinions/experiences on available TCP/IP protocol stacks,
specifically any which may be ported to a 680x0 based NON-Unix O/S.  I
need to know your experiences with reliability, modularity, ease of porting,
etc.

Please email me any responses to lawson@netcom.com

thanks!

- Steve


-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 93 19:57:20 GMT
From:      karthik@informix.com (Karthikeyan Guruswamy)
To:        comp.protocols.tcp-ip
Subject:   WinQVT for Windows NT ...

Hi,
Sorry if this is a FAQ. Where can I grab WinQVT for NT ?  

Thanks,
Karthik
---------------------------------------------------------------
Karthik						
Infosoft Inc, (Contractor to INFORMIX Inc.)
Cupertino, CA


All the views expressed here are solely mine and they dont 
represent those of my organization.
---------------------------------------------------------------

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Nov 1993 20:08:34 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: X.25 through tcp-ip

In article <BOB.93Nov2114443@volitans.MorningStar.Com> Support@MorningStar.Com (MST Tech Support Group) writes:
>                                                 ...  For just about
>anything you can think of doing with a network, someone will find
>themselves backed into a situation (usually political :-) where
>they'll welcome even the ugliest hacks.

I went home from the first InterOP in Monterey muttering that 90%
of all of "networks" is politics, not "technology."

That applies even to the 10% that is not described by Sturgeon's law
(that says 90% of everything is baloney).


Vernon Schryver    vjs@rhyolite.com

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Nov 1993 20:21:18 GMT
From:      ccfj@hippo.ru.ac.za (F. Jacot Guillarmod)
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   PCRoute into Xylogics Annex terminal server?

A possibly naive, and definitely hopeful, question:

Is it possible to use a single PCRouter, configured with an ether and
serial SLIP interface and run the serial side of this configuration into a
SLIP port on a Xylogics Annex terminal server on a central ethernet
backbone?

The idea is to link up a lot of remote subnetted ethernet segments on
campus without having to provide a corresponding PCRouter on the
central backbone.

We're running out of power points, not to mention floor space, for
mounds of PC's acting as routers in our computer room, and I'd
be interested to know if anyone has tried this successfully, or if
there's some technical reason it wouldn't work.

Any feedback or comments on this approach appreciated.
-- 
  F.F. Jacot Guillarmod     PO  Box 94     \        |     ccfj@hippo.ru.ac.za
  Computing Centre       Grahamstown 6140   \      /      Fax: +27 461 25049
  Rhodes University        South Africa      ;___*/     Phone: +27 461 318284


-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 1993 11:28:10 -0800
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: ISDN (was Re: X.25 through tcp-ip)

In article <1993Nov3.064001.17495@dumbcat.sf.ca.us> marc@dumbcat.sf.ca.us (Marco S Hyman) writes:
>
>Warning -- Lon pushed a button without knowing it :-)
>
>AARRRRGGGHHH.  The only thing wrong with ISDN is that computer networking
>types think the N stands for *computer* Networking.  It doesn't.
>
   No, I knew I pushed that button.  The button was aimed at the
   computer network types you mention....as well as those who
   assume ISDN is a single layer and leave it at that.

   My REAL gripe about ISDN (donning asbestos undershorts) is that
   I can't get it where I need it...

   However, you've suggested some new acronym interpretations for my 
   collection:

      It Simply Don't Network



-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Nov 1993 23:12:42 GMT
From:      add@is.rice.edu (Arthur Darren Dunham)
To:        comp.protocols.tcp-ip
Subject:   MacTCP 2.0.4, Multicast?

Simple question:

Does anyone know if MacTCP 2.0.4 can do IP multicast, or will I have to
wait for MacTCP 3.0?
-- 
Darren Dunham                 		          add@is.rice.edu
MicroConsultant                       		  Rice University
(What is that? A small consultant?)	              Houston, TX
Any resemblance between real opinions and my post is coincidental

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 93 00:17:33 GMT
From:      karthik@informix.com
To:        comp.protocols.tcp-ip
Subject:   QVTNET for NT


Hi,
To the creators of WINQVT for NT = Hats off ! It's just too much you
can get for a NT workstation as shareware. 

Karthik

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 1993 00:44:05 GMT
From:      resnick@cogsci.uiuc.edu (Pete Resnick)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP 2.0.4, Multicast?

add@is.rice.edu (Arthur Darren Dunham) writes:

>Does anyone know if MacTCP 2.0.4 can do IP multicast, or will I have to
>wait for MacTCP 3.0?

You will have to wait for 3.0. MacTCP 2.0.4 does not do IP multicast.

pr
-- 
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: resnick@cogsci.uiuc.edu

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Nov 1993 02:20:35 GMT
From:      bleys@vpnet.chi.il.us (Bleys Ahrens)
To:        comp.protocols.tcp-ip
Subject:   IBM 3172 or Memorex 9340 devices...

I am looking for people who are currently using IBM 3172 or
Memorex 9340 type devices (channel attached with LAN adapters)
to run TCP/IP to MVS on IBM mainframes. (Other similar devices
are made by NCR and MacData.)  We are very interested in your
experiences and answers to some of the following questions:

1. What has your uptime been for the device?
2. When you have problems, how has support been?
3. How has performance been; telnet, ftp, sockets, etc?
4. How many users can the device comfortably support?
5. What other vendors did you look at and why did you choose the one you did?
6. The 3172 has no fault tolerance.  This scares us...  Should it?
(I wouldn't put a departmental file server out without fault tolerance,
much less a device my whole network will be dependant upon.)

Ideally I would like to have someone call you to discuss this.  Minimally,
I would really appreciate email with answers to the above questions.

Thanks.
Bleys

--

==========================================================================
=   Bleys Ahrens                                             Chicago, IL =
=                        VPNET/Public Access Usenet                      =
=   Information gains value when shared...         bleys@vpnet.chi.il.us =
==========================================================================

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Nov 1993 02:22:32 GMT
From:      bleys@vpnet.chi.il.us (Bleys Ahrens)
To:        comp.protocols.tcp-ip
Subject:   Sockets access to CICS...

I am seeking people with experience using TCP/IP sockets to access
CICS applications on MVS.  We are about to embark on this path 
and would like to benefit from other people's experience.

Please reply by email.

Thanks.
Bleys

--

==========================================================================
=   Bleys Ahrens                                             Chicago, IL =
=                        VPNET/Public Access Usenet                      =
=   Information gains value when shared...         bleys@vpnet.chi.il.us =
==========================================================================

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 93 06:40:01 GMT
From:      marc@dumbcat.sf.ca.us (Marco S Hyman)
To:        comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   ISDN (was Re: X.25 through tcp-ip)

In article <2b64j0$1en@pyrnova.mis.pyramid.com> lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:
 >    Sad but true.  I've seen SNA shoehorned onto ethernet, tcp/ip on
 >    SNA, bisync 3270 on X.25, X.25 on X.25, and my favorite practical
 >    joke, ANYTHING on ISDN.  >:-)

Warning -- Lon pushed a button without knowing it :-)

AARRRRGGGHHH.  The only thing wrong with ISDN is that computer networking
types think the N stands for *computer* Networking.  It doesn't.

Questions:
 * what's funny about a leased 56 kbit/s digital line.
 * Ok, how about a switched 56 kbit/s digital line.  Or do you prefer
   a 14.4 modem on an analog line.  Remember, compression can be done
   over either, so if you claim 57.6 kbit/s over the analog line I claim
   224 kbit/s over the digital line.

ISDN *today* gives you switched 56 kbit/s (64 kbit/s if you're lucky)
at prices in the same range as the 14.4 kbit/s modem on a business line.
The only problem is that you can't get it everywhere (I have a pair of
old fashion switched 56 lines for just that reason).

Sorry, I'm off my soapbox.  Followups to comp.dcom.isdn.

// marc
-- 
// primary:	marc@dumbcat.sf.ca.us	pacbell!dumbcat!marc    
// secondary:	marc@ascend.com		uunet!aria!marc

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Wed, 03 Nov 1993 15:42:32 -0500
From:      Steven_Carmody@brown.edu ()
To:        comp.protocols.tcp-ip
Subject:   Authorization Service

More and more of the client-server style services that we deploy seem to
need some sort of authorization control available to the server. An example
might be private conferencing groups within a news server -- a conference
that can only be seen and read by a specified group of people (eg the
members of a seminar group).

We're interested in having a single authorization service, which our
servers can use. OSF/DCE includes both authentication and authorization;
however no one I've talked to knows how to use those if my existing client
base is distinctly non-DCE (its thousands of  Macs, PC/DOS, and PC/Windows
machines).

Does anyone have such a service in place? Have anyone heard of such a
service? 

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Nov 1993 09:00:45 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Address Translation Gateways

In article <2arqnt$rge@cnj.digex.com> hand@cnj.digex.com writes:
>
>        I'm looking for pointers to information on IP address translation 
>gateways.  Specifically, I'm looking for ways to allow Internet connectivity
>as transparently as possible to a large IP network with non-NIC-assigned
>IP addresses.  I was hoping that with the shortage of IP network numbers, 
>there might already be some good solutions available to this problem.

I've been looking into this one too, for about six months.
You might not find much success, but please post any ideas or comments.

Most very experienced TCP/IP experts recommend that NIC registered
addresses are used exclusively, universally.  That is they recommend 
against having any private internets with private address spaces.
Quite naturally, they base this advice on the awful warnings of
other organisations who tried it, came unstuck, needed to connect
to the Internet and had major transitional (re-addressing) problems.

I accept these points of wisdom, but I also happen to believe
that there are many organisations who genuinely wish never to be
connected to the Internet or to any other Internet-connected
subnets.  (Yes, NEVER  -  it's policy)
(I have several large clients who fall into this category.)

If your plan is to have a few hosts (within a large private internet)
connect via border routers into the Internet, then the choices are 
limited.

To answer your first question (IP address translation): I looked into
that and was helped by several IP experts who advised that the TCP
checksum included the IP addresses (called the "psuedo header").  
This would mean that you can't just translate the addresses "on the
fly" in the IP packet.  I suspect that to actually make something like 
that work, you would need to process the TCP packets too, which
would mean your "gateway" would be effectively a transport relay.
Because of the complexity we dropped this idea.

The other answer is to use "secondary addressing" on a LAN port
of a router.  (Cisco routers support this.)  The router 
would be at the border between your private internet and the Internet,
connected by LAN or WAN.  On the private side of the router (a LAN
port) you tell the router that two subnets exist on the same LAN
segment (primary subnet address={private}, secondary address={Internet})

You then install static routing (and filtering) on the border router 
to ensure that no packets to or from hosts with private addresses 
ever leak out to the Internet, and vice versa.

Hosts of each identity can then coexist on the "dual identity" LAN 
subnet.

This is only feasible for workstations (typically PCs). 
Under normal operations they boot up (or load their TCP/IP stack)
with private addresses and participate in their local private
internet.   Fine.  They are unaware of the presence on the Internet
beyond the border router.

When they need to connect to the Internet, they either roboot with
a different stack config file (or reload the stack with the different
config file, containing the Internet registered IP address), having 
unloaded the  first stack/config file. (The key is to have two config 
files for loading the TCP/IP stack with, one with the Internet 
registered address and the other with the private address).

During times when the Internet addresses stack is loaded, the host
participates in the Internet, but is totally ignored by the other
hosts on the same LAN.

I don't know what this would do to the name service.  I suspect that 
one might need to configure in a separate name server for each "identity"
under which the host operated?

Any comments?

-- 

Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      | (networking & OSI specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 1993 19:55:59 -0500
From:      myke@terminator.rs.itd.umich.edu (Michael Dautermann)
To:        comp.sys.mac.comm,comp.sys.mac.misc,comp.protocols.appletalk,comp.sys.mac.apps,comp.protocols.tcp-ip,umich.archives
Subject:   Re: Mac LPD

In article <1993Nov3.192923.24324@gumby.dsd.trw.com>,
Jeanine A. Modic-Carmona <modic@gumby.dsd.trw.com> wrote:
>
>
>I was wondering if anyone is using an LPD server on the Macintosh. If so which
>one? And where do I get it? I am specifically looking for something that can    accept non-postscript files to print to a printer connected by Appletalk. The   reason being is I'm sending data from an IBM mainframe to print.
>
>Please send any responses directly modicj@r3vm.dsd.trw.com


I'll e-mail Jeanine.. as well as post this to the group...

Here's something that you can probably use... I found this listing
in the mac.archive.umich.edu index, which is the "index.txt" file
in the "00help" directory.

/mac/util/print/lpdaemon3.32.cpt.hqx
  77     4/10/93    BinHex4.0,Compact1.34

   Transmit files from Unix hosts through your Mac (which acts as a
   server), to be printed on LaserWriters on the Macintosh network.
   Includes LPR 1.0.1, an lpDaemon client that submits jobs to a
   (UNIX) printer queue.  Both require MacTCP.  Different from
   /mac/util/print/lpr1.2.cpt.hqx 

Source is also available as:

/mac/development/source/lpdaemon3.32src.cpt.hqx
 135    4/10/93     BinHex4.0,Compact1.34

   THINK C source to /mac/util/print/lpdaemon3.32.cpt.hqx, a program
   to send files from Unix hosts through your Mac (which acts as a
   server), to be printed on LaserWriters on the Macintosh network.
   Also includes source to LPR 1.0.1, an lpDaemon client that submits
   jobs to a (UNIX) printer queue.



If you're interested in getting on the mac.archive "recent files" mailing
list, drop me a line at "mac-recent-request@mac.archive.umich.edu".

Hope that helps!


-- 
-----------------------------------------------------------------
myke@terminator.rs.itd.umich.edu = insmxd04@nt.com = myke@umich.edu
mike@mac.archive.umich.edu = MISTER archive
Michael Dautermann - U-M Alumni calling in from the world...

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 1993 19:56:09 -0500
From:      msbendts@mtu.edu (Michael S. Bendtsen)
To:        comp.os.ms-windows.setup,comp.os.ms-windows.misc,comp.protocols.tcp-ip
Subject:   Re: Windows for Workgroups over TCP/IP

Bill Kress (kress@kentrox.com) wrote:
>
> As long as we're at it, IF it is possible to get WFW running on a TCP/IP
> network (say, perhaps with a bunch of unix machines on it, or not...) what
> would it take to get internet news and e-mail?  Would we have to use a
> winsock-compatible mail/news reader or are these tools built in to
> WFW.  Also, if there isn't a unix machine to hold the news, can the
> WFW machines themselves take care of it?
>
> A little more than curious.
>      Bill Kress.

Yes, WfW can run concurrently with a TCP/IP network.  I have setup WfW and
FTP Software's PC/TCP pacakge on my network without much of a hitch.  I am
even using an outta date version of the PC/TCP package too (v2.05...they 
are now up to v2.11)  As for getting winsock to work with it, I have not
yet been successful, but I have also not tried the winsock.dll update that
I just got yet either.  (FTP PC/TCP winsock.dll can be obatined at ftp.com)
I might be SOL due to my version of FTP's package, but I have heard of others
having no problems.

As for having the PC doing the NNTP services...I don't know of any programs
written to do that yet.

Mike
-- 
 Mike Bendtsen                          msbendts@mtu.edu
  CCLI Senior Technical Consultant      Windows Administrator
  Michigan Technilogical University     Multiplatform Systems Integrator

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 93 14:28:44 GMT
From:      dove+@pitt.edu (Daniel L Dove)
To:        comp.protocols.tcp-ip
Subject:   Looking for some help concerning the TELNET client protocol


	Hello, I'm looking for any info concerning the TELNET protocol. 
I'm currently working aon a server for a research project in TCP/IP.  I
would like to use telnet instead of building my own client. A couple of
the specific things I'd like to know about are 

	How to format the telnet screen from the server?

	Can Telnet clients recieve color ANSI codes??           

	I appologize if I have not quite phrased the questions correctly.
I'm not really sure what terminology is used for these subjects.


	Any help would be greatly appriciated


	Thanks in Advance


				Dan Dare
				dove@vms.cis.pitt.edu
				dove@unixd.cis.pitt.edu


-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Wed, 03 Nov 1993 14:43:01 GMT
From:      mark@cyantic.com (Mark T. Dornfeld)
To:        comp.protocols.tcp-ip
Subject:   WAN network numbers

One of our clients is using CISCO routers to connect their remote sites to
the corporate backbone. They are routing IP, IPX, and EtherTalk.

The synchronous ports on the Cisco equipment have been given IP addresses.
There is a facility in the router configuration that allows these ports to
to be configured as "unnumbered" ports. It seems to be a reasonable way to
run the WAN rather than waste IP numbers on each one of the synchronous
ports.

I cannot tell from the docs whether there are any side effects of doing this
or whether it is really the right way to handle the Cisco routing.

Please email responses, since I may not be receiving this newsgroup
consistently.

-- 

Mark T. Dornfeld, CYANTIC Systems             Voice: (416) 234-9048
101 Subway Crescent Suite 2103                Facsimile: (416) 234-0477
Etobicoke, Ontario, M9B 6K4 CANADA            Email: mark@cyantic.com

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 93 14:54:54 GMT
From:      jessea@u013.me.vp.com (Jesse W. Asher)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   DIS version of ka9q?

Does anyone know where I can get the DIS version of ka9q?  I don't even know
what DIS stands for so archie wasn't a whole lot of help.  Thanks.

-- 
      Jesse W. Asher                                          (901)762-6000
                             Varco-Pruden Buildings
                 6000 Poplar Ave., Suite 400, Memphis, TN  38119
    Internet: jessea@vpbuild.vp.com                   UUCP: vpbuild!jessea

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Nov 1993 14:58:42 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP 2.0.4, Multicast?

In article <CFw0H6.6oy@rice.edu> add@is.rice.edu (Arthur Darren Dunham) writes:
>
>Does anyone know if MacTCP 2.0.4 can do IP multicast, or will I have to
>wait for MacTCP 3.0?

Please post a followup to the newsgroup if you know, this is of
widespread interest.  I'd clarify the question by asking if IGMP is
implemented as well.

A second question is whether the long-standing TCP implementation bug
that results in sub-par performance from MacTCP has been fixed in this
release.

Ran
atkinson@itd.nrl.navy.mil




-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 93 15:56:29 GMT
From:      st92ebps@dunx1.ocs.drexel.edu (Kim Baxter)
To:        comp.protocols.tcp-ip
Subject:   NFS on the Macintoshes

I would like information on any companies *other than* Intercon who sell NFS    software for use on a Macintosh Ethernet network.  I also need to know what is
involved in converting a LocalTalk network to Ethernet other than buying the
Ethernet cards (or is that all I need to do?)
Finally, I am interested in providing dial-in access to remote users who want to access their Internet account which will be set up on this Mac network.  What  software does a remote user need, and can they use a PC (or dumb terminal) to   dial in to Internet which is on a Mac network?
Am I likely to need more RAM in these Macs to run this network fairly quickly   and house 100+ accounts?  It is a network of 4 macs:  a IIci with 8 megs, a
IIsi with 8 megs, and two LCIIIs with 4 megs of RAM.  Two printers are also on
PA College of Podiatry
work to have its own Internet node, and I need to figure out how it will work
on the Macintosh network to estimate hardware and software costs.
Thank you for your time.
Kim 
 
 
 



PA College of Podia

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 1993 16:34:38 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Re: PCRoute into Xylogics Annex terminal server?


In article <CFvsJJ.Dz@hippo.ru.ac.za>, ccfj@hippo.ru.ac.za (F. Jacot Guillarmod) writes:
|A possibly naive, and definitely hopeful, question:
|
|Is it possible to use a single PCRouter, configured with an ether and
|serial SLIP interface and run the serial side of this configuration into a
|SLIP port on a Xylogics Annex terminal server on a central ethernet
|backbone?
|
|The idea is to link up a lot of remote subnetted ethernet segments on
|campus without having to provide a corresponding PCRouter on the
|central backbone.
|
|We're running out of power points, not to mention floor space, for
|mounds of PC's acting as routers in our computer room, and I'd
|be interested to know if anyone has tried this successfully, or if
|there's some technical reason it wouldn't work.

Yes, this sure should work.  A Xylogics Annex can support routing
to arbitrary-topology remote networks thru its serial ports.
And this seems a heck of a lot smarter than stacking up "mounds
of PC's" in your computer room, especially as a port on an Annex
costs much, much less than a PC with an Ethernet adapter.

See the sections "SLIP Configurations: Connecting Two Networks
Together" and "Routing Services and Gateway Entries" in the
Annex _Network Administrator's Guide_ for more info on how to
configure this.

There is one caveat: an Annex can listen to RIP but will not speak it.
So any routers on your backbone side should be configured with 
static routes thru the Annex to your remote nets.

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721


-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Nov 1993 16:43:35 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Extensive use of PUSH on large network, feasible ?

In article <CFv2HF.H4@sci.kun.nl> albertk@cs.kun.nl (Albert Koppes) writes:
>In an application we are planning the use of
>the TCP PUSH mechanism to implement a kind
>of message boundary keeping, and to
>avoid applications to implement this.

I hope that you are not expecting the stream break caused by the PUSH
to be preserved at the receiving end.  TCP does not guarantee this.
Under light loads and network traffic it may appear to behave like
that, but TCP only ever guarantees a byte stream.  Where the breaks
occur in the received byte stream depend on many factors.

>Therefore, every SEND will use the PUSH
>mechanism. 
>I have the impression that the use of PUSH will
>put some burden on the TCP-stack, as more interupts
>are generated.

If you use PUSH frequently, after small numbers of bytes, it will tend
to cause TCP to generate many tiny segments.  This wastes CPU resources
and causes more network header overhead.

>Is somebody familiar with this
>PUSH-ing of data if it is extensively used ? And
>in general is it really a good method of keeping
>message boundaries ?

Again, PUSH does not guarantee boudaries.  It is only ment to insure that
data be sent as soon as possible.

Art


-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Nov 1993 16:45:03 GMT
From:      heka@ost.ericsson.se (Hedie Kamoun)
To:        comp.protocols.tcp-ip
Subject:   Detecting broken connection

Hello TCP gurus,
	I have a problem which I badly need solved, which I thought I'd run by
the collective wisdom of this group. 
	I need to be able to detect that my server process goes away. As I have
it working right now it takes some 5-10 sends before the client detects that its
sending doesn't get through.
	I did some experimenting with select()'ing the socket for reads and at
the same time with the ioctl(s, FIONREAD, &nr) tried to figure out the nr of
available bytes. In my mind if this turned out to be zero (still with the socket
being marked readable) this would indicate a reset from my server, a RST-packet?
	Now this doesn't seem to work. I should perhaps mention that I used select
as a poll with a 0 timeval. The detection still doesn't occur until a couple of
sends. What am I doing wrong. 
	The architecture I'm using is Sun and their 4.1.? OS. Any suggestions or
oppinions on this issue are very welcome. I know this question have been on the
net before however I didn't pay much attention at the time, anybody saved some of
the discussions on file? 
	Thanks in advance for any inconvenience

	Best regards Hedie
	Email: heka@ppvku.ericsson.se


-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 93 22:24:34 CDT
From:      rsl11@kuhub.cc.ukans.edu
To:        comp.sys.ibm.pc.misc,comp.protocols.tcp-ip
Subject:   X-Windows Emulator for PC,Public Domain or Shareware

Hello there,

	
	I would like to know if there is any public domain or Shareware or low
price software program for the PC that allowss you to emulate X-Windows for the 
PC. If there are some public domain please let me know whare I could find them.
Also, if you could have a comparison of all the availble packeges that would be
great.



    	I would appreciate any relevant response preferably by e-mail.


E-mail: rsl11@kuhub.cc.ukans.edu

	Thanks, Chris.

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 1993 18:22:07 GMT
From:      resnick@cogsci.uiuc.edu (Pete Resnick)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP 2.0.4, Multicast?

atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:

>In article <CFw0H6.6oy@rice.edu> add@is.rice.edu (Arthur Darren Dunham) writes:
>>
>>Does anyone know if MacTCP 2.0.4 can do IP multicast, or will I have to
>>wait for MacTCP 3.0?
 
>Please post a followup to the newsgroup if you know, this is of
>widespread interest.  I'd clarify the question by asking if IGMP is
>implemented as well.

As per my most yesterday, multicast is not supported by MacTCP 2.0.4.

>A second question is whether the long-standing TCP implementation bug
>that results in sub-par performance from MacTCP has been fixed in this
>release.

It has been greatly improved if not fixed. I take it you are referring
here to the retransmit timer problem. Everyone I have heard from so
far seems very pleased, even over slow SLIP connections.

Many other bugs were addresses in 2.0.4. Overall, I think it is the
best set of bug fixes to date.

pr
-- 
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: resnick@cogsci.uiuc.edu

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 1993 19:03:40 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: WAN network numbers

In article <1993Nov03.144301.26060@cyantic.com> mark@cyantic.com (Mark T.
Dornfeld) writes: 
    One of our clients is using CISCO routers to connect their remote sites to
    the corporate backbone. They are routing IP, IPX, and EtherTalk.
    
    The synchronous ports on the Cisco equipment have been given IP addresses.
    There is a facility in the router configuration that allows these ports to
    to be configured as "unnumbered" ports. It seems to be a reasonable way to
    run the WAN rather than waste IP numbers on each one of the synchronous
    ports.
    
    I cannot tell from the docs whether there are any side effects of doing
    this or whether it is really the right way to handle the Cisco routing.
    
There are some significant side effects, depending on how you're doing
routing.  They're listed in the chapter on IP routing.  The biggies are:

 - you can't ping the unnumbered interface (nothing to refer to)
 - you have real problems if you have different major network numbers on
   either end of the serial link

Is it the right way?  Depends on your situation.  Suggest you try one of
each and see which you prefer.

Tony

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Nov 1993 19:29:23 GMT
From:      modic@gumby.dsd.trw.com (Jeanine A. Modic-Carmona)
To:        comp.sys.mac,comp.sys.mac.comm,comp.sys.mac.misc,comp.protocols.appletalk,comp.sys.mac.app,comp.protocols.tcp-ip
Subject:   Mac LPD



I was wondering if anyone is using an LPD server on the Macintosh. If so which
one? And where do I get it? I am specifically looking for something that can    accept non-postscript files to print to a printer connected by Appletalk. The   reason being is I'm sending data from an IBM mainframe to print.

Please send any responses directly modicj@r3vm.dsd.trw.com

Thanks...
Jeanine Modic
TRW
One Space Park
Redondo Beach, California

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 1993 20:00:20 GMT
From:      csch@netcs.com (Clemens Schrimpe)
To:        comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: ISDN (was Re: X.25 through tcp-ip)

In article <2b90oa$fus@pyrnova.mis.pyramid.com>, lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:
[...]
<>    My REAL gripe about ISDN (donning asbestos undershorts) is that
<>    I can't get it where I need it...
Careful where you step, guys, you're not alone on this planet!
(Sorry, but sometimes I *NEED* to say that - at least when I just received
some US phone bills, where most of the dialed number is cut off, because some
smart-head believed, that EVERY phone-# in the world is just 7 digits long :-( )

There REALLY are countries, where you CAN GET IT EVERYWHERE (except maybe on
mountain-tops, but if you say "... but I can get my sw-56 up there..." I would
respond: "Ok, if you get a PTT guy to climb up there he could as well put an
ISDN line in place :-)" )
Just to name a few: Japan, France, Germany (except some lonely parts of former
East-germany, but this is about to be fixed by next spring), Belgium, Denmark,
Finland, Sweden, Singapore, etc. pp.

AND: You CAN get it in at least the civilized parts of even YOUR COUNTRY.
BUT: The problem is not on the technical side, but mostly on the administrative/marketing side - sometimes the guys from the local telco DON'T
EVEN KNOW themself, that ISDN is available. Sometimes I have the feeling, that their thoughts are somewhat like "... Hmmm this guy, I have on the phone, wants something I don't know how to handle - lets just sell him a good ol' sw-56 and we booth will be fine ...".
Don't believe it? I called PacBell at the beginning of August this year, asking whether ISDN would be available in Santa Cruz and it took them some time (since I was insisting on a ultimate answer they couldn't get rid of me :-) to find out, that there might be a chance. My question, whether I could make international data calls on such a "might be" line was answered with a "I don't believe so...". The facts: There WAS a line available and I WAS ABLE to call 
a German ISDN line w/ 64kbps unrestricted data BC (call setup time ~ 4-6 seconds, unfortunately there was no CLI available in either direction).

The sum of all this talk: *** ASK !!! ***

Greetings,

	Clemens Schrimpe, netCS Berlin

PS: If you don't believe in this technology, ping csch.home.netcs.com - it's my
    "TeleCommuterTool" at home - hooked up via ISDN :-)
--
INTERNET:  csch@netcs.com        WWW:    http://www.netcs.com/PEOPLE/csch.html
PHONE:     +49-30-21500541       FAX:    +49-30-855 52 18

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Nov 1993 22:00:15 GMT
From:      kress@kentrox.com (Bill Kress)
To:        comp.os.ms-windows.setup,comp.os.ms-windows.misc,comp.protocols.tcp-ip
Subject:   Re: Windows for Workgroups over TCP/IP

In article <2ampn7$eqf@openlink.openlink.com> car@public.btr.com (Carlos Rimola-Sarti  car@btr.com) writes:
>From: car@public.btr.com (Carlos Rimola-Sarti  car@btr.com)
>Subject: Windows for Workgroups over TCP/IP
>Date: 27 Oct 1993 21:37:43 GMT
 
>Can someone tell me if it is possible to get WFW to run using TCP/IP
>as a transport protocol.  As I understand it, WFW uses the Netbios
>interface to talk to the network.  FTP Software's PC/TCP includes an
>implementation of Netbios over TCP/IP (RFC 1001/1002) which is supposed
>to allow applications that talk to the Netbios interface to run over
>TCP/IP.  Has anyone successfully tried this (WFW over PC/TCP's Netbios)?
 
>I have also heard that Microsoft is planning to provide native support for
>WFW over TCP/IP.  Can anyone confirm this and when it may be available.
 
>Please post and e-mail responses.  I need an answer soon.
 
>Many thanks!

As long as we're at it, IF it is possible to get WFW running on a TCP/IP
network (say, perhaps with a bunch of unix machines on it, or not...) what
would it take to get internet news and e-mail?  Would we have to use a
winsock-compatible mail/news reader or are these tools built in to
WFW.  Also, if there isn't a unix machine to hold the news, can the
WFW machines themselves take care of it?

A little more than curious.
     Bill Kress.

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Nov 1993 22:14:52 GMT
From:      ashok@biochemistry.cwru.edu (Ashok Aiyar)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: DIS version of ka9q?

In article <1993Nov03.145454.18834@vpbuild.vp.com> jessea@u013.me.vp.com (Jesse W. Asher) writes:

>Does anyone know where I can get the DIS version of ka9q?  I don't even know
>what DIS stands for so archie wasn't a whole lot of help.  Thanks.


DIS = Demon Internet Services

Try ftp.demon.co.uk

Later,
Ashok

--
Ashok Aiyar                        Email: ashok@biochemistry.cwru.edu
Department of Biochemistry           Tel: (216) 368-3300
CWRU School of Medicine              Fax: (216) 368-4544
MIME Enclosures OK

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 93 00:06:10 GMT
From:      cggarrat@csir.co.za (CRAIG)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibm-pc
Subject:   Bootp - where is it headed

I am about to install bootp on our campus and the server I intend using is 
version 1.8 of the software written at the Technical University of Czech.

Our campus is quite large and before we embark on this line of fire I would 
just like to first check that I am not overlooking some changes that have 
been/are imminent with bootp. [It was noted by a colleague that there was 
some discussion on changes to bootp recently but unfortunately I missed 
it :-(]

If anyone has any comments or suggestions please could you e-mail me.

Ta

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Nov 1993 00:47:03 GMT
From:      jrg@rahul.net (John Galloway)
To:        comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: ISDN (was Re: X.25 through tcp-ip)

In article <2b92kl$n88@sunmbx.netmbx.de> csch@netcs.com (Clemens Schrimpe) writes:
>In article <2b90oa$fus@pyrnova.mis.pyramid.com>, lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:
>[...]
><>    My REAL gripe about ISDN (donning asbestos undershorts) is that
><>    I can't get it where I need it...
>Careful where you step, guys, you're not alone on this planet!
>(Sorry, but sometimes I *NEED* to say that - at least when I just received
>some US phone bills, where most of the dialed number is cut off, because some
>smart-head believed, that EVERY phone-# in the world is just 7 digits long :-( )
>
>There REALLY are countries, where you CAN GET IT EVERYWHERE ...
>Just to name a few: Japan, France, Germany (except some lonely parts of former
>East-germany, but this is about to be fixed by next spring), Belgium, Denmark,
>Finland, Sweden, Singapore, etc. pp.
>
Yes but you need to be careful about what you mean by "it", if your using
ISDN for IP, I was amazed when doing a contract in Munich that even the
giant Siemens Nixdorf was until recently using uucp for email because a
dedicated IP connection was to expensive due to the control of telecom by the
government. I don't know the details, or if its changing, but just because
ISDN is "available" may be a bit misleading.
	-jrg
-- 
internet    jrg@galloway.sj.ca.us  John R. Galloway, Jr  795 Beaver Creek Way
applelink   D3413                  CEO...receptionist    San Jose, CA   95133
                                   Galloway Research     (408) 259-2490

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Nov 1993 02:36:36 GMT
From:      dpi@world.std.com (Mike Bloom)
To:        comp.protocols.tcp-ip
Subject:   multiple subnets on same physical wire

Fellow netters:

A very brief question: is it legal/possible to have several subnets share
the same piece of physical thinnet cable?  A test customer of mine had the
following arrangement, but I'm not sure that it was legal:

1. Two subnets (e.g., 16.122.144 and 16.122.128) in the same building, each
   with many Unix workstation nodes.
2. Two routers were configured as well, namely, one routed from subnet 144
   to 128 while the other routed from 128 to 144.  The routers were also on
   the same physical wire, I believe.
3. I tried to ping one node on subnet 128 from another on subnet 144, but
   this failed.
4. I tried to construct static routes from the workstation on 128 through
   the 128-144 router, as well as one in the opposite direction, but the
   attempt to establish a route from 144-128 just hung.  The ping failed
   too.  The customer's system administrator felt that the routers had
   all of the routine information they needed without the need for extra
   static routes, but we tried it anyway.
5. It may be possible that the node on subnet 128 did not have its IP address
   correctly set in it, but this is simply speculation at the moment.  Clearly,
   this would explain the symptoms that we saw!

Any info on what we did wrong and what we should do next would be appreciated.
Thanks in advance,

Mike Bloom,
Digital Products, Inc.


-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 1993 03:38:35 +0100
From:      agulbra@nvg.unit.no (Arnt Gulbrandsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Authorization Service

In article <Steven_Carmody-031193154232@stcmacii.cis.brown.edu>,
 <Steven_Carmody@brown.edu> wrote:
>More and more of the client-server style services that we deploy seem to
>need some sort of authorization control available to the server.

<lots deleted>

>Does anyone have such a service in place? Have anyone heard of such a
>service? 

This is sure to start a flame war:

IMHO, you can use RFC1413, provided that you ONLY use it for
multiuser machines which YOU administrate and control.  No PCs
running DOS, no machines with unknown superusers, no *.do.main
wildcards.

Once again, to make myself perfectly clear:  If you have a list of IP
numbers belonging to machines which you control, disallowing access
by everyone else and using RFC1413 to authenticate access by these
machines should do what you want.

I think you can find code at lysator.liu.se.

Alternatively, you can do as imapd does and sail on ~/.rhosts.

--Arnt

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Nov 1993 05:33:03 GMT
From:      visser@convex.com (Lance Visser)
To:        comp.protocols.tcp-ip
Subject:   Re: Tcp Push?

In <2b4fms$p7u@perot.mtsu.edu> csehm@perot.mtsu.edu (Mr. Erik Moe) writes:

+>How does one flush TCP data and send it to the receiver?

	In most implementations you dont need to flush TCP data.  Its
done for you.  The TCP push bit doesn't have a whole lot of meaning
in many implementations.  You send and receive as fast as you can.
The flow control stuff regulates what gets sent.




-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Nov 1993 07:26:24 GMT
From:      secssxn@mx.secs.csun.edu (Scott Neugroschl)
To:        comp.protocols.tcp-ip,biz.sco.opendesktop
Subject:   NFS printers under SCO ODT 2.0


We are using SCO ODT 2.0 and Wollong Pathway 2.1.1 and Client NFS 1.2.1
(? not sure if that is correct -- either 1.2 or 1.2.1).  When we try to
mount a printer via NFS we find its not exported.  When I put a printer
in the /etc/exports file on the server, SCO barfs and pcnfsd dies when
I try to mount it.

What is the proper way to export a printer for NFS mount/printing?  TFM
doesn't give any clues.

-- 
Scott "The Pseudo-Hacker" Neugroschl
-- Beat me, Whip me, make me code in Ada

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Nov 1993 10:31:26 GMT
From:      Helge.Oldach@Stollmann.DE (Helge Oldach)
To:        comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: ISDN (was Re: X.25 through tcp-ip)

lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:

|    My REAL gripe about ISDN (donning asbestos undershorts) is that I can't get
|    it where I need it...

Careful, guys - the Germans are listening. :-)

You actually *can* get ISDN lines where you need them - over here.

--
Helge.Oldach@Stollmann.DE                                   Fazer auf Betäubung!

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Nov 1993 10:40:03 GMT
From:      Helge.Oldach@Stollmann.DE (Helge Oldach)
To:        comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: ISDN (was Re: X.25 through tcp-ip)

jrg@rahul.net (John Galloway) writes:

| I was amazed when doing a contract in Munich that even the giant Siemens
| Nixdorf was until recently using uucp for email because a dedicated IP
| connection was to expensive due to the control of telecom by the government.
| I don't know the details, or if its changing, but just because ISDN is
| "available" may be a bit misleading.

You're mixing up facts here. Leased lines (which I suppose SNI was not using
for IP traffic for price reasons) are not ISDN. Leased lines in fact still are
expensive, but I can get a transparent 2B+D connection between home and work for
just $200 a month (no traffic charges).

--
Helge.Oldach@Stollmann.DE                                   Fazer auf Betäubung!

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Nov 1993 10:41:39 GMT
From:      mab@mdis.co.uk (Martin Bradford)
To:        comp.os.ms-windows.setup,comp.os.ms-windows.misc,comp.protocols.tcp-ip
Subject:   Re: Windows for Workgroups over TCP/IP

Michael S. Bendtsen (msbendts@mtu.edu) wrote:
: Bill Kress (kress@kentrox.com) wrote:
: >
: > As long as we're at it, IF it is possible to get WFW running on a TCP/IP
: > network (say, perhaps with a bunch of unix machines on it, or not...) what
: > would it take to get internet news and e-mail?  Would we have to use a
: > winsock-compatible mail/news reader or are these tools built in to
: > WFW.  Also, if there isn't a unix machine to hold the news, can the
: > WFW machines themselves take care of it?
: >
: > A little more than curious.
: >      Bill Kress.
 
: Yes, WfW can run concurrently with a TCP/IP network.  I have setup WfW and
: FTP Software's PC/TCP pacakge on my network without much of a hitch.  I am
: even using an outta date version of the PC/TCP package too (v2.05...they 
: are now up to v2.11)  As for getting winsock to work with it, I have not
: yet been successful, but I have also not tried the winsock.dll update that
: I just got yet either.  (FTP PC/TCP winsock.dll can be obatined at ftp.com)
: I might be SOL due to my version of FTP's package, but I have heard of others
: having no problems.
 
: As for having the PC doing the NNTP services...I don't know of any programs
: written to do that yet.
 
: Mike
: -- 
:  Mike Bendtsen                          msbendts@mtu.edu
:   CCLI Senior Technical Consultant      Windows Administrator
:   Michigan Technilogical University     Multiplatform Systems Integrator

I think you are misunderstanding the original question. As I understand it,
the question is if it is possible to run Windows for Workgroups using
TCP/IP as its underlying transport mechanism rather than just concurrent
with TCP. The native W4WG protocol is only really suitable for local area
networking as far as I can see but, if it can actually run OVER tcp, then
workgroups could span the world. This is something I have been looking for
for some time and I would also be interested in any answers.



-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Nov 1993 11:28:58 GMT
From:      dwight@hyphen.com (Dwight Ernest)
To:        comp.protocols.tcp-ip
Subject:   Re: Books on programming for TCP/IP ?

bob@sensorat.demon.co.uk (Bob Rowland) writes:

>Hi everybody,
>             Can anyone help this newbie and recommend any good books
>that cover developing software for SLIP and TCP/IP on UNIX or POSIX. Anything 
>in this area will be a great help.
>Can you please e-mail any info. to Bob@sensorat.demon.co.uk. 
>Thanks in advance.

Anything by Richard Stevens or Douglas Comer, especially Stevens'
UNIX Network Programming.

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Nov 1993 11:47:04 GMT
From:      leo@elmail.co.uk (E.J.Leoni-Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Address Translation Gateways

In article <752317245snz@peeras.demon.co.uk> proyse@peeras.demon.co.uk writes:
>In article <2arqnt$rge@cnj.digex.com> hand@cnj.digex.com writes:
>>
>>        I'm looking for pointers to information on IP address translation 
>>gateways.  Specifically, I'm looking for ways to allow Internet connectivity
>>as transparently as possible to a large IP network with non-NIC-assigned
>>IP addresses.  I was hoping that with the shortage of IP network numbers, 
>>there might already be some good solutions available to this problem.
>
>I've been looking into this one too, for about six months.
>You might not find much success, but please post any ideas or comments.
>
[... useful stuff deleted..]

It is conceptually quite simple to set up an application gateway, which 
solves ALL access problems at the expense of creating new ones.

What you do is have a set of server processes sitting on (not very well
known) sockets which are invoked by a set of (specially ported) applications
that connect TO the gateway.

I.e. your special Telnet when knows not to attempt to connect to
the host directly, but request a connect to the tthe gateway, which 
then does the real internet connection and simply passes packets
back and forth. The gateway would use the SOCKS code to drive 
two intefcaes - one private and one connected to the Internet.

The actual applications aren't a very big deal. 

Anyway, this was the way we determined it should be done. Unfortunately
this means proxy applications are needed inside the gateway. 

You pays your moneyt...

Oh - and we reckoned that a modest SPARC would be more than adequate 
to cope with a 64kbps Internet connection....

Leo


-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Nov 1993 11:51:54 GMT
From:      leo@elmail.co.uk (E.J.Leoni-Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS on the Macintoshes

In article <CFxAy5.9t6@Dunx1.OCS.Drexel.Edu> st92ebps@dunx1.ocs.drexel.edu (Kim Baxter) writes:
>I would like information on any companies *other than* Intercon who sell NFS    software for use on a Macintosh Ethernet network.  I also need to know what is
>involved in converting a LocalTalk network to Ethernet other than buying the
>Ethernet cards (or is that all I need to do?)

Do you _really_ need NFS/TCP-IP?

At least one company (Helios) make some excellent software which is basically
Appleshare on Unix (typically a Sparc) This allows full integration of
file and print resources between the Unix and MAC domains, and has a 
good terminal emulator and reasonable access to Unix E-mail services...

And yes, converting from localtalk IS just a question of plugging in
the Ethernet hardware and clicking on an Icon..:-)


>Finally, I am interested in providing dial-in access to remote users who want to access their Internet account which will be set up on this Mac network.  What  software does a remote user need, and can they use a PC (or dumb terminal) to   dial in to Internet which is on a Mac network?

Apple remote access should be all that is required - or am I missing something?

Leo


-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Nov 1993 13:17:52 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: ISDN (was Re: X.25 through tcp-ip)

In article <2b90oa$fus@pyrnova.mis.pyramid.com>, 
lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:

>   No, I knew I pushed that button.  The button was aimed at the
>   computer network types you mention....as well as those who
>   assume ISDN is a single layer and leave it at that.

Counting layers is a matter of definition. If you look in the 
I-standards, you'll see that B channels are in fact described
as a single "layer 1". D channels are described as layers 1, 2
and 3 (they are explicitly *not* named like the OSI layers,
just identified by their numerical designations). I believe 
that I.320 has a good figure illustrating this (I haven't got 
the recommendation at hand, so maybe the number is wrong).

Even though it takes three layers to get a bit end-to-end
in datagram-oriented networks, and a fourth layer to shape that
into a sequenced stream, does not imply that any other net
technology providing the same end result is a 4-layer protocol 
(no, I am not claiming that an ISDN B-channel is reliable, but 
it *is* end-to-end, and it *is* sequenced).
Switching a B channel is roughly the same as the function of a 
plug managed by human operators in pre-WW2 crossbar phone 
switches. You wouldn't consider that plug 4-layered, would you?

For B-ISDN, I have actually seen descriptions of everything
up to the AAL as "layer 1". Although the 1990 docs do identify
three layers (total 5 sublayers), you still need to run a number 
of OSI Link and Net functions on top of B-ISDN (and note that 
ISDN B channels will be provided on top of B-ISDN!). So
it sort of makes sense, from a practical point of view, to 
treat the 5 sublayers as being the Physical layer in the OSI
model, providing a virtual cable, but not much more (except
that it is end-to-end), even though it offloads the next couple
layers to some degree. So does a modem connection!

The idea of sublayers is not new. If you want to prove anything
about "too many layers", just start counting sublayers as if
they were full layers, and you might possibly construct a
stack with a 3-digit number of layers...

(My personal record in multiple layers: Our machine didn't have
an ethernet card - this was 7 years ago - but I wanted to 
ftp a file to a machine with ethernet connection only. I had to
do this via another machine that could talk to ours through an
X.25 switch, and also was on that ethernet. So my user data was
wrapped into an FTP envelope, into a TCP envelope, into an IP
envelope - ready for feeding into the ether. But then it was
wrapped into a proprietary transport envelope on the way to the
relaying machine. Then it was wrapped into X.25 PLP, then the
X.25 LAP-B and sent to the X.25 switch across a 9600 bps line.

Now comes the funny part: The X.25 switch was internally a 
distributed one, and ours and the relay machine was on different 
modules. These modules used an ethernet for exchanging packets,
so another set of net, link and physical ethernet envelopes were
wrapped around it. Guess which ethernet this was? Correct: the
same one as the destination machine was on. Unfortunately, my 
data was invisible under umpteen envelope layers. First, the
other X.25 switch module had to unwrap three of them, then the
relay machine unwrapped the LAP-B, X.25 PLP, and the proprietary 
transport envelope, leaving the TCP and IP ones but wrapping it 
in a 802.2 link and ethernet physical envelope before shipping it 
to its final destination...

FTP reported a throughput of 1.2E-6 bytes/sec for that transfer!)



-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Nov 1993 13:31:50 GMT
From:      etxmesa@eos.ericsson.se (Michael Salmon)
To:        comp.protocols.tcp-ip
Subject:   What does Telnet mean?

I was recently acsked by a collegue what Telnet meant. I had never
thought of it meaning anything but my guess was Telecomputing via
Internet. Does anyone have a better suggestion or even better the
actual meaning.

-- 

Michael Salmon

#include	<standard.disclaimer>
#include	<witty.saying>
#include	<fancy.pseudo.graphics>

Ericsson Telecom AB
Stockholm

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Nov 1993 13:41:22 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Help on large ethernet packets > 1500

In article <skaaric.4@ion.bpmf.ac.uk> skaaric@ion.bpmf.ac.uk (Robert Clark) writes:
> I have install fergie and from that display it seems that under these
> conditions the packet size distribution shows 50% > 1500.
> What does this mean? 
> Is this the cause of my problem? 
> If there is a problem host how do I identify it? 

Oversize packets on an Ethernet are definitely a real problem,
especially if you have as many as you report.  

The usual cause for this is some sort of Ethernet--FDDI bridge (such
bridges are more or less always a bad idea) which is taking an FDDI
packet that is too large for Ethernet and sending it out anyway.
Connections between Ethernet and FDDI should almost always be via a
router.

Ran
atkinson@itd.nrl.navy.mil


-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 1993 12:02:52 +0100
From:      urlichs@smurf.sub.org (Matthias Urlichs)
To:        comp.protocols.tcp-ip
Subject:   Re: Extensive use of PUSH on large network, feasible ?

In comp.protocols.tcp-ip, article <CFv2HF.H4@sci.kun.nl>,
  albertk@cs.kun.nl (Albert Koppes) writes:
> In an application we are planning the use of
> the TCP PUSH mechanism to implement a kind
> of message boundary keeping, and to
> avoid applications to implement this.
> 
You can't. You have to pass the message size in a fixed-size message header 
or similar.

-- 
What am I doing out of bed?
-- 
Matthias Urlichs        \ XLink-POP Nürnberg   | EMail: urlichs@smurf.sub.org
Schleiermacherstraße 12  \  Unix+Linux+Mac     | Phone: ...please use email.
90491 Nürnberg (Germany)  \   Consulting+Networking+Programming+etc'ing      42

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Nov 1993 13:51:38 GMT
From:      ben@piglet.cr.usgs.gov (Ben A. Mesander)
To:        comp.os.ms-windows.setup,comp.os.ms-windows.misc,comp.protocols.tcp-ip
Subject:   Re: Windows for Workgroups over TCP/IP


   Michael S. Bendtsen (msbendts@mtu.edu) wrote:
   : Yes, WfW can run concurrently with a TCP/IP network.  I have setup WfW and
   : FTP Software's PC/TCP pacakge on my network without much of a hitch.  I am
   : even using an outta date version of the PC/TCP package too (v2.05...they 
   : are now up to v2.11)  As for getting winsock to work with it, I have not
   : yet been successful, but I have also not tried the winsock.dll update that
   : I just got yet either.  (FTP PC/TCP winsock.dll can be obatined at ftp.com)
   : I might be SOL due to my version of FTP's package, but I have heard of others
   : having no problems.

Have you been able WFWG to use NFS drives mounted with PC/TCP's idrive?
I can make NFS work under DOS, and under regular windows, but under wfwg,
file manager shows no files on NFS-mounted drives. I really would like to
make this work, so I can get rid of dpci/Domain OS on my network, and
replace them with NFS/UNIX type stuff, which will make maintaining my
network easier.

If you post, please reply to me via email also; I rarely have time to read
news. Thanks...

--Ben

--
I think signatures are stupid, but the US Geological Survey requires that I
have a ``disclaimer'' informing you that I am not an official US government
spokesdroid.
--
--
I think signatures are stupid, but the US Geological Survey requires that I
have a ``disclaimer'' informing you that I am not an official US government
spokesdroid.

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Nov 1993 15:16:41 GMT
From:      leo@elmail.co.uk (E.J.Leoni-Smith)
To:        comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: ISDN (was Re: X.25 through tcp-ip)

In article <CFyqKH.JGp@Stollmann.DE> Helge.Oldach@Stollmann.DE (Helge Oldach) writes:
>lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:
>
>|    My REAL gripe about ISDN (donning asbestos undershorts) is that I can't get
>|    it where I need it...
>
>Careful, guys - the Germans are listening. :-)
>
>You actually *can* get ISDN lines where you need them - over here.

Excellent. I need some over there (or I hope I will) :-)

How much do they cost, and what do you get?

i.e. in UK 400 uk pounds buys you 2x64k channels and ongoing rental is
(can't remember). 

Penetration in UK is reasonably good provided the local exchange is digital.

also, what ISDN Ethernet bridges are available and approved in
merry olde Deustchland?



Leo


-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Nov 1993 16:06:09 GMT
From:      skaaric@ion.bpmf.ac.uk (Robert Clark)
To:        comp.protocols.tcp-ip
Subject:   Help on large ethernet packets > 1500

Hello.
I have an ethernet with about 60 hosts (Suns,PCs, Macs) with a variety
of protocols (tcp, nfs, lat, decnet, netbeui, ipx but not appletalk).
Recently everything seems to drag on a sporadic basis. The jam/collision
led on the nearest repeater to me doesnt come on, but the receive light
is hammering away when this happens. 
I have install fergie and from that display it seems that under these
conditions the packet size distribution shows 50% > 1500.
What does this mean? Is this the cause of my problem? If there is
a problem host how do I identify it? Finally I would be grateful if
someone could tell me if there is a user guide for fergie.
Thanking in advance.

Robert Clark

--------------------------------------------------------------------------
skaaric@ion.bpmf.ac.uk  Robert Clark,             Robert Clark
                        Joint Computer Unit,      Joint Computer Unit,
Tel +44 71 836 3611     Institute of Child Health,Institute of Neurology,
           ext 4147     University of London,     University of London,
    +44 71 242 9789     30 Guilford Street,       Queen Square,
           ext 2624     London,   WC1N 1EH        London, WC1N 3BG
--------------------------------------------------------------------------

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 1993 17:12:05 GMT
From:      okorf@netcs.com (Oliver Korfmacher)
To:        comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: ISDN (was Re: X.25 through tcp-ip)

In article <CFz3rv.7tJ@elmail.co.uk>, leo@elmail.co.uk (E.J.Leoni-Smith) writes:
<> In article <CFyqKH.JGp@Stollmann.DE> Helge.Oldach@Stollmann.DE (Helge Oldach) writes:
<> >lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:
<> >
<> >|    My REAL gripe about ISDN (donning asbestos undershorts) is that I can't get
<> >|    it where I need it...
<> >
<> >Careful, guys - the Germans are listening. :-)
<> >
<> >You actually *can* get ISDN lines where you need them - over here.
<> 
<> Excellent. I need some over there (or I hope I will) :-)
<> 
<> How much do they cost, and what do you get?
<> 
<> i.e. in UK 400 uk pounds buys you 2x64k channels and ongoing rental is
<> (can't remember). 
<> 
<> Penetration in UK is reasonably good provided the local exchange is digital.
<> 
<> also, what ISDN Ethernet bridges are available and approved in
<> merry olde Deustchland?
We prefer IP (or other) routeing here in Deutschland :-)

Use ppp over isdn!

	Oliver
<> 
<> 
<> 
<> Leo
<> 

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 1993 18:15:22 GMT
From:      d3e260@charis. (B Kissinger)
To:        comp.protocols.tcp-ip
Subject:   SLIP for NT

Is anyone aware of commercial or public domain SLIP drivers for Windows NT?






-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 1993 18:19:11 GMT
From:      bhatiani@jpmorgan.com (Amit Bhatiani,Amit,16/30B,59383,)
To:        comp.protocols.tcp-ip
Subject:   New book on Gigabit Networking by Craig Partridge

Hi all:

There is a great new book by Craig Partridge on Gigabit Networking. I just happened
to see it on the shelves at the neighborhood bookstore. Run out and get it...:-)

--- amit

P.S. I have no relation to Craig Partridge or Addison Wesley (the publisher).
___________________________________________________________________
Amit Bhatiani				     bhatiani@jpmorgan.com
     These opinions are my own, your mileage may vary.


-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 1993 04:16:23 -0500
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Finding hop-counts

In article <SHIRONO.93Oct31160905@gcx1.ssd.csd.harris.com> shirono@ssd.csd.harris.com writes:
>The Berkeley routing table does not keep hop counts.  They are irrelevant
>to actual packet routing.  Hop counts are relevant only to distance-vector
>routing protocols, such as RIP.  Berkeley's routed(8) implements RIP.

If the kernel doesn't store this information, why does the route command
require a metric argument?  What does it do with it?

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 93 20:40:04 GMT
From:      yan@orion.oac.uci.edu (Yan Or)
To:        comp.protocols.tcp-ip
Subject:   RARP server

We are implementing RARP on our manageable hubs.
We would like to know i there exists any commercially
available RARP server implementations for DOS/Windows,
OS/2, or UNIX (Sun).  We need a RARP server!

thanks in advance,
Yan Or
COMPEX, Inc.
(714) 630-7302 ext. 145


-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 1993 22:44:51 GMT
From:      csch@netcs.com (Clemens Schrimpe)
To:        comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: ISDN (was Re: X.25 through tcp-ip)

In article <CFxzIF.GID@rahul.net>, jrg@rahul.net (John Galloway) writes:
[...]
<> Yes but you need to be careful about what you mean by "it", if your using
<> ISDN for IP, I was amazed when doing a contract in Munich that even the
<> giant Siemens Nixdorf was until recently using uucp for email because a
<> dedicated IP connection was to expensive due to the control of telecom by the
<> government. I don't know the details, or if its changing, but just because
<> ISDN is "available" may be a bit misleading.
[...]
It would be definitely against the Netiquette to tell, what I really think of some (!!!) SNI guys :-| :-| :-|

Fact is (and ever was), that ISDN connections in Germany *ALWAYS* cost the same
as a usual (POTS) telephone call to the same destination. Therefore it COULDN'T
BE more expensive than using modems. Because of the higher speeds it is even 
cheaper, since you get your news/mail stuff done in less time.
The ONLY difference is the base fee (DM 74,- (to become DM 69,- next month) for
an ISDN BRI (two unrestriced B channels) vs. DM 42,- for two analog lines),
but as a usual UseNet site it just takes a couple of days to recap the difference through savings in x-mission times.

I know, that there are countries, the PTT monopolies are abused to charge unreasonable prices; I heard in France DATA calls are charged twice the amount of VOICE calls - allthough both use the VERY SAME equipment and resources.
(Therefore some people use the VOICE BC for data calls :-)

Greetings,

	Clemens
--
INTERNET:  csch@netcs.com        WWW:    http://www.netcs.com/PEOPLE/csch.html
PHONE:     +49-30-856 999-0      FAX:    +49-30-855 52 18

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 1993 22:59:00 GMT
From:      csch@netcs.com (Clemens Schrimpe)
To:        comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: ISDN (was Re: X.25 through tcp-ip)

In article <CFz3rv.7tJ@elmail.co.uk>, leo@elmail.co.uk (E.J.Leoni-Smith) writes:
[...]
<> also, what ISDN Ethernet bridges are available and approved in
<> merry olde Deustchland?
I haven't seen much (in fact "any" :-) of these over here. IP and IPX routers
are much more popular over here (or packet drivers fro ISDN boards).

	Clemens

--
INTERNET:  csch@netcs.com        WWW:    http://www.netcs.com/PEOPLE/csch.html
PHONE:     +49-30-856 999-0      FAX:    +49-30-855 52 18

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Nov 1993 23:04:13 GMT
From:      ag995@Freenet.carleton.ca (Marwan Forzley)
To:        comp.protocols.tcp-ip
Subject:   URGENT /BROADCASTING


I need to setup a broadcast message server that will do the folloing
1- Broadcast messages to all clients that are connected to the message server.
2- Broadcast messages to all clients who can access the server but not connected 
   at the time when the broadcast was done. Hence if the server sends a message 
   to client A , Client B and Client C, but only client A was connected,  then
   client A will receive the message and client B and Client C will receive the 
   message as soon as they logon to the server. 

Can I do this using TCP/IP by specifying the socket type to be BROADCAST. Or is 

there another protocol that is especially designed for broadcasting. 
I would appreciate it if somebody can help me on that because I cant find any
reference on broadcasting in the communication manuals that i have.

Thanks
-- 
******************************************************************
***                                                            ***
***                           MARWAN                           ***
***                     ag995@freenet.carleton.ca              ***

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Nov 1993 00:34:12 GMT
From:      thomas@datamark.co.nz (Thomas Beagle)
To:        comp.os.ms-windows.setup,comp.os.ms-windows.misc,comp.protocols.tcp-ip
Subject:   Re: Windows for Workgroups over TCP/IP

In article mab@mdis.co.uk (Martin Bradford) writes:
>: Bill Kress (kress@kentrox.com) wrote:
>: >
>: > As long as we're at it, IF it is possible to get WFW running on a TCP/IP
>: > network (say, perhaps with a bunch of unix machines on it, or not...) what
>: > would it take to get internet news and e-mail?  Would we have to use a
>: > winsock-compatible mail/news reader or are these tools built in to
>: > WFW.  Also, if there isn't a unix machine to hold the news, can the
>: > WFW machines themselves take care of it?
>
>I think you are misunderstanding the original question. As I understand it,
>the question is if it is possible to run Windows for Workgroups using
>TCP/IP as its underlying transport mechanism rather than just concurrent
>with TCP. The native W4WG protocol is only really suitable for local area
>networking as far as I can see but, if it can actually run OVER tcp, then
>workgroups could span the world. This is something I have been looking for
>for some time and I would also be interested in any answers.

Well, I just (five minutes ago) returned from a client's site that is
doing exactly that.

They have LanManager running on the HPUX box with an ethernet
consisting of LanManager clients, all using TCP/IP as the transport.

We removed LanManager from one of the machines and installed WfWG 3.11
and the TCP/IP upgrade that you could get for WfWG 3.10.

This then happily connected to the LanManager server, transferred
files, etc, etc. (Well, there a few niggly problems but nothing
major.)

Then, using the WinSock that's part of WfWG TCP/IP we installed
WinQVTNet 3.94 for WinSock on the client PC. This then gives them
Telnet, Mail, News, etc, etc.

Not a Netbeui in sight...

-- 
   Thomas Beagle |    ,__o    Faster and faster until the thrill of speed 
Technical Writer |  _-\_<,    overcomes the pain of long ears flapping
  Wellington, NZ | (*)/'(*)   in the wind.          thomas@datamark.co.nz

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Nov 1993 01:21:43 GMT
From:      ishwar@sol.cs.wmich.edu (Ishwar Rattan)
To:        comp.protocols.tcp-ip
Subject:   Help with TCP + socket programming


Hello
	I am teaching a course on computer networks using the
well known book "Unix network programming" by Stevens. I need
some help regarding setting up a dual TCP socket connection in
the same style as done by FTP. I have not been able to figure
it out and a plea for HELP from some kind and knowledgable
soul in this group. 

	The scenario in the code given below: -- The client
does a connect to server. Next opens a new socket, binds the same
address to the new socket and does an accept for server to connect
on the new socket. The client blocks on accept correctly. The server
does a bind and accept so that client can connect to it. Next
it opens a new socket and then binds a new address (same host
but different port #) to it. It tries a connect to client (using
the information returned by accept call). Some how the connect
always fails :-(

Any help will be appreciated. Please respond by e-mail.

The code that I tried under SunOS is given below.

- ishwar
--------------cut----
/*
 * Definitions for TCP and UDP client/server programs.
 */

#include	<stdio.h>
#include	<sys/types.h>
#include	<sys/socket.h>
#include	<netinet/in.h>
#include	<arpa/inet.h>

#define MY_TCP_PORT     5100
#define	SERV_UDP_PORT	5134
#define	SERV_TCP_PORT	5134
#define	SERV_HOST_ADDR	"141.209.20.80"	/* host addr for server */
#include "inet.h"

============
print(addr)
struct sockaddr_in addr;
{
   char *id;  u_short port;

   id = inet_ntoa(addr.sin_addr);
   port = ntohs(addr.sin_port);
   printf("id: %s, port: %u\n", id, port);
}

==============
/* this prints the error message 'reason' and aborts the
   process with error exit 1.
 */

#include <stdio.h>

serr(reason)
char *reason;
{
    fprintf(stderr, "%s\n", reason);
    exit(1);
}

================
/*
 * Example of client using TCP protocol.
 */

#include	"inet.h"


main()
{
	int			anylen, on = 1, sockfd, nsfd, ssfd;
	struct sockaddr_in	myaddr, serv_addr, anyaddr;


	/*
	 * Fill in the structure "serv_addr" with the address of the
	 * server that we want to connect with.
	 */

	bzero((char *) &serv_addr, sizeof(serv_addr));
	serv_addr.sin_family      = AF_INET;
	serv_addr.sin_addr.s_addr = inet_addr(SERV_HOST_ADDR);
	serv_addr.sin_port        = htons(SERV_TCP_PORT);

	/* fill myaddr with local info */
	bzero((char *) &myaddr, sizeof(myaddr));
	myaddr.sin_family      = AF_INET;
	myaddr.sin_addr.s_addr = inet_addr(SERV_HOST_ADDR);
	myaddr.sin_port        = htons(MY_TCP_PORT);

	/*
	 * Open a TCP socket (an Internet stream socket).
	 */
	if ( (sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0)
		serr("client: can't open stream socket");

	/* bind to local address myaddr */
	if(bind(sockfd, (struct sockaddr *)&myaddr, sizeof(myaddr)) < 0)
		serr("client: can't bind to local address..");

	/* print myaddr info */
	print(myaddr);

	/* get local info via getsockname() */
	anylen = sizeof(anyaddr);
	if (getsockname(sockfd, (struct sockaddr *)&anyaddr, &anylen) < 0)
		serr("client: getsockname failed..");
	

	/*
	 * Connect to the server.
	 */

	if (connect(sockfd, (struct sockaddr *) &serv_addr,
					sizeof(serv_addr)) < 0)
		serr("client: can't connect to server");

	str_cli(sockfd);		/* do it all */



	/* open another socket to bind */
	if ((ssfd = socket(AF_INET, SOCK_STREAM, 0)) < 0)
		serr("client: can't open new socket..");

	/* set SO_REUSEADDR option on socket */
	if (setsockopt(ssfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on)) < 0)
		serr("client: SO_REUSEADDR option set error..");

	if (bind(ssfd, (struct sockaddr *)&myaddr, sizeof(myaddr)) < 0)
		serr("client: bind failed-1..");

	/* see if accept works on the socket */
	if (listen(ssfd, 5) < 0) serr("client: listen error..");

	anylen = sizeof(anyaddr);
	if ((nsfd = accept(ssfd, (struct sockaddr *)&anyaddr, &anylen)) < 0)
		serr("client: accept failed..");

	/* print the info in anyaddr */
	print(anyaddr);

	if (close(sockfd) < 0)
		serr("client: socket close error");
	exit(0);
}

===================
/*
 * Example of server using TCP protocol.
 */

#include	"inet.h"

main()
{
	int			ssfd, sockfd, newsockfd, clilen, childpid;
	struct sockaddr_in	cli_addr, serv_addr, clsraddr;


	/*
	 * Open a TCP socket (an Internet stream socket).
	 */

	if ( (sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0)
		serr("server: can't open stream socket");

	/*
	 * Bind our local address so that the client can send to us.
	 */

	bzero((char *) &serv_addr, sizeof(serv_addr));
	serv_addr.sin_family      = AF_INET;
	serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
	serv_addr.sin_port        = htons(SERV_TCP_PORT);

	if (bind(sockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0)
		serr("server: can't bind local address");

	if (listen(sockfd, 5) < 0)
		serr("server: listen error");


	while(1) {

		clilen = sizeof(cli_addr);
		newsockfd = accept(sockfd, (struct sockaddr *) &cli_addr,
					     &clilen);
		if (newsockfd < 0)
			serr("server: accept error");
		
		/* print client info */
		print(cli_addr);

			str_echo(newsockfd);
		
		/* fill up the new port for binding */
		serv_addr.sin_addr.s_addr = inet_addr(SERV_HOST_ADDR);
		serv_addr.sin_port    = htons(SERV_TCP_PORT + 1);

		print(serv_addr);

		/* open another socket */
		if ((ssfd = socket(AF_INET, SOCK_STREAM, 0)) < 0)
			serr("server: can't open new socket..");

		/* bind to serv-addr */
		if (bind(ssfd, (struct sockaddr *)&serv_addr, sizeof(serv_addr)) < 0)
			serr("server: bind failed-1..");

		/* connect to former client */
		if (connect(ssfd, (struct sockaddr *)&cli_addr, sizeof(cli_addr)) < 0)
			serr("server: connect failed..");
		print(cli_addr);

		if (close(newsockfd) < 0)
			serr("server: socket close error-1");
	}
}
 --------cut----

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Nov 1993 01:48:28 GMT
From:      dmb@synoptics.com (David Brady)
To:        comp.protocols.tcp-ip
Subject:   Sun server mac addresses

				 A SUN server has 2 ethernet ports, A and B, and each is 
				 configured to its own unique subnet, and given that a SUN
				 server uses the same ethernet MAC address on both ports
				 A and B, Theoretically speaking, if somehow port A was to
				 receive a frame that was really destined to port B, that
				 is, the frame contains port B's IP destination address,
				 will port A forward the frame to the application layer or
				 will it simply drop the frame because the subnet doesn't
				 match?

				 Furthermore, if the application layer does receive the frame
				 will it respond out port A or port B with its response?
				 
Keywords: IP, SUBNET



-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 93 08:17:37 CST
From:      hens@cray.com (Tom Stephens)
To:        comp.protocols.tcp-ip
Subject:   Re: Routers in parallel

In article 93Nov2141352@btzp09.bits.alcbel.be, mcla@bits.alcbel.be (CLAEYS Marc) writes:
>Hi all,
>
>
>Consider the next configuration :
>
>Two lan's : LAN1 and LAN2.
>On each lan 2 hosts : HOST11 and HOST12 on LAN1
>		      HOST21 and HOST22 on LAN2
>
>Two routers in parallel between LAN1 and LAN2: R1 and R2, viz:
>
>
>	+--------+      +--------+
>	| HOST21 |      | HOST22 |
>	+----+---+      +----+---+
>	     |               |
>	     |               |
>	    -+---------------+-  LAN2
>	     |               |
>	     |               |
>	+----+---+      +----+---+
>	|   R1   |      |   R2   |
>	+----+---+      +----+---+
>	     |               |
>	     |               |
>	    -+---------------+-  LAN1
>	     |               |
>	     |               |
>	+----+---+      +----+---+
>	| HOST11 |      | HOST12 |
>	+--------+      +--------+
>
>
>	On HOST21
>	route add HOST11 R1 1
>	route add HOST11 R2 1
>	route add HOST12 R1 1
>	route add HOST12 R2 1
>
>	On HOST22
>	route add HOST11 R1 1
>	route add HOST11 R2 1
>	route add HOST12 R1 1
>	route add HOST12 R2 1
>
>	On HOST11
>	route add default R1 1
>	or
>	route add default R2 1
>
>	On HOST12
>	route add default R2 1
>		or
>	route add default R1 1
>
>Given that all connections are initiated by HOST11 or
>HOST12 (i.e. hosts on LAN1), has the configuration above
>any chance to work? Why (not?).


It has every chance of working although not as you have described.  On the hosts, you need to run some dynamic routing program like gated, routed or GDP (gateway discovery proto.)  We use this configuration extensivly here and it works great for the machines that can do dynamic routing.  It doesn't really do any good to add a default route unless you want to manualy change it when the router you point at goes down.  We use Cisco routers and they do "load sharing" on the interfaces in common. 


A side note.  RIP is not a very good protocol for this.  It does work, but more intelligence  is needed to pick the best path.   

---------------------------------
Tom Stephens
Corporate Computing and Networks, Chippewa Falls, WI
Cray Research Inc.  hens@cray.com


-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Nov 1993 03:02:29 GMT
From:      dmb@synoptics.com (David Brady)
To:        comp.protocols.tcp-ip
Subject:   Sun server mac addresses

        I'm trying to find the answer to a very simple problem.

        A SUN server has 2 ethernet ports, A and B, and each is 
        configured to its own unique subnet, and given that a SUN
        server uses the same ethernet MAC address on both ports
        A and B, Theoretically speaking, if somehow port A was to
        receive a frame that was really destined to port B, that
        is, the frame contains port B's IP destination address,
        will port A forward the frame to the application layer or
        will it simply drop the frame because the subnet doesn't
        match?
        
        Furthermore, if the application layer does receive the frame
        will it respond out port A or port B with its response?
				 
Keywords: IP, SUBNET



-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 93 12:49:21 PST
From:      lui@davidsys.com
To:        comp.protocols.tcp-ip
Subject:   TFTP public domain source code

Does anyone know where can I get the public domain source code for TFTP.
Please indicate the exact directory path. Thanks in advance.

Michael


-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 1993 13:29:59 -0500
From:      shirono@gcx1.ssd.csd.harris.com (Roberto Shironoshita)
To:        comp.protocols.tcp-ip
Subject:   Re: Finding hop-counts

In article <9311050916.AA26437@gandalf.think.com> Barry Margolin <barmar@Think.COM> writes:
> In article <SHIRONO.93Oct31160905@gcx1.ssd.csd.harris.com> shirono@ssd.csd.harris.com writes:
> >The Berkeley routing table does not keep hop counts.  They are irrelevant
> >to actual packet routing.  Hop counts are relevant only to distance-vector
> >routing protocols, such as RIP.  Berkeley's routed(8) implements RIP.
>
> If the kernel doesn't store this information, why does the route command
> require a metric argument?  What does it do with it?

The pre-Net2 (as late as 4.3 Tahoe) route(8) command uses the metric
argument to decide whether the specified route goes through a gateway or
not.  The Net2 route command (at least the one in 4.3 Reno) does something
else that I haven't quite figured out.

On taking a closer look, it seems that the 4.3 Reno networking code has
some metric info in its route entry, but I don't know that it is used
internally by the kernel.

At any rate, in the absence of route metrics in the table, the kernel
simply takes the first route it finds.  The route daemons are the ones that
use the metrics to decide whether to change a route or not.

     Roberto Shironoshita      ||   Internet: shirono@ssd.csd.harris.com
      Harris Corporation       ||
   Computer Systems Division   ||   UUCP: ...!uunet!ssd.csd.harris.com!shirono
                               ||
DISCLAIMER: The opinions expressed here are my own; they in no way reflect the
            opinion or policies of Harris Corporation.

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Fri, 05 Nov 1993 20:28:34 -0800
From:      wcheung@sdcc13.ucsd.edu (Wilson Cheung)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for sendmail/SMTP formats.

In article <1993Nov2.195120.3485@ohstpy.mps.ohio-state.edu>,
glazer@ohstpy.mps.ohio-state.edu (JON GLAZER) wrote:

> I am looking for some good documentation on all the sendmail/smtp 
> address headers.  I am talking about the headers found in a given email
> message that can be utilized on most systems.  Now I was once told to
> get RFC221 and I looked all over and all the major sites that cary 
> thousands of RFCs that I've found don't have this one.
> 
> Is there a newer/better document for this?  Where can I  get it?

Try taking look at RFC821 and RFC822.


They are available via anonymous FTP from:

ds.internic.net:/rfc/rfc821.txt
ds.internic.net:/rfc/rfc822.txt

-- 
Wilson Cheung
wcheung@sdcc13.ucsd.edu

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 1993 16:12 -0500
From:      gharpure@vtpwr1.psl.ee.vt.edu (Vasudev Gharpure)
To:        comp.protocols.tcp-ip
Subject:   Help: Network application

Hi

        I have an application wherein I must send data (1-2 Kbytes) 
continuously (every few seconds) from a PC(486, with a 3Com Etherlink III 
card) to a Sun sparcstation. This could go on for a few minutes at a time. 
The machines are practically sitting next to each other and are directly 
connected to each other over the ethernet by crossed over twisted pair.

    On the PC, I could use ftp in a batch file thus:

        a) applic.exe ---saves data file
        b) ftp the file
        c) loop back to a)

    (We will have everything on a ramdisk and save on disk access time)

    However, it seems to be a waste to load the .exe files and open/close 
the connection each time. I think this will also slow down the process 
somewhat.

Now the questions:

1) Is it possible to write an application using socket calls etc to open 
a connection and keep it open while the application gathers data and sends 
it as stream/packet/datagram/whatever on the PC?

(Of course, I would need a matching program on the Sun to collect the data 
at the other end.)

If yes to 1) above, then:

2) Is there a socket library or some such available, either free or 
commercially? I would prefer to code in C on the PC, but assembly would be 
just fine.

    I am not sure if I have asked the right questions. Any advice, hints, 
suggestions, flames, friendly advice for my own good etc.etc. welcome.

Vasudev Gharpure
gharpure@power.psl.ee.vt.edu

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 93 14:13:03 CDT
From:      rsl11@kuhub.cc.ukans.edu
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   WinQVTNet 3.93 Bug and X-term Emulation

Hello there,

	I am facing some problems with WinQVT/Net version 3.94 and I am
wondering whether anybody else has had the same experience or had any ideas on
what the problem might be.

	After I load WinQVT/Net and work for some time, especially when I copy
and paste quite a bit with the mouse, while I am typing the letters start
showing up as capital letters. After I press the capsLock key the lowercase
is reversed. Also, when I type "." character ">" appears, when I type ","
character "<" appears, for ";" ":" appears etc. In other words, what  happens
is that the effect is as if I was pressing the shift key. If I press the shift
key though nothing happens. Also, if I go to any editor or wordprocessor and I
move the arrow key then text is selected, i.e. it has the same effect as if I
am pressing the shift key. If I continue typing on a QVTnet session for a while
the problem disappears.

Questions:

1. Has anybody experienced any problem of that sort? It seems to me that there
is a small portion of memory that QVTnet tries to use and interferes with
Windows 3.1? Do you think it might be interfering with the vga.drv? I once got
a crash because of that. That happened only once and no more again. also after
I start typing for quite some time the fonts of QVTnet become screwed up and
after a while the problem goes away. So it might be a problem with the fonts
maybe....
	These are my comments. I would appreciate anybodies ideas.


	The second question that I have is that if QVTNet is able to provide
support for X-term emulation. In other words, if you have a program that
emulates X-windows could you use QVTNet to provide TCP/IP support? Can both
versions of QVT the Windows SOcket and the packet driver version provide
support for X-Windows?


	I would appreciate any relevant response.


Thanks, Chris

Please E-mail: rsl11@kuhub.cc.ukans.edu

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 93 16:48:40 CDT
From:      rsl11@kuhub.cc.ukans.edu
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   WinQVTNet 3.93  problem with the rcp command

Hello there,

	I have a problem using the rcp command of the WinQVT/Net 3.93. I can
transfer files(copy a file) from my machine running QVT to a remote machine
running BSD Unix but I cannot do the opposite, i.e. I cannot copy files
that reside on my PC to the remote UNIX machine however. I thouhg that maybe
the permissions on the remote Unix machine were the problems but I tried
enabling  all permissions in other words, I gave permissions to all users
to read and write to my directory but still no success. I have no password
file implemented and in my qvtnet.acl file the directory I am trying to access
is not listed and therefore I have no restrictions.

	Can anyone provide any useful information regarding the rcp command?
I would appreciate any relevant information concerning the rcp utility of QVT.

	Thnaks, Chris

Please E-mail: rsl11@kuhub.cc.ukans.edu

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 1993 13:30:15 GMT
From:      jbrady@deepriver.East.Sun.COM (John Brady - SunNetworks Consultant)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP server

Sun's come with software that enables them to act as RARP servers.

Refer to your "Administering TCP/IP and UUCP" manual that comes with all
Solaris releases.  For the Solaris 2.2 release (SunOS 5.2), a description of
how to configure bootp as a RARP server appears on page 50.

John Brady
Network Management Consultant
SunNetworks, A Sun Microsystems, Inc. Business
(703) 204-4859
john.brady@East.Sun.Com


-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 1993 13:42:30 GMT
From:      lsimon@kuht.uh.edu
To:        comp.os.ms-windows.setup,comp.os.ms-windows.misc,comp.protocols.tcp-ip
Subject:   Re: Windows for Workgroups over TCP/IP

In article <2b9jv9$3vm@maxwell13.ee> msbendts@mtu.edu (Michael S. Bendtsen) writes:
>Bill Kress (kress@kentrox.com) wrote:
>>
>> As long as we're at it, IF it is possible to get WFW running on a TCP/IP
>> network (say, perhaps with a bunch of unix machines on it, or not...) what
>> would it take to get internet news and e-mail?  Would we have to use a
>> winsock-compatible mail/news reader or are these tools built in to
>> WFW.  Also, if there isn't a unix machine to hold the news, can the
>> WFW machines themselves take care of it?
>>
>
>Yes, WfW can run concurrently with a TCP/IP network.  I have setup WfW and
>FTP Software's PC/TCP pacakge on my network without much of a hitch.  I am
>even using an outta date version of the PC/TCP package too (v2.05...they 
>are now up to v2.11)  As for getting winsock to work with it, I have not
>yet been successful, but I have also not tried the winsock.dll update that
>I just got yet either.  (FTP PC/TCP winsock.dll can be obatined at ftp.com)
>I might be SOL due to my version of FTP's package, but I have heard of others
>having no problems.
>
>As for having the PC doing the NNTP services...I don't know of any programs
>written to do that yet.
>

We have gotten WFW to run just fine with such TCP-IP & Internet-related stuff: Trumpet's Sockets, QVTNET 3.94, Trumpet's News and several other applications. It will probably be taking the place of the packet-driver versions of these applications, which took the place of Wollongong's crummy Pathway Access.

Anyone know how to get QVTNET 3.94 to switch keyboard maps on the fly?

  __
 /  \  "Give me toast or give me death!"
 >--<  Laurence Simon, lsimon@kuht.uh.edu, KUHT - Houston Public Television
 \__/  [*** ******* **** ******* ***.]             

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Nov 1993 13:49:13 GMT
From:      mab@mdis.co.uk (Martin Bradford)
To:        comp.os.ms-windows.setup,comp.os.ms-windows.misc,comp.protocols.tcp-ip
Subject:   Re: Windows for Workgroups over TCP/IP

Thomas Beagle (thomas@datamark.co.nz) wrote:

: Well, I just (five minutes ago) returned from a client's site that is
: doing exactly that.
 
: They have LanManager running on the HPUX box with an ethernet
: consisting of LanManager clients, all using TCP/IP as the transport.
 
: We removed LanManager from one of the machines and installed WfWG 3.11
: and the TCP/IP upgrade that you could get for WfWG 3.10.
 
: This then happily connected to the LanManager server, transferred
: files, etc, etc. (Well, there a few niggly problems but nothing
: major.)
 
: Then, using the WinSock that's part of WfWG TCP/IP we installed
: WinQVTNet 3.94 for WinSock on the client PC. This then gives them
: Telnet, Mail, News, etc, etc.
 
: Not a Netbeui in sight...
 
: -- 
:    Thomas Beagle |    ,__o    Faster and faster until the thrill of speed 
: Technical Writer |  _-\_<,    overcomes the pain of long ears flapping
:   Wellington, NZ | (*)/'(*)   in the wind.          thomas@datamark.co.nz

Thomas,
	Can we just clarify this because it sounds like it might be what
we are looking for. Are you saying if you have two lans set up as you
describe and each of them were gated into the Internet (as we are) then
workstations on one lan could make use of the W4WG facilities (e.g. Clipbook,
distributed DDE etc) to workstations on the other lan (possibly on the other
side of the world)? You only mention file transfer to/from the server which
is not the same thing at all.

	I know that it is quite easy to make W4WG coexist with tcp - we run
like that all the time, but we would like to be able to interact with
workgroups all over this country (or the rest of the world).

Regards,

	Martin Bradford.


-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Nov 1993 15:25:08 GMT
From:      grante@hydro.rosemount.com (Grant Edwards)
To:        comp.sys.ibm.pc.misc,comp.protocols.tcp-ip
Subject:   Re: X-Windows Emulator for PC,Public Domain or Shareware

rsl11@kuhub.cc.ukans.edu wrote:

: I would like to know if there is any public domain or Shareware or
: low price software program for the PC that allowss you to emulate
: X-Windows for the PC. If there are some public domain please let me
: know whare I could find them.  Also, if you could have a comparison
: of all the availble packeges that would be great.

I'm not sure what you mean by "emulate X-Windows."

If you want to run X on a PC, that's available for free.  You can run
X11R5 under Linux or one of the free BSD releases.  These are all
available at no charge from various ftp sites.  You can also get them
on CD for a nominal charge ($30 - $50).  If you are interested I can
send you the Linux and Xfree86 FAQs.

If you are looking for an X server that runs under DOS, I'm not aware
of anything that's freely available.

I've run a couple different X servers under DOS as well as running X
under Linux.  The latter is way easier and cheaper IMHO.

You might want to read the groups comp.windows.x.i386unix or
comp.windows.x.

--
Grant Edwards                                 |Yow!  On SECOND thought,
Rosemount Inc.                                |maybe I'll heat up some BAKED
                                              |BEANS and watch REGIS
grante@rosemount.com                          |PHILBIN..  It's GREAT to be
                                              |ALIVE!!

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Nov 1993 16:15:42 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: Finding hop-counts

Barry Margolin (barmar@think.com) writes:
> [...] shirono@ssd.csd.harris.com writes:
> > The Berkeley routing table does not keep hop counts.
  
    This is correct.

> > They are irrelevant to actual packet routing.

    This is incorrect, with respect to BSD's implementation.

> If the kernel doesn't store this information, why does the route command
> require a metric argument?  What does it do with it?

  The "metric" argument is used as a boolean.  In other words, all that
  matters is zero and non-zero.

  It is used to set an internal flag to identify the route as "direct" (ARP
  for the IP destination address) or "indirect" (send the packet to the
  physical address identified by the gateway argument).

  Personally, I believe this use of the metric argument __can__ be made
  irrelevant (but it actually is not in a straight BSD implementation). For
  this purpose, if the "gateway" argument is a local interface IP address,
  the route is "direct"; otherwise, the route is "indirect".

  That is, I believe the following are either useless or erroneous:

     route add $destination $localIP  1   # indirect to ourself
     route add $destination $remoteIP 0   # direct to nonlocal IP address

  In fact, I believe the latter should produce an error.  But I coulda sworn
  I got it to work under certain limited situations.  I just don't recall.

  Someone has given me an interesting interpretation of the former, which I
  have not yet had time to look into.  Nonetheless, I believe the same effect
  can be gotten another way.

-- Ken Mintz

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      05 Nov 1993 17:36:06 GMT
From:      jazz@jazz.hal.com (Jason Zions)
To:        comp.protocols.tcp-ip
Subject:   Re: What is the overhead of a hub?


   In article <1993Oct22.063104.28473@huey.csun.edu> secssxn@mx.secs.csun.
   edu (Scott Neugroschl) writes:

   >	-------thin net------------------------
   >	 |                |        |         |
   >	SCO		XTERM	  misc	  AT&T
   >      server			   pcs	  STARLAN hub (in our lab)
   >					     | 
   >					     | 10BaseT line
   >					     |
   >					  AT&T
   >					  STARLAN hub (in wiring closet)
   >					     | 
   >					     | 6 10BaseT lines
   >					     |
   >					   OFFICE X terminals
   >
   >1) What sort of overhead is involved in the wiring diagram shown?

Purely the speed of the hub; how fast it can suck bits in one side and drive
them out the other side. Hubs are, technically, multiport repeaters; they
have only a few bits of buffering, at most, and provide no protection from
packet collision (like bridges do).

The big question is this: just how old are these STARLAN hubs, anyway? If
they're the original STARLAN, they're what, five, six years old? Way slow
compared to modern hubs.

   >2) Does an adapter of the kind I'm looking for exist?

There are a couple ways of converting 10BaseT to 10Base2; on a
per-workstation basis, there are Balun-type things that do it, for about
$150 per port, but I don't know if they're suitable for hooking a multiport
repater to a 10Base2 backbone.

I'd recommend you replace both starlan hubs with a single modern repeater
that has a 10Base2 connector as well as 10BaseT ports. HP makes several, as
do 3Com, Synoptics, and the rest of the usual suspects.


-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 1993 17:43:29 GMT
From:      nprobert@fires1.uucp (Neal Probert)
To:        comp.protocols.tcp-ip
Subject:   Looking for a telnetd with activity time out ?

Looking for a telnetd that has an activity time out where it dies if
there is no activity for a specific period of time.

Thanks.



-- 
-------------------------------------------------------------------------------
    FORD       | Neal W. Probert   E3154 SRL    | nprobert@fires1.srl.ford.com
 SCIENTIFIC    | Ford Scientific Research Labs  | 313-845-8178 FAX 313-845-8202
RESEARCH LABS  | Dearborn, MI 48121-2053        | Disclaimer: I'm innocent!

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      05 Nov 1993 17:46:16 GMT
From:      jazz@jazz.hal.com (Jason Zions)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibm-pc
Subject:   Re: Bootp - where is it headed

A significant effort is underway by about a half-dozen folks scattered
around the country to produce version 2.4 of the CMU-codebase bootd server.
Among many other things, it'll support up through RFC 1497 in the
vendor-extension area (initially defined in RFC 1048), include the ability
to broadcast bootp replies, a bunch of bugfixes, etc.

Stay tuned; announcements will appear here.

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      05 Nov 1993 17:53:10 GMT
From:      jazz@jazz.hal.com (Jason Zions)
To:        comp.protocols.tcp-ip
Subject:   Re: Help on large ethernet packets > 1500

In article <skaaric.4@ion.bpmf.ac.uk> skaaric@ion.bpmf.ac.uk (Robert Clark) writes:

   I have install fergie and from that display it seems that under these
   conditions the packet size distribution shows 50% > 1500.

Is this >1500 or >1518? Protocols like NFS will send maximal-size ethernet
packets (IP fragmentation handles this, actually); the maximum-sized
ethernet packet is 1518 bytes, not 1500. On a network with heavy NFS (or
even FTP) traffic, I'd expect to see many full-size packets.

I'd be surprised if fergie didn't report oversized packets separately; have
you checked that?

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Nov 1993 18:09:26 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Finding hop-counts

In article <9311050916.AA26437@gandalf.think.com> barmar@think.com (Barry Margolin) writes:
>In article <SHIRONO.93Oct31160905@gcx1.ssd.csd.harris.com> shirono@ssd.csd.harris.com writes:
>>The Berkeley routing table does not keep hop counts.  They are irrelevant
>>to actual packet routing.  Hop counts are relevant only to distance-vector
>>routing protocols, such as RIP.  Berkeley's routed(8) implements RIP.
>
>If the kernel doesn't store this information, why does the route command
>require a metric argument?  What does it do with it?

It's been a few years since I rummaged around in the BSD networking code,
but it may only use the metric to set the Gateway bit in the route entry.

Art



-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 1993 02:53:52 -0500
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Finding hop-counts

   Date: Fri, 5 Nov 93 13:29:39 -0500
   From: shirono@gcx1.ssd.csd.harris.com (Roberto Shironoshita)

   On taking a closer look, it seems that the 4.3 Reno networking code has
   some metric info in its route entry, but I don't know that it is used
   internally by the kernel.

   At any rate, in the absence of route metrics in the table, the kernel
   simply takes the first route it finds.  The route daemons are the ones that
   use the metrics to decide whether to change a route or not.

It would make sense for the metrics in the kernel to be used by the routing
daemon to initialize its table.  I.e. it's for communication between the
route command and the routing daemon.  I agree that the kernel itself
doesn't need to use the metric for its routing.

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Nov 1993 19:04:00 GMT
From:      xwu@indyvax.iupui.edu (Xiaomin Wu)
To:        comp.protocols.tcp-ip
Subject:   traceroute

Where can I get the latest version of traceroute? Will it involve kernel
mods? (I'm interested in Mac and PC).  
Thanks in advance.

Wu
xwu@indyvax.iupui.edu


-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 1993 19:38:25 GMT
From:      shane@utdallas.edu (Shane Davis)
To:        comp.protocols.tcp-ip
Subject:   Re: Finding hop-counts

Ken Mintz (mintz@cup.hp.com) wrote:
[...]
>   That is, I believe the following are either useless or erroneous:
 
>      route add $destination $localIP  1   # indirect to ourself
>      route add $destination $remoteIP 0   # direct to nonlocal IP address
 
>   In fact, I believe the latter should produce an error.  But I coulda sworn
>   I got it to work under certain limited situations.  I just don't recall.

This latter one will work if there is some router entity on the wire doing
proxy ARP for machines on its other interface(s). That also allows one to use
a netmask of, say, 255.255.0.0 for a class B when one's network is actually
subnetted.

Although we encourage use of the proper netmask here, the routers will
perform proxy ARP and allow hosts with a "route 129.110.0.0 my-name 0" to work
in spite of the fact that 129.110.x.0 is on a different wire from 129.110.y.0.

Maybe that's not what you meant, but it's a way in which the latter example
works.

--Shane
--
Network Systems Software            I needed a new vice after I quit smoking;
Univ. of Texas at Dallas            so, after 7 .signature-free years...
"This is side 5...follow along in your book and repeat after me as we learn 3
new words in Turkish...towel...bath...border...May I see your passport, please?"

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Nov 1993 22:11:36 GMT
From:      sjs@netcom.com (Stephen Schow)
To:        comp.protocols.tcp-ip
Subject:   Question about SLIP servers

I am wondering if there are any kind of SLIP "servers" or some such thing.
Basically I need a device which would sit on our ethernet(TCP/IP) network.
It would have 1 or more 14400+ baud modems attached to it.  When people called
in, it would establish SLIP connections with them and then they would be able
to connect to anything on the ethernet network using normal TCP addressing,
provided that they have a SLIP based client running on their PC or Mac or
whatever they are using.

Does this make sense?  If not, please enlighten me.  I am trying to find out
the best way for people in our company to dial in and use any one of many
computers(with only one phone number).  They could connect to the Sun, HP,
or anything else with an IP address and open security.  They could use SLIP
or something that would enable them to function the same as if they were
directly connected to the network.

Help please.  Is there a FAQ?
-- 
------------------------------------------------------------------
Steve Schow    | But you don't need to use the claw, if you
sjs@netcom.com | pick the pear with the big paw paw......
(415) 354-4908 | Have I given you a clue......?
               |                       - Baloo the Bear
------------------------------------------------------------------

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 1993 22:24:44 GMT
From:      mike@ecs.educ.ubc.ca (Michael Shepard)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Unable to run pcnfsd v2

I have been unable to run pcnfsd version 2 (dated 93.02.16) on my
SPARC 1 running SunOS 4.1.2. If I try to run it, I get a core dump and
nothing else happens. 

I have compiled and run the exact some version on my Sun IPX running
SunOS 4.1.3. with no problems at all. When I run this on my SPARC, 1 I
get the standard warning about the library being too old.

Does anyone have any suggestions?



-- 
-----------------------------------------------------
Michael Shepard 
Education Computing Services
Faculty of Education, University of B.C. 

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 1993 02:37:49 GMT
From:      tstark@clark.net (Tim Stark)
To:        comp.protocols.tcp-ip
Subject:   Looking for Network Traffic Monitor

All:

   I am looking for a network traffic monitor software that keeps tracks of 
packets and results how much usage of specific ports like ftp, nntp,
news, mail, mud, etc.. My system is Solaris 2.2 operating system.
Can you point me to a solaris or system V version of that software?

   I grabbed tcpdump software but it is for BSD operating system. :(

-- Tim Stark

--
Timothy Stark			Inet: tstark@clark.net
6130 Edsall Rd. #301		TDD: (703)212-9731  FAX: (703)212-7598
Alexandria, Va. 22304-5859	Voice: Via VA Relay Center (800)828-1140
"God bless you! - My friend, Washington DC. - The Most Deaf Population City!"

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 1993 03:17:57 GMT
From:      tstark@clark.net (Tim Stark)
To:        comp.protocols.tcp-ip
Subject:   Need information for cable TV signals

All:

    I heard that DEC is developing the new routers for cable TV companies
that wants provide internet services to businesses, home, etc..  Does
anyone have information about that?

    Also I heard that PSI made good deal with the Cable TV company for
internet service somewhere. 

    We like to look into complete information for our future service.

-- Tim Stark

--
Timothy Stark			Inet: tstark@clark.net
6130 Edsall Rd. #301		TDD: (703)212-9731  FAX: (703)212-7598
Alexandria, Va. 22304-5859	Voice: Via VA Relay Center (800)828-1140
"God bless you! - My friend, Washington DC. - The Most Deaf Population City!"

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 Nov 1993 05:02:09 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: Finding hop-counts

Shane Davis (shane@utdallas.edu) writes:
> > route add $destination $remoteIP 0   # direct to nonlocal IP address
                         ^^^^^^^^                 ^^^^^^^^
> This latter one will work if there is some router entity on the wire doing
> proxy ARP [...]
  :
> the routers will
> perform proxy ARP and allow hosts with a "route 129.110.0.0 my-name 0" to work
                                                              ^^^^^^^
  I think you misunderstood my posting.

  Yes, `remote add $destination $localIP 0` depends on the existence of a
  proxy ARP router on the wire.

  But I was talking about `remote add $destination $remoteIP 0`.

  (Note __remote__IP, not __local__IP == "my-name".)

  In that case (as in the case $localIP), we should arp for $destination on
  the __local__ interface whose IP address matches the "gateway" address on
  the route command, in this case $remoteIP.

  Since, by definition, $remoteIP is not a local IP address, there should
  be no match.

  Indeed, normally the route command detects this obvious error and returns
  "network unreachable".

  But as I said, I coulda sworn it doesn't always happen as I expect.

  I now figured out the case when no error is reported, namely when $remoteIP
  is on the same subnetwork as a local interface.

  In that case, it appears (from a trace) that we do send the ARP over that
  local interface.  But is that correct?

  IMHO, this is a defect in SIOCADDRT.  That is, I see no functional reason
  why "$remoteIP" should be accepted and function the same as "$localIP"
  under this exceptional case.

  (Can someone offer a functional reason?  I want very much to ignore the
  "metric" argument on the route command and instead to use the local v.
  remote IP address to distinguish direct and indirect routes.)

  Not having the time to look into this right now, I can only guess that
  SIOCADDRT attaches the route to the (first) local interface that is on the
  same subnetwork as the "gateway" argument, not requiring an exact match.

  That's okay, I 'spose; but I just don't see any functional reason to
  permit it.

     [Sigh, I just thought of one.  On diskless clients, it allows to have
     __one__ /etc/netlinkrc to set up the default route for all clients by
     simply specifying the subnetwork address for the "gateway" argument.
     Is that how people use this "feature"?]

  I don't know.  Bear in mind that this is utter speculation since I have
  not looked into this further.

-- Ken Mintz

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 Nov 1993 14:29:54 GMT
From:      itbaop@pukrs7.puk.ac.za (Anton Opperman)
To:        comp.protocols.tcp-ip
Subject:   syslog

Hi all,

  I'm busy writing an app that submits a message to syslog on a loghost. This
  is accomplished by connecting to port 514, using UDP, and submitting the
  message. I have 2 questions:

  - The message always gets submitted to the user facility, how do I change
    this (would prefer this in daemon)?

  - How do I know if the submission was successful, no return code?

Thanks,

Anton Opperman
  itbaop@pukrs7.puk.ac.za

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 Nov 1993 21:00:21 GMT
From:      celita@berlioz.nsc.com (Eli Lopez)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans.ethernet
Subject:   Standalone TCP/IP package needed


Hello to all.

We want to implement the TCP/IP protocol (tcp, ip, icmp, arp, rarp)
in a stand alone environment.
We are using a diskless NS32000 based platform, with no operating system, and
we want to run the tcp server from prom, as a single task with a single port.
We are looking for a package that will require a limited effort in porting
to our platform.
Does anybody know of a stand-alone tcp/ip package for sale ? (or for free) ?

Any info/pointer will be helpful.

Please e-mail your answers directly to:         cgakta@taux01.nsc.com

Thanks
   Gary Kshepitzki           cgakta@taux01.nsc.com
   National Semiconductor (Israel) P.O.B. 3007, Herzlia 46104, Israel
   tel: 972-9-594255



-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 1993 01:48:09 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.protocols.tcp-ip
Subject:   Mrouted over a PPP link?

I want to set up an mrouted multicast tunnel to a standalone machine
with a PPP link but no ethernet. This mean that mrouted running on the
remote machine will only see one vif, the tunnel.  Mrouted won't run
without at least two vifs.

What's the right way to do this?
 

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



-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 93 17:34:23 CDT
From:      rsl11@kuhub.cc.ukans.edu
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Windows Sockets Version for QVTnet????

Hello there,

	You said you are able to run X-Win with WinSock of QVTnet? I installed
WinQVT/Net that is using its own TCP/IP transport, i.e. I have installed the
packet driver version. I tried installing the WinSock version but there is
something that I do not understand. 

If you install the WinSock version what other programs do you need? 
Do you need a TCP/IP transport, i.e. another program that provides the TCP/IP?
Would any transport do it? 
Is there a list that can work with WinSock? 
How do you specify the Windows Sockets envronment so that QVTnet will know 
which TCP/IP porgram you are using? 
Do you need to load a packet driver with the Windows Sockets version? In other
words, do you need to load the wd8003e.com packet driver if I have the Western
Digital EtherCard Elite 16? 
What are some Windows Sockets packages that one can use with the Windows 
socket version of QVT Net?

	I would very much appreciate your response.

Thanks, chris

E-mail Address: rsl11@kuhub.cc.ukans.edu

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 1993 22:51:38 -0600
From:      karl@Notwerk.mcs.com (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple subnets on same physical wire

In article <2bk5kjINN5jb@cronkite.cisco.com>, Tony Li <tli@cisco.com> wrote:
>In article <CFy4L2.Ipy@world.std.com> dpi@world.std.com (Mike Bloom) writes:
>    
>    A very brief question: is it legal/possible to have several subnets share
>    the same piece of physical thinnet cable?  A test customer of mine had the
>    following arrangement, but I'm not sure that it was legal:
>    
>    1. Two subnets (e.g., 16.122.144 and 16.122.128) in the same building, each
>       with many Unix workstation nodes.
>
>Yes, this is legal.

Legal but <highly> dangerous.  Sun machines, in particular, will fail in
nasty ways with arp and broadcast storms if you are not <extremely> careful
doing this.  The result will be cable meltdown, and it is not pretty.

Sun gear can be made "safe" for this, but it requires non-standard kernel
config options (at least with SunOS 4.x; no idea about Solaris 2.x)  I've
had to do this on more than one occasion, usually for short term changes of
configuration where you had to get new things up before tearing down old
(like infrastructure -- cable plant, etc).

One thing to remember -- it is <absolutely essential> that if a SunOS machine 
has two interfaces on the same wire, with different network numbers (as 
defined by the netmask), that they be configured NOT to forward packets.  
Note that this is exactly the opposite of the default config for a kernel 
which has two interfaces active!  It also means that a machine such as this
cannot route between the subnets for you.  

>    2. Two routers were configured as well, namely, one routed from subnet 144
>       to 128 while the other routed from 128 to 144.  The routers were also on
>       the same physical wire, I believe.
>
>This is strange, to say the least.  

Also legal, but again, watch out for arp and broadcast storms!  It is
possible to get redirect loopbacks in this situation if there is any 
broadcast traffic on the wire (and there always is -- arps at minimum).

>Well, I would start by simplifying the problem and only using one router to
>route in both directions.  I would then verify that you really are on one
>physical cable.  You should do this by snooping the wire, NOT just by
>tracing it physically.  Then snoop to see that the two hosts are getting to
>the router.
>
>Tony

Good advice. Grab a Sniffer and have at it.

--
Karl Denninger (karl@MCS.COM) 	| MCSNet - First Interactive Internet and 
Modem: [+1 312 248-0900]	| Clarinet feed in Chicago.  Send email to
Voice/FAX: [+1 312 248-8649]	| "info@mcs.com" for more information.

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 93 19:03:52 CDT
From:      rsl11@kuhub.cc.ukans.edu
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   TCP/IP Transport Packages. Info Required...

Hello there,

	I just wanted to get some information about some TCP/IP transport
packages that enable HCL-eXceed/W and other X-Windows emulators to run
on the PC under Dos and MS-Windows.

	I heard of the following packages that can serve as transports for
the HCL-eXceed/W package:

Wollongong Group WIN/TCP for Dos
Wollongong Group PathWay Access for Dos
Walker Richer & Quinn, Inc. The TCP Connection
Ugermann-Bass Inc. Net/One TCP BNS/PC
Sun Microsystems PC-NFS
Microsoft Dos TCP/IP
NetManage Inc. Chameleon TCP/IP
Novell 4.0 for Dos
Locus Computing TCP/IP for Dos
HP ARPA Services for MS-Dos
IBM TCP/IP for Dos
FTP Software Inc. PC/TCP Network Software Windows Enchanced mode

	I am interested in finding pricing info for the above packages to see
if it is worth buying HCL-eXceed/W.

	For X-Win the following TCP/IP transport packages are supported:

FTP Software - PC/TCP
Lanera -TCPOpen
Sun - PC-NFS
Winsock(Windows Sockets Package)

	I would like to know what the price information is for the following 
package in case any body is aware of them or if any of them is Public Domain.

	Thnaks Chris

E-mail:rsl11@kuhub.cc.ukans.edu

Please e-mail..

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Sun, 7 Nov 1993 15:08:52 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Ethernet overload due to faulty TCP/IP implementations

We had a rather interesting overload situation on our network a little over
a week ago, and I thought I would share the experience with the rest of the
net.

First, some background. University of Trondheim and SINTEF, a non-profit R&D
institution affiliated with the university, share a common network backbone.
This used to be an "inter-Ethernet" based on connecting the local Ethernets
via bridges, routers and a 5 Mbit/s broadband network (anybody here remember
Sytek?)  Nowadays, we have an FDDI ring in place, and an increasing number
of departments are connected to the FDDI ring. But the 5 MBit/s broadband
network still carries a lot of the traffic between the departments, and many
of the connections to the 5 MBit/s network are based on bridges.

On October 29, around 2 PM, I discovered that an X client I was running on
a remote system seemed to be extremely sluggish, with updates on my screen
taking several minutes to complete. I started monitoring the network with
tcpdump, and found the following interesting things happening:

1. A PC trying to start a telnet session to the broadcast address! The packets
were transmitted to the Ethernet broadcast address, and also carried an IP
broadcast address of 255.255.255.255. These packets were all TCP 'SYN' packets,
ie. the first packet of a TCP connection attempt. Furthermore, it transmitted
many of these packets rapidly, up to 110 packets per second.

2. Fortunately, most hosts ignored these packets. But a number of terminal
servers (all from 3Com/Bridge) answered! There were enough of these terminal
servers around that each 'SYN' packet the PC sent generated 20 - 35 packets of
reply. Furthermore, these terminal servers have another bug in their TCP/IP
implementation: The answers from the terminal servers had the IP broadcast
address (255.255.255.255) as *source* address.

Multiplying the numbers, and you can see that we have around 3000 packets per
second generated here. All of this traffic was carried across the 5 MBit/s
broadband network backbone. It led to the broadband network backbone being
almost completely unusable, with packet losses of 30 to 40 percent. Normally
the broadband network backbone carries around 300 - 700 packets per second,
with peaks of up to 1500 packets per second.

We found the owner of the PC in question, and got him to reboot - that being
the quickest way of stopping the problem. However, it's obvious that the same
problem could occur again, as long as some departments are connected to the
backbone with bridges instead of routers. This incident certainly has served
to strengthen my belief in a router-based instead of a bridge-based backbone.

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 93 17:43:44 GMT
From:      nkumar@cronkite.ocis.temple.edu (R Nandkumar)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Chameleon TCP/IP Network Driver Problem.

We have several PCs on an ethernet lan connecting to an NCR server.
The server runs Unix/ORACLE/SQL-NET/TCP/IP. The clients i.e. the PCs
use Chameleon NFS for the protocol stack, and the visual interface is 
provided by SQL-Plus. Here's the problem!! Four of the PCs recognize and
connect to the server just fine. But two of them return an error saying
that the TCP/IP driver is not loaded. The interesting part is that the 
two can ping the server with no problem. We have already tried the
obvious solutions,like making sure the configuration files are the
same on each PC,checking the network connections,and ensuring the
PCs have the same hardware configuration. Nope!! Still the same message. :-<
Any suggestions? Thanx!! 

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Sun, 7 Nov 1993 17:49:19 GMT
From:      lindsay@dscatl.atl.ga.us (Lindsay Cleveland)
To:        comp.protocols.tcp-ip
Subject:   Re: Question about SLIP servers

In article <sjsCG1HnC.HzM@netcom.com> sjs@netcom.com (Stephen Schow) writes:
>I am wondering if there are any kind of SLIP "servers" or some such thing.
>Basically I need a device which would sit on our ethernet(TCP/IP) network.
>It would have 1 or more 14400+ baud modems attached to it.  When people called
>in, it would establish SLIP connections with them and then they would be able
>to connect to anything on the ethernet network using normal TCP addressing,
>provided that they have a SLIP based client running on their PC or Mac or
>whatever they are using.

We have been using the Telebit NetBlazer for just this function.
It will establish either SLIP or PPP connections, support a modem
pool for both in-coming and out-going links (SLIP, PPP, or plain
old ASCII terminal emulation), and can also function as a router.
Has Telnet and FTP capability between it and any other network node.

We use a pair of them between two buildings (primarily as routers)
supporting a 56KB line.  A neat feature is that if the leased line goes
down, one NetBlazer will automatically dial out on its modems to the
other NetBlazer and use the connections to keep the data flowing!

You can administer it either from a directly-connected terminal, by
dialing into a modem port, or via Telnet.  If you *really* want to,
you can take the DOS-format diskette with its configuration
information to another computer, modify it with any character
editor, put the diskette back into the NetBlazer and reboot!

Fairly straight-forward to set up and configure.  

Cheers,
  Lindsay

Lindsay Cleveland           Digital Systems Co, Inc,  Atlanta GA
  gatech!dscatl!lindsay     (404) 497-1902
  lindsay@dscatl.atl.ga.us  (U.S. Mail:  PO Box 1149, Duluth  GA 30136)

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Sun, 7 Nov 1993 20:04:06 GMT
From:      jch@CS.CMU.EDU (Jonathan Hardwick)
To:        comp.protocols.tcp-ip
Subject:   Re: LBL CSLIP 2.7 is now released

In article <35236@dog.ee.lbl.gov> cslip@ee.lbl.gov (Craig Leres) writes:
> I just placed cslip-2.7.tar.Z in the anonymous ftp directory of
> ftp.ee.lbl.gov. When retrieving this compressed tarchive, don't forget
> to set binary mode. This package should work without too much trouble
> on BSD derived systems and is known to work with SunOS 4. But
> unfortunately, Solaris 2 is NOT supported.

The README for cslip-2.7 advises upgrading to the 4.3-tahoe network
code** if running SunOS 4.1.1 or earlier.  Unfortunately, the 4.3-tahoe
README appears to have been written in the days of SunOS 3.5; I can't
get the code to integrate with my SunOS 4.1.1 system.  Has anyone
succeeded in doing this?  How?  I'll summarize any replies I get to the
net, and write up a README.TAHOE file for inclusion in cslip-2.8...

Jonathan H.

** pub/UCB/tcp.tar.Z and inet.tar.Z from gatekeeper.dec.com

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Sun, 7 Nov 1993 20:10:06 GMT
From:      thomas@datamark.co.nz (Thomas Beagle)
To:        comp.os.ms-windows.setup,comp.os.ms-windows.misc,comp.protocols.tcp-ip
Subject:   Re: Windows for Workgroups over TCP/IP

In article <CG0uE1.F25@mdis.co.uk> mab@mdis.co.uk (Martin Bradford) writes:

>: They have LanManager running on the HPUX box with an ethernet
>: consisting of LanManager clients, all using TCP/IP as the transport.
 
>: Then, using the WinSock that's part of WfWG TCP/IP we installed
>: WinQVTNet 3.94 for WinSock on the client PC. This then gives them
>: Telnet, Mail, News, etc, etc.
 
>	Can we just clarify this because it sounds like it might be what
>we are looking for. Are you saying if you have two lans set up as you
>describe and each of them were gated into the Internet (as we are) then
>workstations on one lan could make use of the W4WG facilities (e.g. Clipbook,
>distributed DDE etc) to workstations on the other lan (possibly on the other
>side of the world)? You only mention file transfer to/from the server which
>is not the same thing at all.

There aren't two LANs, only one. This LAN has Lanmanager as the server
and WfWG as the client PC software. They don't have an internet link,
but there's no reason why they couldn't. (They do have a remote site
but that uses bridges rather than routers.)

>	I know that it is quite easy to make W4WG coexist with tcp - we run
>like that all the time, but we would like to be able to interact with
>workgroups all over this country (or the rest of the world).

It's not a case of WfWG coexisting with TCP/IP - it's using TCP/IP as
the transport. Therefore all the normal routers, name servers, and so
on should all work with WfWG just as they do with any other TCP/IP
networking software. The router doesn't know what networking software
you're running, it just knows how to move TCP/IP packets around.

Or so I understand it anyway.

-- 
   Thomas Beagle |    ,__o    Faster and faster until the thrill of speed 
Technical Writer |  _-\_<,    overcomes the pain of long ears flapping
  Wellington, NZ | (*)/'(*)   in the wind.          thomas@datamark.co.nz

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 93 21:42:30 GMT
From:      cml0464@ultb.isc.rit.edu (C.M. Leung)
To:        comp.protocols.tcp-ip
Subject:   Good books on TCP/IP for beginners


Can anyone recommend a good book for TCP/IP programming?

I start to get a rough concept on different parts of TCP/IP and try to 
catch up on more detail through Douglas Comer's book.  However, that book
is slightly unreadable compared to others I have come across.  I have to
agree it contains lots of detail on design and implementations and it seems
that it's a struggle to get through some of the codes.  I guess I find it
hard to connect to different parts in the book.

Anyone has some comments on another book titled "Practical internetworking
with Unix" by Addison Wesley?

Regards

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 1993 00:58:59 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple subnets on same physical wire

In article <CFy4L2.Ipy@world.std.com> dpi@world.std.com (Mike Bloom) writes:
    
    A very brief question: is it legal/possible to have several subnets share
    the same piece of physical thinnet cable?  A test customer of mine had the
    following arrangement, but I'm not sure that it was legal:
    
    1. Two subnets (e.g., 16.122.144 and 16.122.128) in the same building, each
       with many Unix workstation nodes.

Yes, this is legal.

    2. Two routers were configured as well, namely, one routed from subnet 144
       to 128 while the other routed from 128 to 144.  The routers were also on
       the same physical wire, I believe.

This is strange, to say the least.  

    3. I tried to ping one node on subnet 128 from another on subnet 144, but
       this failed.
    4. I tried to construct static routes from the workstation on 128 through
       the 128-144 router, as well as one in the opposite direction, but the
       attempt to establish a route from 144-128 just hung.  The ping failed
       too.  The customer's system administrator felt that the routers had
       all of the routine information they needed without the need for extra
       static routes, but we tried it anyway.

Most of the routers that I know of would not require additional static
routes.

    5. It may be possible that the node on subnet 128 did not have its IP
       address correctly set in it, but this is simply speculation at the
       moment.  Clearly, this would explain the symptoms that we saw!
    
    Any info on what we did wrong and what we should do next would be
    appreciated. 

Well, I would start by simplifying the problem and only using one router to
route in both directions.  I would then verify that you really are on one
physical cable.  You should do this by snooping the wire, NOT just by
tracing it physically.  Then snoop to see that the two hosts are getting to
the router.

Tony

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 93 01:35:54 GMT
From:      jcmorris@mwunix.mitre.org (Joe Morris)
To:        comp.protocols.tcp-ip
Subject:   Re: What does Telnet mean?

liu@nchud1.nchu.edu.tw (Jinshung Liu) writes:

>>From: etxmesa@eos.ericsson.se (Michael Salmon)
>>Subject: What does Telnet mean?
 
>>I was recently acsked by a collegue what Telnet meant. I had never
>>thought of it meaning anything but my guess was Telecomputing via
>>Internet. Does anyone have a better suggestion or even better the
>>actual meaning.
 
>my guess to it :  Terminal emulation via network ( internet )
                   ^        ^  ^          ^^^
Nope.

The word comes from TELetype NETwork, which suggests just how long ago
it was coined.  'Way back then "internet" meant the corridor between the
posts on a tennis court.  8-)

Joe Morris / MITRE


-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 93 13:55:09 CDT
From:      rsl11@kuhub.cc.ukans.edu
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Changing the Login Drive in a Novell FileServer

Hello there,

	I have a question about the login drive in a Novell fileserver.
The login drive of my novell fileserver is f:. However, I need drive letter
f: for ramdrive and letter g: for stacker. So I though that maybe if I use
drive letter f: for ramdrive the network will default to g:. However
what happens is that the ramdirve is deleted after I login.

	My questions are:

1. How can I change the drive letter of the login drive from f: to any other
letter, say h:? I have tried the command map but it did not get rid of f:.
Note that before logging onto the Novell fileserver I already have drives
f: and g: that are already assigned to a stacker drive and ramdrive.
Is there a way maybe to assign a different letter to ramdrive? To stacker?

	I would very much appreciate any relevant response.


Thanks, Chris

Please E-mail: rsl11@kuhub.cc.ukans.edu

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 93 14:34:21 CDT
From:      whitley@sil.org
To:        comp.protocols.tcp-ip
Subject:   Help with subnet

Hello,

I need some info reguarding routing for a second class c address at our site.
We have a Dept. which runs a 4-lan novell setup seperate from the main backbone.
They have acquired a second class c internet address and have subnet that 
number into 6 nets.  They want to be able to use the router on the main backbone
to get out to the internet.  Can anyone point me in the right direction to set
this up?  Can we even there from here?  Sorry if this is not enough info.
Please e-mail with responses to rick.whitley@sil.org.

Rick...

Isaiah 41:13

============================================================
rick.whitley@sil.org | ...A Church for every People
System Manager       |     The Gospel for every Person
S.I.L.               |   by the year 2000...
Dallas, TX           |
============================================================


-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 1993 19:06:44 -0500
From:      kimc@w8hd.org (Kim Culhan)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple subnets on same physical wire

karl@Notwerk.mcs.com (Karl Denninger) writes:

>Good advice. Grab a Sniffer and have at it.

karl, could you suggest a Sniffer and where it could be found?

regards
kim culhan

-- 
kimc@w8hd.org

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Nov 1993 12:55:45 GMT
From:      leo@elmail.co.uk (E.J.Leoni-Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Help: Network application

In article <5NOV199316120155@vtpwr1.psl.ee.vt.edu> gharpure@vtpwr1.psl.ee.vt.edu (Vasudev Gharpure) writes:
>Hi
>
>        I have an application wherein I must send data (1-2 Kbytes) 
>continuously (every few seconds) from a PC(486, with a 3Com Etherlink III 
>card) to a Sun sparcstation. This could go on for a few minutes at a time. 
>The machines are practically sitting next to each other and are directly 
>connected to each other over the ethernet by crossed over twisted pair.
>
>    On the PC, I could use ftp in a batch file thus:
>
>        a) applic.exe ---saves data file
>        b) ftp the file
>        c) loop back to a)
>
>    (We will have everything on a ramdisk and save on disk access time)
>
>    However, it seems to be a waste to load the .exe files and open/close 
>the connection each time. I think this will also slow down the process 
>somewhat.

Why don't you just by a copy of PC-NFS and do it this way

(From within program)
(i) Open temporary file on NFS mounted SPARC directory.
(ii) spool data to it
(iii) close it
(iv) rename it to something known to the SPARC
(v) go to (i)

And on the SPARC...
(i) Look for known filename in directory.
(ii) If not found sleep for a second and go to (i)
(iii) If found rename to something else quicky.
(iv) process it
(v) go to (i)

..who needs socket programming? Unless you are selling this App. in
millions why not opt for the easy way out?

;-)

Leo


-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Nov 1993 13:29:43 GMT
From:      ag129@ucs.cam.ac.uk (Alasdair Grant)
To:        comp.protocols.tcp-ip
Subject:   Must a host handle ICMP redirects?

Is there any standards requirement on a host to handle the ICMP 
redirects it receives?  I.e. can a host throw them all away?
From my reading of RFC 792 nothing will go wrong if it does, just
reduced performance.  For example is it acceptable for A to send
a packet for B to G1, G1 to send an ICMP redirect for G2 back to
A, and for A's very next packet to be one for B, still sent to G1.
Say if A just had a finite table for redirects, is it allowed to
fill it up until it's full or is there a requirement on it to use
some kind of LRU strategy so recent redirects always get in the
table?

It is not my TCP/IP implementation - I am trying to get a vendor
to fix theirs and I need the standards to back me up as they are
taking it as 'design change' rather than 'bug fix'.
--
Alasdair Grant

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 93 14:29:20 GMT
From:      davidsen@sixhub.tmr.com (Bill Davidsen)
To:        comp.protocols.tcp-ip,biz.sco.opendesktop
Subject:   Re: NFS printers under SCO ODT 2.0

In article <1993Nov4.072624.15520@huey.csun.edu> secssxn@mx.secs.csun.edu (Scott Neugroschl) writes:
| 
| We are using SCO ODT 2.0 and Wollong Pathway 2.1.1 and Client NFS 1.2.1
| (? not sure if that is correct -- either 1.2 or 1.2.1).  When we try to
| mount a printer via NFS we find its not exported.  When I put a printer
| in the /etc/exports file on the server, SCO barfs and pcnfsd dies when
| I try to mount it.
| 
| What is the proper way to export a printer for NFS mount/printing?  TFM
| doesn't give any clues.

  Either I don't know what you're doing, or you don't know what you're
doing. As far as I know, you can't export a printer with NFS, that's one
of the advantages of RFS, in that it can export physical devices.

  I suggest you use a more conventional approach and set up a remote
line printer daemon, then use standard remote line printer protocols for
sending data to the printer *queue*.

  My manual describes this in some detail, and I bet yours does too.
-- 
Bill Davidsen, davidsen@tmr.com      |  C programming, PC based UNIX, data
    TMR Associates, +1 518-370-5654  |  acquisition, device drivers.
_____________________________________|______________________________________
I can see clearly now, the brain is gone. I can see all popsicles in my way

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      08 Nov 1993 14:46:44 GMT
From:      miles@cogsci.ed.ac.uk (Miles Bader)
To:        comp.protocols.tcp-ip
Subject:   Re: Help: Network application

leo@elmail.co.uk (E.J.Leoni-Smith) writes:
> >    On the PC, I could use ftp in a batch file thus:
> >
> >        a) applic.exe ---saves data file
> >        b) ftp the file
> >        c) loop back to a)
> >
> >    (We will have everything on a ramdisk and save on disk access time)
 
> Why don't you just by a copy of PC-NFS and do it this way
[describes similar operation, but using nfs]

Reason 1) Because writing over NFS, especially using PC-NFS, is one of the
slowest operations known to man...  FTP (again from a pc) is over 10 times as
fast in my experience.

NFS: just say no

-Miles
--
--
Miles Bader - HCRC, U of Edinburgh - miles@cogsci.ed.ac.uk, +44 31 650-4439
Is it true that nothing can be known?  If so how do we know this?  --Woody Allen

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Nov 1993 14:56:58 GMT
From:      Rick_Granberry@pts.mot.com (Rick Granberry)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Ethernet overload due to faulty TCP/IP implementations

Steinar.Haug@runit.sintef.no (Steinar Haug) writes:
> 
> We had a rather interesting overload situation on our network a little over
> a week ago, and I thought I would share the experience with the rest of the
> net.
> . . .
> . . .
> A PC trying to start a telnet session to the broadcast address! The packets
> were transmitted to the Ethernet broadcast address, and also carried an IP
> broadcast address of 255.255.255.255.
 
> 2. Fortunately, most hosts ignored these packets. But a number of terminal
> servers (all from 3Com/Bridge) answered!
> . . .
> Furthermore, these terminal servers have another bug in their TCP/IP
> implementation: The answers from the terminal servers had the IP broadcast
> address (255.255.255.255) as *source* address.
> . . .
> However, it's obvious that the same
> problem could occur again, as long as some departments are connected to the
> backbone with bridges instead of routers. This incident certainly has served
> to strengthen my belief in a router-based instead of a bridge-based 
backbone.

Uh, what would be different?  Wouldn't the routers be passing packets sent to 
the IP broadcast addresses?  Furthermore, the routers would be connected to 
many networks, not just two, which would compound the situation.


| Rick_Granberry@pts.mot.com
|
| Hell and destruction are never full:  so the eyes of man are never satisfied.



-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Nov 1993 15:29:49 GMT
From:      steven@unipalm.co.uk (Steven Vincent)
To:        comp.os.ms-windows.setup,comp.os.ms-windows.misc,comp.protocols.tcp-ip
Subject:   Re: Windows for Workgroups over TCP/IP


ben@piglet.cr.usgs.gov (Ben A. Mesander) writes:


>   Michael S. Bendtsen (msbendts@mtu.edu) wrote:
>   : Yes, WfW can run concurrently with a TCP/IP network.  I have setup WfW and
>   : FTP Software's PC/TCP pacakge on my network without much of a hitch.  I am
>   : even using an outta date version of the PC/TCP package too (v2.05...they 
>   : are now up to v2.11)  As for getting winsock to work with it, I have not
>   : yet been successful, but I have also not tried the winsock.dll update that
>   : I just got yet either.  (FTP PC/TCP winsock.dll can be obatined at ftp.com)
>   : I might be SOL due to my version of FTP's package, but I have heard of others
>   : having no problems.
 
>Have you been able WFWG to use NFS drives mounted with PC/TCP's idrive?
>I can make NFS work under DOS, and under regular windows, but under wfwg,
>file manager shows no files on NFS-mounted drives. I really would like to
>make this work, so I can get rid of dpci/Domain OS on my network, and
>replace them with NFS/UNIX type stuff, which will make maintaining my
>network easier.

load the w4wfix.386 driver provided to get round the bug in Microsoft's 
drive redirector.

w
>If you post, please reply to me via email also; I rarely have time to read
>news. Thanks...
 
>--Ben
 
>--
>I think signatures are stupid, but the US Geological Survey requires that I
>have a ``disclaimer'' informing you that I am not an official US government
>spokesdroid.

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Nov 1993 16:46:25 GMT
From:      liu@nchud1.nchu.edu.tw (Jinshung Liu)
To:        comp.protocols.tcp-ip
Subject:   Re: What does Telnet mean?

>From: etxmesa@eos.ericsson.se (Michael Salmon)
>Subject: What does Telnet mean?
 
>I was recently acsked by a collegue what Telnet meant. I had never
>thought of it meaning anything but my guess was Telecomputing via
>Internet. Does anyone have a better suggestion or even better the
>actual meaning.
>
my guess to it :  Terminal emulation via network ( internet )
                  ^        ^  ^          ^^^
J L

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Nov 1993 17:19:17 GMT
From:      cml0464@ultb.isc.rit.edu (C.M. Leung)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple subnets on same physical wire

In article <2bkj8q$2uo@Notwerk.mcs.com> karl@Notwerk.mcs.com (Karl Denninger) writes:
>In article <2bk5kjINN5jb@cronkite.cisco.com>, Tony Li <tli@cisco.com> wrote:
>>In article <CFy4L2.Ipy@world.std.com> dpi@world.std.com (Mike Bloom) writes:
>>    
>>    A very brief question: is it legal/possible to have several subnets share
>>    the same piece of physical thinnet cable?  A test customer of mine had the
>>    following arrangement, but I'm not sure that it was legal:
>>    
>>    1. Two subnets (e.g., 16.122.144 and 16.122.128) in the same building, each
>>       with many Unix workstation nodes.
>>
>>Yes, this is legal.
>
>Legal but <highly> dangerous.  Sun machines, in particular, will fail in
>nasty ways with arp and broadcast storms if you are not <extremely> careful
>doing this.  The result will be cable meltdown, and it is not pretty.


Wow, cable meltdown!  Talking of solid damage what "soft"ware can achieve!


-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Nov 93 18:11:27 GMT
From:      mikeh@microme.uucp (Michael L. Hasenfratz)
To:        comp.os.ms-windows.setup,comp.os.ms-windows.misc,comp.protocols.tcp-ip
Subject:   Re: Windows for Workgroups over TCP/IP

In article <BEN.93Nov4085138@piglet.cr.usgs.gov> ben@piglet.cr.usgs.gov (Ben A. Mesander) writes:
>
>   Michael S. Bendtsen (msbendts@mtu.edu) wrote:
>   : Yes, WfW can run concurrently with a TCP/IP network.  I have setup WfW and
>   : FTP Software's PC/TCP pacakge on my network without much of a hitch.  I am
>   : even using an outta date version of the PC/TCP package too (v2.05...they 
>   : are now up to v2.11)  As for getting winsock to work with it, I have not
>   : yet been successful, but I have also not tried the winsock.dll update that
>   : I just got yet either.  (FTP PC/TCP winsock.dll can be obatined at ftp.com)
>   : I might be SOL due to my version of FTP's package, but I have heard of others
>   : having no problems.
>
>Have you been able WFWG to use NFS drives mounted with PC/TCP's idrive?
>I can make NFS work under DOS, and under regular windows, but under wfwg,
>file manager shows no files on NFS-mounted drives. I really would like to
>make this work, so I can get rid of dpci/Domain OS on my network, and
>replace them with NFS/UNIX type stuff, which will make maintaining my
>network easier.
>
>If you post, please reply to me via email also; I rarely have time to read
>news. Thanks...
>
>--Ben
>
>--
>I think signatures are stupid, but the US Geological Survey requires that I
>have a ``disclaimer'' informing you that I am not an official US government
>spokesdroid.
>--
>--
>I think signatures are stupid, but the US Geological Survey requires that I
>have a ``disclaimer'' informing you that I am not an official US government
>spokesdroid.

	For what it's worth. I use PC-NFS Ver. 5.0 (note... 5.0) and it comes
with the files to set it up for use with WfWg. Not only can I see my NFS
drives at anytime in WfWg, but In addition to the normal mount drive question
on the WfWg file manager, it includes a PC-NFS button to mount an NFS drive.

	Now as far as I know, it is NOT using TCP/IP as a transport media (as
I my WfWg has no idea what the IP address is) The PC-NFS applications that are
installed during the 'winstall' of PC-NFS 5.0 can deal with the IP stuff, but 
WfWg in and of itself does not.

	The telnet is great, as is the FTP. I have NOT seen anything on a windows
based MAIL 'hook' though (still looking!!!).

	My $.02...

73's de Mike

Mike Hasenfratz - WA6FXT * mikeh@uMEM.COM or uunet!microme!mikeh
Micro Memory Inc.
Chatsworth, Ca. 91311

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 1993 18:12:12 GMT
From:      whalenm@obelix.tsg.com (Matthew Whalen)
To:        comp.protocols.tcp-ip
Subject:   Subnetting Class C Addresses - again

I know this was discussed a fair amount recently, and I know that it
it possible to do, so what I am looking for are suggestions.  Should
we attempt to subnet our class c networks, or should we simply request
a couple more class c networks and not use a lot of the addresses?

--
-matthew           ____ 	"Thanks mom...
whalenm@tsg.com    \  /		love the genes."
(NeXTMail OK)       \/		
----------------------------------------------------------------
(My actions/words in no way reflect those of my employer.)

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 1993 18:28:08 GMT
From:      pascoe@MathWorks.Com (Dave Pascoe)
To:        comp.protocols.tcp-ip
Subject:   IP broadcast address getting reset

I'm having a strange problem on a SPARC-10 running SunOS 4.1.3 where
the IP broadcast address is being reset by some process from all ones
to all zeros.  i.e., 144.212.255.255 is being changed to 144.212.0.0.

Anyone know what might be doing this?

--
Dave Pascoe
The MathWorks, Inc.
508-653-2452  x362
pascoe@mathworks.com

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Nov 1993 18:53:32 GMT
From:      gary@sci34hub.sci.com (Gary Heston)
To:        comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: ISDN (was Re: X.25 through tcp-ip)

In article <CFyqyv.JL6@Stollmann.DE> Helge.Oldach@Stollmann.DE (Helge Oldach) writes:
>jrg@rahul.net (John Galloway) writes:
 
>| I was amazed when doing a contract in Munich that even the giant Siemens
>| Nixdorf was until recently using uucp for email because a dedicated IP
>| connection was to expensive due to the control of telecom by the government.
 
>You're mixing up facts here. Leased lines (which I suppose SNI was not using
>for IP traffic for price reasons) are not ISDN. Leased lines in fact still are
>expensive, but I can get a transparent 2B+D connection between home and work for
>just $200 a month (no traffic charges).

At the moment, the state Public Service Comission has before it a tarrif
request from BellSouth for the establishment of ISDN service pricing. I'm
getting a line right now; the requisition is in process under a non-tarrifed
provision that permits special arrangements for large customers. Hopefully,
the line will be in place in 2-3 weeks (the local telco people haven't
handled many of these yet, and most are still having trouble spelling
"ISDN").

My quoted price per month for flat-rate usage is $75. Our corporate
communications manager was amazed....

Right now, the biggest holdback isn't the availability of connections,
it's the $2100+ cost of the bridges. If that comes down to under $1000,
ISDN will really take off.


-- 
Gary Heston    SCI Systems, Inc.  gary@sci34hub.sci.com   site admin
The Chairman of the Board and the CFO speak for SCI. I'm neither.

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Nov 1993 19:30:13 GMT
From:      leo@elmail.co.uk (E.J.Leoni-Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Help: Network application

In article <MILES.93Nov8144644@oliphant.cogsci.ed.ac.uk> miles@cogsci.ed.ac.uk (Miles Bader) writes:
>leo@elmail.co.uk (E.J.Leoni-Smith) writes:
>> >    On the PC, I could use ftp in a batch file thus:
>> >
>> >        a) applic.exe ---saves data file
>> >        b) ftp the file
>> >        c) loop back to a)
>> >
>> >    (We will have everything on a ramdisk and save on disk access time)
 
>> Why don't you just by a copy of PC-NFS and do it this way
>[describes similar operation, but using nfs]
>
>Reason 1) Because writing over NFS, especially using PC-NFS, is one of the
>slowest operations known to man...  FTP (again from a pc) is over 10 times as

I found ftp under PC-NFS actually SLOWER against a sparc target than NFS.
PC/TCP was much fatser on FTP than NFS tho.

But its NFS was SLOOW!

On the other hand, you pays your money and you takes your choice.

I assumed you wanted a practical solution, not e technically
perfect and aesthetically pleasing one - you aren't
a computer scientist are you ?

Leo Smith
-----------------------------------------------------
A software engineer is a man who can do in sixteen bytes what a computer
scientist can write a thesis on, and needs a megabyte of RAM just to
write the formal analysis

Freely adapted without shame from Neville Shute (Norway). :-)


-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Nov 1993 20:23:45 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Ethernet overload due to faulty TCP/IP implementations

>Uh, what would be different?  Wouldn't the routers be passing packets sent to 
>the IP broadcast addresses?  Furthermore, the routers would be connected to 
>many networks, not just two, which would compound the situation.

Read RFC 1122. 255.255.255.255 is a broadcast limited to that particular
physical network segment it is sent on. RFC 1122, section 3.2.1.3:

            (c)  { -1, -1 }

                 Limited broadcast.  It MUST NOT be used as a source
                 address.

                 A datagram with this destination address will be
                 received by every host on the connected physical
                 network but will not be forwarded outside that network.

A router will normally *not* forward a packet addressed to 255.255.255.255.

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 1993 20:33:03 GMT
From:      ddean@minerva.rolm.com (Drew Dean)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple subnets on same physical wire

|In article 2uo@Notwerk.mcs.com, karl@Notwerk.mcs.com (Karl Denninger) writes:
|In article <2bk5kjINN5jb@cronkite.cisco.com>, Tony Li <tli@cisco.com> wrote:
|> You should do this by snooping the wire, NOT just by
|>tracing it physically.  Then snoop to see that the two hosts are getting to
|>the router.
 
|>Tony
 
|Good advice. Grab a Sniffer and have at it.
 
|Karl Denninger (karl@MCS.COM) 	| MCSNet - First Interactive Internet and 

Well, you weren't at Wesley Irish's talk last week at Stanford.  Sniffers have
a nasty way of dropping packets, especially after collisions and other abnormal
events.  What you really need is a good digital storage oscilloscope, and a little
knowledge of Manchester encoding.  BTW, it's fun !

--
Drew Dean
ddean@robadome.com -- I don't speak for ROLM....




-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Nov 1993 21:48:56 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: Tcp Push?

In article <visser.752391183@convex.convex.com> visser@convex.com (Lance Visser) writes:
>   In most implementations you dont need to flush TCP data.  Its
 
>  done for you.  The TCP push bit doesn't have a whole lot of meaning
>  in many implementations.  You send and receive as fast as you can.
>  The flow control stuff regulates what gets sent.

I have noticed the delay of packets after a PUSH are longer that
other packets. I suspect that the PUSH bit is sent after the transmit
buffer is "finished". Is this the case?

--
Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Nov 1993 23:56:54 GMT
From:      lawson@netcom.com (Steven Lawson)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple subnets on same physical wire

Drew Dean (ddean@minerva.rolm.com) wrote:
[stuff deleted]

: Well, you weren't at Wesley Irish's talk last week at Stanford.  Sniffers have
: a nasty way of dropping packets, especially after collisions and other abnormal
: events.  What you really need is a good digital storage oscilloscope, and a little
: knowledge of Manchester encoding.  BTW, it's fun !

Digital storage scope???  A real man could do it with a cap and a #42
light bulb...  :-)   :-)


-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 93 00:28:48 GMT
From:      dcn1@ns1.cc.lehigh.edu (DAVID CHRISTOPHER NOEL)
To:        comp.protocols.tcp-ip
Subject:   Looking for TCP/IP source code

I am writing a simple program that will use TCP/IP on a SUN SparcStation.  I
am looking for some source code of programs that do this(ftp and telnet are
fine).  If someone could send me the address of an ftp site that contains
source code I would be grateful.

Thanks.

Dave
-- 
______________________________________________________
|====================================================|
|            Dave Noel Lehigh University             |
|      Internet address dcn1@ns1.cc.lehigh.edu       |
|====================================================|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Tue, 09 Nov 93 01:39:51 GMT
From:      jlevine@wvus.org (Jeff Levine)
To:        comp.protocols.tcpip,comp.protocols.misc
Subject:   strange packets seen?

One of our network technicians asked me to post this:



This may be a question for the Internet.  While analysing Ethernet
TCP/IP traffic using traces from LanWatch, I noticed something that
seems a little odd to me.  It's most pronounced coming from a Xircom
PE3-10BT Pocket Ethernet adaptor (plugs into the parallel port of a
laptop).  However I have seen the same oddity coming from Racal
Interlan NI6510 NICs and the Sequent boxes at less frequent
intervals.  We are running 10baseT using Synoptics 3000
concentrators and cards.~

What happens is that the sending device will, on occasion, send two or
more consecutive control packets (usually IP ACK or ACK/PUSH but never
any data) that are identical except for the packet ID. There is a time
separation of usually 0 to 5 milliseconds (ms is as fine as LanWatch
times the packets so anything less than 1ms is probably listed as 0ms)
between these packets. There are no responses from the receiving
device during these bursts. If these were retransmits due to
collisions, then our network management software would detect those
and the collision rate would be extreemly high. This is not the case.

Are these "retransmits" normal, or is there some condition that might
cause this kind of behaviour?~

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Tue, 09 Nov 93 02:01:43 GMT
From:      jlevine@wvus.org (Jeff Levine)
To:        comp.protocols.tcp-ip
Subject:   strange packets?

One of our network analysts wanted me to post this:




This may be a question for the Internet.  While analysing Ethernet
TCP/IP traffic using traces from LanWatch, I noticed something that
seems a little odd to me.  It's most pronounced coming from a Xircom
PE3-10BT Pocket Ethernet adaptor (plugs into the parallel port of a
laptop).  However I have seen the same oddity coming from Racal
Interlan NI6510 NICs and the Sequent boxes at less frequent
intervals.  We are running 10baseT using Synoptics 3000
concentrators and cards.~

What happens is that the sending device will, on occasion, send two or
more consecutive control packets (usually IP ACK or ACK/PUSH but never
any data) that are identical except for the packet ID. There is a time
separation of usually 0 to 5 milliseconds (ms is as fine as LanWatch
times the packets so anything less than 1ms is probably listed as 0ms)
between these packets. There are no responses from the receiving
device during these bursts. If these were retransmits due to
collisions, then our network management software would detect those
and the collision rate would be extreemly high. This is not the case.

Are these "retransmits" normal, or is there some condition that might
cause this kind of behaviour?~

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 1993 11:33:06 -0500
From:      jpn@genrad.com (John P. Nelson)
To:        comp.os.msdos.apps,comp.protocols.tcp-ip,comp.binaries.ibm.pc.wanted
Subject:   Looking for License Management Software

We have a network of about 200 PCs (using the Lan Manager protocol,
well, really DEC Pathworks TCP/IP).  We've found it convenient to make
certain commerical packages available on the network, so that they can
be used from any PC, and so they don't take disk space on every PC.

However, we don't have SITE licenses for these packages, we have a
limited number of copies that we've bought, and so a limited number
of licenses to use the software.  We are trying to stay legal by
limiting the number of copies of each licensed package that can be
running at a time.

Our current solution is rather clumsy (particularly for windows users),
and we are looking for software that can help us manage this problem.
I've found a couple of packages on the usual archive sites (Simtel, etc.)
but they have been specific to NOVELL networks, and that doesn't help us.

Are there ANY software packages that do licensing that will either
run on any kind of network, or are designed for a TCP/IP protocol
stack (perhaps using a winsock interface?)  I'd prefer a free or
shareware package, but am willing to consider commercial packages
as well.

-- 
     john nelson (jpn@genrad.com)

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Nov 1993 05:08:49 GMT
From:      thayne@unislc.slc.unisys.com (Thayne Forbes)
To:        comp.protocols.tcp-ip
Subject:   Re: Good books on TCP/IP for beginners

C.M. Leung (cml0464@ultb.isc.rit.edu) wrote:

: Can anyone recommend a good book for TCP/IP programming?
 
: I start to get a rough concept on different parts of TCP/IP and try to 
: catch up on more detail through Douglas Comer's book.  However, that book
: is slightly unreadable compared to others I have come across.  I have to
: agree it contains lots of detail on design and implementations and it seems
: that it's a struggle to get through some of the codes.  I guess I find it
: hard to connect to different parts in the book.

Two items.  I assume that you are refering above to volume two by
Comer and Stevens.  If not, get that book.  It has lots of code examples.
Also, for writing TCP apps, get volume three.  

Secondly, I find that Unix Network Programming by W. Richard Stevens
is a VERY good book.  I use it a lot.
-- 
Thayne Forbes         thayne@unislc.slc.unisys.com
Unisys Unix Support Engineering,    Salt Lake City.
Phone: (801) 594-4448          Fax: (801) 594-3827

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 1993 07:44:14 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Must a host handle ICMP redirects?

In article <ag129.382.2CDE49A8@ucs.cam.ac.uk> ag129@ucs.cam.ac.uk (Alasdair
Grant) writes: 
    Is there any standards requirement on a host to handle the ICMP 
    redirects it receives?  I.e. can a host throw them all away?

RFC 1122 has this to say about ICMP redirects:

         3.2.2.2  Redirect: RFC-792

            A host SHOULD NOT send an ICMP Redirect message; Redirects
            are to be sent only by gateways.

            A host receiving a Redirect message MUST update its routing
            information accordingly.  Every host MUST be prepared to
            accept both Host and Network Redirects and to process them
            as described in Section 3.3.1.2 below.

            A Redirect message SHOULD be silently discarded if the new
            gateway address it specifies is not on the same connected
            (sub-) net through which the Redirect arrived [INTRO:2,
            Appendix A], or if the source of the Redirect is not the
            current first-hop gateway for the specified destination (see
            Section 3.3.1).

I think that this is fairly clear.  I think that you should also suggest
that your vendor pay particular attention to this last paragraph.

Tony

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 1993 08:59:22 GMT
From:      wbn@quax.sp-media.de (Werner Brakemann)
To:        comp.protocols.tcp-ip
Subject:   Unknown Portnumber 5888

Hi,

does anybody know which service or program uses the portnumber 5888?.

Thanks in advance.

Werner Brakemann

-- 
+-----------------------------------------------------------------------+
+                                                                       +
+  S & P Media                                                          +
+  Werner Brakemann                                                     +
+                                                                       +
+  Gadderbaumerstr. 19                Tel. +49 521 1450313              +
+  33602 Bielefeld                    Fax  +49 521 1450350              +
+  Germany                            email  wbn@comic.sp-media.de      +
+                                                                       +
+-----------------------------------------------------------------------+

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Tue, 09 Nov 1993 10:59:07
From:      timmi@ftp.com  (Kitchen Staff Supervisor)
To:        comp.protocols.tcp-ip,biz.sco.opendesktop
Subject:   Re: NFS printers under SCO ODT 2.0

*| We are using SCO ODT 2.0 and Wollong Pathway 2.1.1 and Client NFS 1.2.1
*| (? not sure if that is correct -- either 1.2 or 1.2.1).  When we try to
*| mount a printer via NFS we find its not exported.  When I put a printer
*| in the /etc/exports file on the server, SCO barfs and pcnfsd dies when
*| I try to mount it.
*| 
*| What is the proper way to export a printer for NFS mount/printing?  TFM
*| doesn't give any clues.


In PNCFSD printing, as you say you're using, you do not export the
physical device.  You export a spool directory, and in the
/etc/pcnfsd.conf file you configure this spool directory and the
print method.  If you have the man pages, "man pcnfsd" will give you
the necessary information for SCO ODT 2.0.
--
Timothy G. Reynolds					FTP Software, Inc.
Technical Support					2 High St.
timmi-email@ftp.com					N. Andover, MA
(800) 382-4FTP							01845

  "I just want someone to say to me, 'I'll always be there when you wake'"


-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Nov 1993 09:46:57 GMT
From:      rmercer@cybercon.nb.ca (Ron Mercer)
To:        comp.protocols.tcp-ip
Subject:   ARCHIE client protcol specs

 I want to write an ARCHIE client for an ibm-pc does any one know where
I can find the protocol specification. I've looked in the RFC's but no luck.
Thanks.

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 1993 18:26:30 -0500
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple subnets on same physical wire

In article <2bkj8q$2uo@Notwerk.mcs.com> karl@Notwerk.mcs.com (Karl Denninger) writes:
>In article <2bk5kjINN5jb@cronkite.cisco.com>, Tony Li <tli@cisco.com> wrote:
>>In article <CFy4L2.Ipy@world.std.com> dpi@world.std.com (Mike Bloom) writes:
>>    1. Two subnets (e.g., 16.122.144 and 16.122.128) in the same building, each
>>       with many Unix workstation nodes.
>>Yes, this is legal.
>Legal but <highly> dangerous.  Sun machines, in particular, will fail in
>nasty ways with arp and broadcast storms if you are not <extremely> careful
>doing this.  The result will be cable meltdown, and it is not pretty.

I had this arrangement for a while, and the only problem the Suns had were
that routed complained "Packet from unknown router" every time it saw the
RIP broadcast from the router's "other" address.  This was solved by
putting an entry for the unknown router in the Suns' /etc/gateways files.

I also had to configure my cisco router to use a 255.255.255.255 broadcast
address rather than <network>.<subnet>.255, since the latter didn't work
when trying to broadcast to the secondary subnet.

>Sun gear can be made "safe" for this, but it requires non-standard kernel
>config options (at least with SunOS 4.x; no idea about Solaris 2.x)  I've
>had to do this on more than one occasion, usually for short term changes of
>configuration where you had to get new things up before tearing down old
>(like infrastructure -- cable plant, etc).

I never made any kernel changes for this, and my Suns were fine.  Are you
talking about using the Sun as the router between the two subnets?

>>    2. Two routers were configured as well, namely, one routed from subnet 144
>>       to 128 while the other routed from 128 to 144.  The routers were also on
>>       the same physical wire, I believe.
>>
>>This is strange, to say the least.  
>
>Also legal, but again, watch out for arp and broadcast storms!  It is
>possible to get redirect loopbacks in this situation if there is any 
>broadcast traffic on the wire (and there always is -- arps at minimum).

I don't see why ARP would have any particular problems.  Hosts will only
ARP for destinations they think are on the same subnet.  When talking to
hosts on the other subnet, they'll ARP for the gateway, and the gateway
will ARP for the destination, and everything should work fine.

I suppose there could be problems if you have machines configured with the
wrong subnet mask (e.g. using the class B mask rather than the site's
subnet mask), so they ARP for machines on the other subnet.  If the router
also does proxy ARP then both the router and the real host will respond to
the ARP query.

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 1993 18:46:54 -0500
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Must a host handle ICMP redirects?

In article <ag129.382.2CDE49A8@ucs.cam.ac.uk> you write:
>Is there any standards requirement on a host to handle the ICMP 
>redirects it receives?  I.e. can a host throw them all away?

RFC 1122, section 3.2.2.2: "A host receiving a Redirect message MUST update
its routing information accordingly."

>From my reading of RFC 792 nothing will go wrong if it does, just
>reduced performance.  For example is it acceptable for A to send
>a packet for B to G1, G1 to send an ICMP redirect for G2 back to
>A, and for A's very next packet to be one for B, still sent to G1.
>Say if A just had a finite table for redirects, is it allowed to
>fill it up until it's full or is there a requirement on it to use
>some kind of LRU strategy so recent redirects always get in the
>table?

Section 3.3.1.3 says, "The [route] cache needs to be large enough to
include entries for the maximum number of destination hosts that may be in
use at one time."  It then goes on to mention replacement stragegies using
LRU timestamps, use counts, etc.

>It is not my TCP/IP implementation - I am trying to get a vendor
>to fix theirs and I need the standards to back me up as they are
>taking it as 'design change' rather than 'bug fix'.

Many implementors consider implementing features required by the Host
Requirements RFC's to be design changes, since they designed their
implementations in accordance with the earlier RFC's.  There's not a whole
lot you can do about this.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Tue, 09 Nov 1993 13:07:59
From:      fks@ftp.com  (Frances K. Selkirk)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP's PC/TCP MS Win. Printing woes

In article <2apaac$409@epenviron.eapi.com> martinw@epenviron.eapi.com (Martin Walker) writes:

> >Wow, I think to myself, I know exactly what this is: the Ctrl-D hack in
> >Windows (I assume to attempt to flush any pending job from the printer).  
> >Even better, I know the solution: find the part in my WIN.INI that says
> >[Postscript, LPT1] and put a CtrlD=0 in there.  It even reiterates this
> >in the MS-Win readme file.  Cool enough.

Right line, wrong place. Putting CrtlD=0 under [Postscript, LPT1]
won't help. You need to actually create a section specific to your
printer type, and put the CrtlD=0 there! As an example, I commented
out:

  ;[PostScript,LPT2]
  ;ATM=placeholder
  ;CtrlD=0
 
and substituted:

  [QMS-PS 820,LPT2]
  ATM=placeholder
  CtrlD=0

I always use the QMS as a postscript printer.

--
Frances K. Selkirk		                                fks@ftp.com
FTP Software, Inc.       Technical Support            (800) 382-4FTP
---------------------------------------------------------------------
 Get our support newsletter from      | FTP support - support@ftp.com
 vax.ftp.com or our BBS (508-659-6240)| FTP sales   - sales@ftp.com


-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 1993 14:14:20 GMT
From:      hunenr@cis.corp.medtronic.com (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   Re: Must a host handle ICMP redirects?

In article <ag129.382.2CDE49A8@ucs.cam.ac.uk> ag129@ucs.cam.ac.uk (Alasdair Grant) writes:
#Is there any standards requirement on a host to handle the ICMP 
#redirects it receives?  I.e. can a host throw them all away?
#From my reading of RFC 792 nothing will go wrong if it does, just
#reduced performance.  For example is it acceptable for A to send
#a packet for B to G1, G1 to send an ICMP redirect for G2 back to
#A, and for A's very next packet to be one for B, still sent to G1.
#Say if A just had a finite table for redirects, is it allowed to
#fill it up until it's full or is there a requirement on it to use
#some kind of LRU strategy so recent redirects always get in the
#table?

From RFC 1122 [pp.40-41]:

         3.2.2.2  Redirect: RFC-792

            A host SHOULD NOT send an ICMP Redirect message; Redirects
            are to be sent only by gateways.

            A host receiving a Redirect message MUST update its routing
            information accordingly.  Every host MUST be prepared to
            accept both Host and Network Redirects and to process them
            as described in Section 3.3.1.2 below.

            A Redirect message SHOULD be silently discarded if the new
            gateway address it specifies is not on the same connected
            (sub-) net through which the Redirect arrived [INTRO:2,
            Appendix A], or if the source of the Redirect is not the
            current first-hop gateway for the specified destination (see
            Section 3.3.1).

Regards,
-Roger

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 93 15:21:31 GMT
From:      tisdall@amalthea.humgen.upenn.edu (James Tisdall)
To:        comp.protocols.tcp-ip
Subject:   inetd max connections?

I have a program that I'm starting as a server via /etc/inetd.conf and
/etc/services on Sun workstations.

I need to limit the number of simultaneous connections, to avoid trashing
the system.

Could some patient soul explain if this is possible/how to do it?

(My program is in the Perl language; but C code or whatever most welcome.)

Thanks,
Jim
======================================================================
James Tisdall
Departments of Genetics and Computer and Information Science
Computational Biology and Informatics Laboratory, Human Genome Project
510 Blockley Hall
University of Pennsylvania

tisdall@cbil.humgen.upenn.edu
215-573-3113
fax 215-573-3111
======================================================================

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Nov 1993 15:33:18 GMT
From:      mwr@eng.tridom.com (Mark Reardon)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Ethernet overload due to faulty TCP/IP implementations

In article <9311080956.AA58182@MacRickG>, Rick_Granberry@pts.mot.com (Rick Granberry) writes:
|> Steinar.Haug@runit.sintef.no (Steinar Haug) writes:
|> > 
|> > We had a rather interesting overload situation on our network a little over
|> > a week ago, and I thought I would share the experience with the rest of the
|> > net.
|> > . . .
|> > . . .
|> > A PC trying to start a telnet session to the broadcast address! The packets
|> > were transmitted to the Ethernet broadcast address, and also carried an IP
|> > broadcast address of 255.255.255.255.
 
|> > 2. Fortunately, most hosts ignored these packets. But a number of terminal
|> > servers (all from 3Com/Bridge) answered!
|> > . . .
|> > Furthermore, these terminal servers have another bug in their TCP/IP
|> > implementation: The answers from the terminal servers had the IP broadcast
|> > address (255.255.255.255) as *source* address.
|> > . . .
|> > However, it's obvious that the same
|> > problem could occur again, as long as some departments are connected to the
|> > backbone with bridges instead of routers. This incident certainly has served
|> > to strengthen my belief in a router-based instead of a bridge-based 
|> backbone.
|> 
|> Uh, what would be different?  Wouldn't the routers be passing packets sent to 
|> the IP broadcast addresses?  Furthermore, the routers would be connected to 
|> many networks, not just two, which would compound the situation.
|> 

No, the routers would block the broadcast since a broadcast is only sent to 
the local net.

Mark

-- 
_____________________________________________
Mark Reardon   AT&T Tridom   (404-514-3383)
email: mwr@tridom.eng.tridom.com, attmail!tridom!mwr

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Tue, 09 Nov 1993 18:33:08
From:      fks@ftp.com  (Frances K. Selkirk)
To:        comp.protocols.tcp-ip
Subject:   Re: Windows for Workgroups over TCP/IP

In article <CFyr1G.KIr@mdis.co.uk> mab@mdis.co.uk (Martin Bradford) writes:

> I think you are misunderstanding the original question. As I understand it,
> the question is if it is possible to run Windows for Workgroups using
> TCP/IP as its underlying transport mechanism rather than just concurrent
> with TCP. The native W4WG protocol is only really suitable for local area
> networking as far as I can see but, if it can actually run OVER tcp, then
> workgroups could span the world. This is something I have been looking for
> for some time and I would also be interested in any answers.

Windows for Workgroups can easily run over a TCP/IP NetBIOS. We've
had many customers doing this with our 2.22 NetBIOS, which can be
configured to send to hosts not on the local LAN.

--
Frances K. Selkirk		                                fks@ftp.com
FTP Software, Inc.       Technical Support            (800) 382-4FTP
---------------------------------------------------------------------
 Get our support newsletter from      | FTP support - support@ftp.com
 vax.ftp.com or our BBS (508-659-6240)| FTP sales   - sales@ftp.com


-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 93 17:22:07 GMT
From:      taschan@vipunen.hut.fi (Thomas S Aschan)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Multiple subnets on bridged network

Hello,

I'm having problems deciding whether to use a number of C class 
addresses or a subnetted B class address.

Let's assume a bridged network with more than 253 hosts. With the B 
class approach, I would be using multiple subnets with the mask 
255.255.255.0. The problem with this solution is, that all traffic 
between two different subnets, goes through the default router.

If the default router goes down, the subnets will be unable to 
communicate with each other. A solution would be to use a subnet mask of 
type 255.255.0.0.

Does somebody have experience with such a set-up? Any comments are
appreciated!


Cheers, Thomas

-----------------------------------------------------------
Thomas Aschan	taschan@vipunen.hut.fi
-----------------------------------------------------------

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Nov 1993 17:51:00 GMT
From:      ag129@ucs.cam.ac.uk (Alasdair Grant)
To:        comp.protocols.tcp-ip
Subject:   Re: Must a host handle ICMP redirects?

In article <2bnhoeINNpd9@cronkite.cisco.com> tli@cisco.com (Tony Li) writes:
>RFC 1122 has this to say about ICMP redirects:
>         3.2.2.2  Redirect: RFC-792
>            A host receiving a Redirect message MUST update its routing
>            information accordingly.  Every host MUST be prepared to
>            accept both Host and Network Redirects and to process them
>            as described in Section 3.3.1.2 below.

Thanks (and thanks to someone who e-mailed me too).  The vendor is now
claiming that since it does this until the table gets full, it is to spec.  
(After all, you can always make the table larger.)  I am trying to 
convince them that the word "cache" later on in this section of the RFC
is a definite requirement for it to throw away old rather than new entries.
--
Alasdair Grant

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Nov 1993 19:02:48 GMT
From:      jsundar@adobe.com (Jagane Sundar)
To:        comp.protocols.tcp-ip
Subject:   Re: Unknown Portnumber 5888

In article <2bnm5aINN143@quax.sp-media.de> wbn@quax.sp-media.de (Werner Brakemann) writes:
>Hi,
>
>does anybody know which service or program uses the portnumber 5888?.
	5888 is actually port 23(telnet) byte swapped. So, your
	problem is likely to be some Little Endian machine (such as a PC)
	with faulty software trying to make a TCP connection without
	setting the port number in network byte order.



	Jagane
>
>Thanks in advance.
>
>Werner Brakemann
>
>-- 
>+-----------------------------------------------------------------------+
>+                                                                       +
>+  S & P Media                                                          +
>+  Werner Brakemann                                                     +
>+                                                                       +
>+  Gadderbaumerstr. 19                Tel. +49 521 1450313              +
>+  33602 Bielefeld                    Fax  +49 521 1450350              +
>+  Germany                            email  wbn@comic.sp-media.de      +
>+                                                                       +
>+-----------------------------------------------------------------------+



-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Nov 1993 20:34:21 GMT
From:      brownje@ncifcrf.gov (Janet E. Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: Good books on TCP/IP for beginners

Have you seen Vol. IV of the Comer books? Also, I can't remember the 
title, but the author is Richard Stevens. I was fortunate to get into 
ione of his classes and his books are excellent. 



-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Nov 1993 20:42:49 GMT
From:      brownje@ncifcrf.gov (Janet E. Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: Tcp Push?

Nope - just the opposite. Push forces the implementation to transfer 
data even if the buffer is only partially full. When I've seen Push 
implemented, it's been in an error situation where there is either 
OOB data or  Error detection. Push also forces the receiver to 
respond immediately, regardless of what state it's in. If you are not 
experiencing errors, the delay you see may be due to buffer recovery 
and state synchs. If you are in an IBM mainframe environment, screen data 
must be reconciled. 

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 93 21:23:45 GMT
From:      karthik@informix.com (Karthikeyan Guruswamy)
To:        comp.protocols.tcp-ip
Subject:   Packet Driver on WinSock

Hi,
I know this is going too far - But is it possible to make a 
packet-driver written for Winsock on a DOS Box ? This will solve
a panacea of problems right from running all kindsof tcp/ip,
telnet, even Novell shell on NT or DOS Box. Am I dreaming or
nobody thought about it ? ;-).

Karthik 
---------------------------------------------------------------
Karthik						
Infosoft Inc, (Contractor to INFORMIX Inc.)
Cupertino, CA

' Help ! I'm a Novell fan ! '

All the views expressed here are solely mine and they dont 
represent those of my organization.
---------------------------------------------------------------

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 93 22:09:15 GMT
From:      wyl@mahoosuc.NSD.3Com.COM (Y. Alan Wang)
To:        comp.protocols.tcp-ip
Subject:   CMU PCIP


Does anyone know where a public server that I can download this PCIP source?

Thanks.


-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Nov 93 22:23:57 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: Unknown Portnumber 5888

In article <2bnm5aINN143@quax.sp-media.de> wbn@quax.sp-media.de (Werner Brakemann) writes:
>Hi,
>
>does anybody know which service or program uses the portnumber 5888?.
>
>Thanks in advance.
>
>Werner Brakemann
>

	None, that I know of. However, 5888 is a byte swapped 23
(5888=23*236), and 23 is the telnet port. So perhaps that is a telnet
connection, and your netowrk monitoring software/application that gave
you that port number is confused about endianness. I've seen a remote
netstat via SNMP do this on a DECstation (telnets would show up as
5888), etc. You can manually fix the endianness of "mystery" numbers
such as this, but fixing the endian problem in the software, etc would
help more in the long run in reducing confusion.


-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 93 22:48:58 GMT
From:      pirate@cbnewsf.cb.att.com (martin.p.mcenroe)
To:        comp.protocols.tcp-ip
Subject:   Who does IGMP?

Background:

We have a need to send data from a set of sources to another set
of destinations.  A solution which includes TCP/IP is preferrable.

I am reading in D.E.Comer vol I, about Internet Group Management
Protocol (IGMP).  It is not blatantly obvious that every IP device
supports this protocol.  

Queries:

What devices support IP multicasting?
Will this work over brouters?
What are some other alternatives to setting up a routine 1 to many
(select set) broadcasts?  I'm thinking now about the etherfind
command available with SunOS 4.1.3.

Oh, by the way, data integrity is super-important.  

Notes:

I will be pulling relevant RFCs in the near future so that advice
will have already been heeded.

I would appreciate a mail reply in addition to a posting.  You can
try "marty@taz.att.com" but you might get a message to try
"m.p.mcenroe@att.com"


Marty McEnroe
908-949-8696

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Nov 1993 23:01:50 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Good books on TCP/IP for beginners

In article <CG8rt9.3GA@ncifcrf.gov>, brownje@ncifcrf.gov (Janet E. Brown) writes:
> Have you seen Vol. IV of the Comer books? Also, I can't remember the 
> title, but the author is Richard Stevens. I was fortunate to get into 
> ione of his classes and his books are excellent. 

	This isn't correct. There is no volume IV in the "Internetworking with
TCP/IP" series (but there *are* two volume III's-- socket and TLI versions).
	And another common mistake-- I am *David* Stevens, co-author on vols
II and III of the series. I don't think we've ever been seen in the same place
at the same time, but I'm pretty sure W. Richard Stevens is another person
entirely, who also writes books on networking, and also for Prentice Hall.
	I'd guess the book you had in mind is "UNIX Network Programming",
Prentice Hall, 1990, ISBN 0-13-949876-1.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Nov 1993 23:41:46 GMT
From:      scott@zmax.com (Scott Wallace)
To:        comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Public Domain Tooltalk Clone

Greetings Netters,

I'm looking for a public domain tool which will run using tcp-ip
with capabilities similar to tooltalk.

  The reason I don't want to use tooltalk is that it's not widely
ported enough yet, and I only want to exchange messages between
different processes in the application I'm writing. I'd prefer not
to have to use System 5 type shared memory or message queue based
methods of sharing info between processes.

  If at all possible, I'd like to have a socket open to a server
which can handle receiving and distribution of given messages.

Has anyone seen/written something along these lines?

Please respond via e-mail to scott@zmax.com since I don't always get
time to read these groups.  If people are interested, I'll post
a summary.

Thanks in advance,

Scott Wallace
Z/Max Computer Solutions Inc.
Baldwinville, NY.


-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 1993 02:08:13 GMT
From:      warlock@csuchico.edu (John Kennedy)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: Multiple subnets on bridged network

In article <taschan.752865727@vipunen.hut.fi>, Thomas Aschan wrote:

-->  I'm having problems deciding whether to use a number of C class 
-->  addresses or a subnetted B class address. ...
-->  If the default router goes down, the subnets will be unable to 
-->  communicate with each other. A solution would be to use a subnet
-->  mask of type 255.255.0.0.

  I strongly urge you to subnet, although not necessarily as a C-class
(255.255.255.0 == 0xFFFFFF00).  Try and figure out how many subnets you
might reasonably need per router interface, double it if practical, and
subnet using that value.  On my campus, I allocate about four subnets/
building, and I _really_ wish I could have gotten there before the
numbering was established.  (:  I could have used a subnet mask of, what?
0xFFFFFC00 I think.  That would have given me two more bits in the subnet
mask on top of my 8 bits, letting four C-class subnets talk to each other
locally without going through the router.

-- 
 John Kennedy <warlock@csuchico.edu>;   Communications Services;   USENET admin

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Nov 93 02:55:50 GMT
From:      kong@bream.mel.dit.CSIRO.AU (Alan Kong)
To:        comp.protocols.tcp-ip,comp.protocols.snmp,aus.net.aarnet
Subject:   Caching in DNS



I am looking for information/articles on how caching is being used to improve
the  performance of DNS, could someone please give me some suggestions.

Thanks in advance.


Reagrds - ALan


:---------------------------------------------------------------
:Alan Kong
:CSIRO Division of Information Technology
:723 Swanston St. Carlton Vic. Australia
:Phone: +61 3 282 2616 (voice)      Email: kong@mel.dit.csiro.au
:       +61 3 282 2600 (fax)
:---------------------------------------------------------------

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 1993 11:22:40 -0500
From:      cmetz@thor.tjhsst.edu (Craig Metz)
To:        comp.unix.programmer,comp.unix.bsd,comp.protocols.tcp-ip
Subject:   Raw IP sockets: How does one set TOS?

	I am trying to write some code that requires raw IP access using the
BSD sockets interface. However, I'm having a bit of trouble setting the Type
Of Service field in the IP header on the socket. The offending line is:

setsockopt(ip_socket, IPPROTO_IP, IP_TOS, (char *)(&protocol_num), 
	sizeof(protocol_num));

	This returns EPERM running as the superuser. Could someone suggest a
fix for this or what I'm doing wrong?

								Thanks,

								-Craig

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 1993 14:29:50 +0800
From:      dinesh@bass.my (Dinesh Arnold Nair)
To:        comp.protocols.tcp-ip
Subject:   Re: Service port #s in inetd.conf???...

In article <CFtqx3.KJD@tandem.com> sharmila@forge.Tandem.COM (Sharmila Podury) writes:
>
>
>Does anyone know why the entries for each service
>in the inetd.conf file do not contain the port numbers?
>Is there a reason why one would not want to put the 
>port numbers in inetd.conf?
>
>Answers would be greatly appreciated.
>
>Thanks.
> 
>-- 
>PODURY_SHARMILA@Tandem.com

Check inetd.conf(5). Basically, the first field of /etc/inetd.conf should
match a valid entry in /etc/services. The port numbers for the particular
service is taken from there so they don't have to be in /etc/inetd.conf.

Hope this helps.

#include <std/disclaimer.h>        /\_/\   "All dogs go to heaven."
                                   (0 0)
+==========================----oOO--(_)--OOo----============================+
| Dinesh Nair (dinesh@bass.my)     /    Surface Address :                   |
| Software Engineer                \    9th Floor, Menara SMI,              |
| Technical Services Group         /    6 Lrg P Ramlee, 50250 Kuala Lumpur  |
| BASS Consulting                  \    Malaysia.   Tel : +603-2305588      |
+===========================================================================+

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Nov 93 03:52:27 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   multiple subnets on same physical wire

In article <2bk5kjINN5jb@cronkite.cisco.com>, Tony Li <tli@cisco.com> wrote:

   In article <CFy4L2.Ipy@world.std.com> dpi@world.std.com (Mike Bloom) writes:
       
       A very brief question: is it legal/possible to have several subnets share   >>    the same piece of physical thinnet cable?  A test customer of mine had    the
       following arrangement, but I'm not sure that it was legal:
       
       1. Two subnets (e.g., 16.122.144 and 16.122.128) in the same building,    each
          with many Unix workstation nodes.
   
   Yes, this is legal.

Legal yes, but everyone must be running a TCP/IP package that knows
how to deal with ICMP redirects and/or RIP.  Otherwise, you'll always
be transmitting *to* your default route(r), which will send back an
ICMP redirect (which you'll ignore), and re-send the packet to the
right host.  Triple the outgoing traffic.

-russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support.
11 Grant St.      | 315-268-1925 (-9201 FAX)       | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 1993 17:17:09 -0500
From:      martinw@epenviron.eapi.com (Martin Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: thin -vs- RJ-45 concern. Advice sought.

tburns@magnus.acs.ohio-state.edu (Timothy A N Burns) writes:

>I am in the process of equiping a classroom lab.  What I have is 24 intel-based
>PCs, and 2 RJ-45 wall jacks (which are connected to an 8 port hub ~100ft away.)

we use tp for everything - it works great and is cheap.  it's a lot cheaper
than coax to buy and have someone pull.  you just have to be careful about
what you pull it near (EMI/RFI considerations).  also, make sure that you
use good (cat4 or 5) wall jacks, wire etc - don't use the flat satin type
wire.  tp is much more flexible should you want to do something else later.
the one thing that coax has over tp is the distance.  however we have
found that by using decent SHEILDED 22 awg TP cable and grounding ONE end
of the foil (ours is actually shielded in pairs and then again for the
whole cable) we can get 1000' over 10BaseT

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Nov 93 09:48:59 GMT
From:      jc6562@albnyvms.bitnet
To:        comp.protocols.tcp-ip
Subject:   VMS telnet-client

Hi, anyone know a vms telnet-client that is closely related to
the one on unix systems?  Our school changed our old telnet-client
to Client-telnet V3.1-3.  The problem I have with this is that 
newlines received doesn't always show new lines.  And when I hit the
delete key nothing on the screen changes but the string sent is 
affected.  Any client that doesn't do much checking of the send/rec
is fine since I have no need for it.  thanks.  Please reply in
Email to cc2955@albny1.albany.edu

		

	
Thanks

						Charley

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Nov 1993 11:53:39 GMT
From:      mab@mdis.co.uk (Martin Bradford)
To:        comp.os.ms-windows.setup,comp.os.ms-windows.misc,comp.protocols.tcp-ip
Subject:   Re: Windows for Workgroups over TCP/IP

Thomas Beagle (thomas@datamark.co.nz) wrote:
: In article <CG0uE1.F25@mdis.co.uk> mab@mdis.co.uk (Martin Bradford) writes:
 
: >: They have LanManager running on the HPUX box with an ethernet
: >: consisting of LanManager clients, all using TCP/IP as the transport.
 
: >: Then, using the WinSock that's part of WfWG TCP/IP we installed
: >: WinQVTNet 3.94 for WinSock on the client PC. This then gives them
: >: Telnet, Mail, News, etc, etc.
 
: >	Can we just clarify this because it sounds like it might be what
: >we are looking for. Are you saying if you have two lans set up as you
: >describe and each of them were gated into the Internet (as we are) then
: >workstations on one lan could make use of the W4WG facilities (e.g. Clipbook,
: >distributed DDE etc) to workstations on the other lan (possibly on the other
: >side of the world)? You only mention file transfer to/from the server which
: >is not the same thing at all.
 
: There aren't two LANs, only one. This LAN has Lanmanager as the server
: and WfWG as the client PC software. They don't have an internet link,
: but there's no reason why they couldn't. (They do have a remote site
: but that uses bridges rather than routers.)
 
: >	I know that it is quite easy to make W4WG coexist with tcp - we run
: >like that all the time, but we would like to be able to interact with
: >workgroups all over this country (or the rest of the world).
 
: It's not a case of WfWG coexisting with TCP/IP - it's using TCP/IP as
: the transport. Therefore all the normal routers, name servers, and so
: on should all work with WfWG just as they do with any other TCP/IP
: networking software. The router doesn't know what networking software
: you're running, it just knows how to move TCP/IP packets around.
 
: Or so I understand it anyway.
 
: -- 
:    Thomas Beagle |    ,__o    Faster and faster until the thrill of speed 
: Technical Writer |  _-\_<,    overcomes the pain of long ears flapping
:   Wellington, NZ | (*)/'(*)   in the wind.          thomas@datamark.co.nz

Are there not problems with workstation addressing in that scenario? As I
understand it, each Windows 4 Workgroups workstation periodically broadcasts
an "I am here" message which the others pick up to supply the addressing list 
etc. This works ok on a small lan but would cause havoc across the global
internet. In the absence of such a mechanism, how do you address workstations
on a remote lan?



-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Nov 93 09:01:16 RSA
From:      047NAIL@Witsvma.wits.ac.za
To:        comp.protocols.tcp-ip
Subject:   Help on SLIP for NeXTStep for 486 intel implementation

A colleague of mine without usenet or internet connectivity has asked
me to post the following question:
Is there a SLIP for NeXTStep for an 486 intel implementation available?
Many thanks, Paul Nailand, Internet: 047nail@witsvma.wits.ac.za
 

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Nov 1993 13:25:12 GMT
From:      thomlins@sol.acs.unt.edu (Thomlinson John R)
To:        comp.protocols.tcp-ip
Subject:   Can anyone there help lan/tcp-ip installation?


Does anyone have a set of SIMPLE instructions on how to get TCP software
running at the same time as a Novell 3.11 LAN? I'm quite stupid, and I'm 
having trouble.  A number of kind souls have helped me here and there, 
each with a bit of advice.  Unfortunately, the bits don't all go
together.  I have lsl.com, ne2000.com, ipxodi.com from novell.  I forget
where odipkt.com came from.  The telnet/ftp software is CUTCP from 
Clarkson U.  I also have ne2000.com as a packet driver from U. Minn 
(I think that's where that came from).

Running the packet-driver "ne2000 0x60" means I can run CUTCP.

Running "lsl ne2000 (from Novell) ipxodi netx" means I can run the LAN.

I can't do both.  Packet-driver ne2000 won't let me load the LAN, and
Novell ne2000, even with odipkt loses my TCP capabilities.

What I need is a) a sequence of the programs and arguments I need
               b) which versions, and where to get them
               c) what needs to be in net.cfg (and config.tel maybe)
               d) what needs to be done to the server

Our LAN manager (a position that was given to her whether she wanted it
or not) is as lost as I am.

If anyone has experienced and solved this problem, and could communicate
same to a biologist who knows just enough about computers to be 
dangerous, he or she would have my undying gratitude.  I'm stumped.

Thanks,
     John Thomlinson

thomlins@sunceer.upr.clu.edu    or
thomlins@sol.acs.unt.edu

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 1993 22:45:32 -0500
From:      philp@universe.digex.net (Phil Perucci)
To:        comp.os.ms-windows.setup,comp.os.ms-windows.misc,comp.protocols.tcp-ip
Subject:   Re: Windows for Workgroups over TCP/IP


For another $49.00, we got an unlimited license for the Microsoft TCP/IP
layer.  Does the WFW stuff over TCP/IP, but the only utility you get is 
ping.  No telnet/ftp just the WFW client/server stuff.  I use it whenever
I have to use a spreadsheet or word-processor on the NT server at work.

Normally I boot up Linux and use it as an X-terminal.

-- 
==============================================================================
 Phil Perucci             | "All postings are my own opinion - all comments
 Systems Programmer       |  are intended for research/educational purposes"
==============================================================================

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Nov 1993 15:34:36 GMT
From:      nguyen@PHUONG.raleigh.ibm.com (Phuong Thanh Nguyen)
To:        comp.protocols.tcp-ip
Subject:   Re: Good books on TCP/IP for beginners

In article <CG8rt9.3GA@ncifcrf.gov>, brownje@ncifcrf.gov (Janet E. Brown) writes:
|> Have you seen Vol. IV of the Comer books? Also, I can't remember the 
|> title, but the author is Richard Stevens. I was fortunate to get into 
|> ione of his classes and his books are excellent. 
|> 
|> 
	I don't think there is Vol IV of Comer books yet.  About the book
of Richard Stevens has the title "UNIX Network Programming" .  There is
a new Richard Steven's book title "Network Illustrated" is going coming
out in December if I'm not mistaken.  I expect this one is going to be
a good one for network programming based on the impression I got from his
"UNIX Network Programming".

Phuong Nguyen
-- 
--------------------------------------------------------------------------
| Disclaimer: This idea belongs to nobody but me. What I think is what I |
|             guess is what I imagine, so it can't be sure.              |
| Hope you have a "phuongtastic" day                                     |
| Internet: PNGUYEN@VNET.IBM.COM                                         |
--------------------------------------------------------------------------

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Nov 1993 16:03:43 GMT
From:      lmd@cayman (Luis Delgado)
To:        comp.protocols.tcp-ip
Subject:   Can't run PC/TCP with windows

Hello:

I'm experiencing some performance problems with PCTCP 2.2 while running
windows 3.1.

When I run PCTCP (telnet for example) in DOS, over a SLIP connection, the
performance is more than satisfactory, but when I run it in windows, it
freezes (the telnet program- TN) as soon as I'm logged in at the remote node.

So I think, this sould be a windows configuration problem.

My configuration is:

A PC DECstation 386SX/16 (rather slow I know...) with a codex 3266 modem (14.4k)
connected via an internal PBX to another similar codex modem connected to a
Telebit Netblazer 40 (SLIP server). I'm using a maximum of 38400 bps.
My PCs serial port COM1 (the one being used for communication) has a       
UART 16550A, being used by the PCTCP packet driver. 
I don't think, even the PC being rather slow, that the problem should be due to
the serial ports performance, since has I said before, in DOS, not performance
problem arises. Only in windows 3.1.

I've only tried to ajust de parameter COM1BUFFER to several values, from 2048
to 8192 and nothing changes.

Does anybody had this kind of problem ?

I would apreciate any help from you guys.

Best Regards,
Luis Delgado, email: lmd@inesc.pt
INESC, Lisbon-Portugal

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Nov 1993 16:24:21 GMT
From:      aboba@netcom.com (Bernard Aboba)
To:        comp.protocols.tcp-ip
Subject:   ARP table?

I am in a situtation where I have many PCs on a network, and suspect
that I have a problem with my ARP table. Since there are many varieties
of network adapaters in use, it would help for me to have a listing of
all the vendor's Ethernet address assignments, so I can match the IP
addresses against what SHOULD be in the ARP table. 

Does anyone know if such a listing is available somewhere on the net? 


-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Nov 1993 16:30:52 GMT
From:      lmd@cayman (Luis Delgado)
To:        comp.protocols.tcp-ip
Subject:   Re: Can't run PC/TCP with windows

oh !! I forgot to tell you about my PCTCP configuration, that I'm runnign 
windows in enhanced mode, and also, that I have in my PCs system.ini,
the following lines:

Com1AutoAssign=0
Com1Base=0
Com1IRQ=-1

in order to avoid serial port conflicts with windows. COM1 serial port is
controlled obviouslly by the PCTCP packet driver slp16550.

I would apreciate any help.
Best Regards.
Luis Delgado, e-mail: lmd@inesc.pt
INESC, Lisbon-Portugal.


-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Nov 1993 18:21:07
From:      rlovelad@netbsd08 (Ross Lovelady)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Changing the Login Drive in a Novell FileServer

In article <1993Nov8.135511.55413@kuhub.cc.ukans.edu> rsl11@kuhub.cc.ukans.edu writes:
>From: rsl11@kuhub.cc.ukans.edu
>Subject: Changing the Login Drive in a Novell FileServer
>Date: 8 Nov 93 13:55:09 CDT
 
>1. How can I change the drive letter of the login drive from f: to any other
>letter, say h:? I have tried the command map but it did not get rid of f:.
>Note that before logging onto the Novell fileserver I already have drives
>f: and g: that are already assigned to a stacker drive and ramdrive.
>Is there a way maybe to assign a different letter to ramdrive? To stacker?

Put LASTDRIVE=G (no colon) in the CONFIG.SYS file and your login drive should 
be H:.

Bye
Ross

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 1993 17:33:55 GMT
From:      maf@dunedin.acs.ohio-state.edu (Mark Fullmer)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple subnets on same physical wire

In article <752903547snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
>In article <2bk5kjINN5jb@cronkite.cisco.com>, Tony Li <tli@cisco.com> wrote:
>
>   In article <CFy4L2.Ipy@world.std.com> dpi@world.std.com (Mike Bloom) writes:
>       
>       A very brief question: is it legal/possible to have several subnets share   >>    the same piece of physical thinnet cable?  A test customer of mine had    the
>       following arrangement, but I'm not sure that it was legal:
>       
>       1. Two subnets (e.g., 16.122.144 and 16.122.128) in the same building,    each
>          with many Unix workstation nodes.
>   
>   Yes, this is legal.
>
>Legal yes, but everyone must be running a TCP/IP package that knows
>how to deal with ICMP redirects and/or RIP.  Otherwise, you'll always
>be transmitting *to* your default route(r), which will send back an
>ICMP redirect (which you'll ignore), and re-send the packet to the
>right host.  Triple the outgoing traffic.

Actually it's worse than this since the router can't send ICMP redirects.
It would need to be an ARP redirect, which ofcourse doesn't exist.

Using RIP sorta works, but the clients need to listen to the RIP  
advertisements from the router, then install those routes as local routes.
I did this once - the problem is it won't work for DOS machines, that
can't run routed.

It's easier in the end to just change the subnet mask to have the hosts
think they can talk to the entire network, then have the router do proxy
arp for the subnets on the 'other' ports.

--
mark
maf+@osu.edu

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Nov 93 18:33:33 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   CMU PCIP

In article <2216@bridge2.NSD.3Com.COM> wyl@mahoosuc.NSD.3Com.COM writes:

   Does anyone know where a public server that I can download this PCIP source?

Most recently-modified version is on netlab1.usu.edu, pub/pcip.

-russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support.
11 Grant St.      | 315-268-1925 (-9201 FAX)       | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 1993 19:00:32 GMT
From:      babb@sciences.sdsu.edu (Jeff Babb)
To:        comp.protocols.tcp-ip
Subject:   ATM Group?

Fellow Netters,
  I did a search on all groups with the substring   atm   in their name. I
got alt.comics.bATMman!! Is there an Asynchronous Transfer Mode group out
there that my nntp server just isn't aware of? Or is it time we established
the group? If its time to establish the group, perhaps the name could
contain something other than     atm    in it so that we wouldn't get a lot
of traffic inquiring about automatic teller machines, eh?  :-)

Jeff.

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Nov 1993 19:11:26 GMT
From:      rgallen@muug.mb.ca (Rennie Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting Class C Addresses - again

In <2bm25s$7m@obelix.tsg.com> whalenm@obelix.tsg.com (Matthew Whalen) writes:

>I know this was discussed a fair amount recently, and I know that it
>it possible to do, so what I am looking for are suggestions.  Should
>we attempt to subnet our class c networks, or should we simply request
>a couple more class c networks and not use a lot of the addresses?

If the number of hosts you have can be handled by subnetting your class C
address, by all means do it.  IP addresses are a limited resource and anyone
who hogs them unnecessarily should be shot and pissed on (not necessarily in
that order).

email: rgallen@muug.mb.ca              mail:  Expert Technology Corporation   
QUICS: rgallen (613) 591-0934                 34 Riverstone Rd. 
Voice: (204) 339-8005                         Winnipeg, Manitoba, Canada R2V 4B2
Fax:   (204) 488-5943

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 1993 20:09:00 GMT
From:      tburns@magnus.acs.ohio-state.edu (Timothy A N Burns)
To:        comp.protocols.tcp-ip
Subject:   thin -vs- RJ-45 concern.  Advice sought.

I am in the process of equiping a classroom lab.  What I have is 24 intel-based
PCs, and 2 RJ-45 wall jacks (which are connected to an 8 port hub ~100ft away.)

I need to network (strictly TCP/IP today) the 24 PCs. Should I

a) stick a 32-port hub in the room, connected via twisted pair to the wall, 
then each PC to a port on said hub. (managed or not?)

b) twisted pair from wall to BALUN to thin coax from which I T-off each PC, 
thus requiring BNC enet card (vs RJ-45 enet cards for option (a))

c) T-off a coax from phone closet to classroom (not use RJ-45, or twitsted 
pair) and run thin to each PC as in choice (b)

d) try (b) whence I find out said BALUN does not work, go with (c).

I am unsure of any benefits of TP vs thin in this case.  The lab I use as a 
model is like (c), except there was no exsisting TP in the wall.  Also I 
currently have 1 of the 24 PCs plugged in via TP.  Any limitations or concerns 
I have not considered , I appreciate ALL advice.

THanks

tim+@osu.edu

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Nov 1993 20:58:22 GMT
From:      brownje@ncifcrf.gov (Janet E. Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: Good books on TCP/IP for beginners

Yikes! you're right - I need to brush up on my Roman Numerals. It 
is Volume III - "Client-Server Programming and Applications".  I see 
your name on the cover - good to know that you are on the net.  There
is another person named Richard Stevens - many people on the net have posted 
the name of his book. Thanks for the correction - the series is our bible. 



-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Nov 1993 21:28:52 GMT
From:      Ran Atkinson <atkinson@itd.nrl.navy.mil>
To:        comp.protocols.tcp-ip
Subject:   Internet Operations Task Force (IOTF)

Hello,

  There has recently been some discussion within the Internet
Engineering Task Force (IETF) about spinning off a new group "Internet
Operations Task Force (IOTF)".  The IETF is the group of people who do
protocol engineering for the Internet (e.g. TCP, IP, UDP, Telnet, SMTP
Email, SNMP, etc).  T he IOTF would be operationally oriented rather
than oriented around protocol engineering.

  The IOTF concept isn't fully defined yet but would provide a forum
for network operations people to come together and work on technical
issues relating to network operations and might provide a joint home
for some of the inter-network coordination activities that are already
going on.  

  The IOTF would be under the existing and widely-recognised Internet
Society &/or Internet Architecture Board framework.  It is intended as
a home for people running campus networks, company networks,
commercial networks, private networks and basically any
Internet-oriented network.  For example, Novell SPX/IPX would probably
not be a focus, but coexistence between Novell SPX/IPX and the
Internet's TCP/IP might arise as a topic.

  The main important open question is how many network operations
folks would be interested in actively participating (both via Email
and via occasional attendance at IOTF meetings {in the manner of and
possibly co-located with IETF meetings}).  If enough people are
interested, then something will likely happen.  If only a few people
are really interested, then the idea probably isn't worth persuing.

  This will likely be discussed at the Seattle, Washington (USA) IETF
meeting in early March, but I'm trying to gauge interest in the mean
time.  If you're seriously interested, please send me an email that
says you're interested in the IOTF and also send me your name and
email address.  Note that I'm not influential or a decision-maker,
just an unofficial data collector. :-)

  Discussion of what the IOTF should be and do might be appropriate 
for this newsgroup though some discussion is happening on the IETF
mailing list. 

  I've forwarded (with explicit permission) a note from Jon Postel
that relates to this topic for your information.

  Ran
  atkinson@itd.nrl.navy.mil

[forwarded note follows]
----------------------------------------------------------------------
 Date: Wed, 10 Nov 1993 10:42:31 -0800
 From: Jon Postel <postel@isi.edu>
 Message-Id: <199311101842.AA23468@zephyr.isi.edu>
 To: ietf@isi.edu, iab@isi.edu
 Subject: Re: Internet Operations Task Force concept

Hi.

Several good points have been raised about an IOTF, i think there is
room for discussion.  I've suggested that the IAB could (if it got
it's act together) help set up an IOTF.

There are repeated calls for something more in the operation area.

We need to find people that want to do the work, and they must be
people who do operations stuff in their real job.

There are already groups that are already involed in this area (IEPG,
regional-techs, etc).  An IOTF should not ignore these groups, but
rather give them a home and a means of further coordinating.

So if helping to create a framework where existing groups get more
recognition as being in charge of operations, and if it helps them to
coordinate even better, then lets do it.

The network operators have to be on board, they have to want and
participate in the IOTF.  If they don't want it and/or don't
participate there is no point in doing it.

I think the IAB's role is to help get it set up.  I also think that if
the governance procedures are parallel to the IETF, then the IOTF
ought to have some influence on who is on the IAB, just as the IETF
does.

So i think we need to hear from the real network operators: do you want
an IOTF or not ?

--jon.
----------------------------------------------------------------------

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 1993 21:33:12 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple subnets on same physical wire

In article <752903547snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:

    Legal yes, but everyone must be running a TCP/IP package that knows
    how to deal with ICMP redirects and/or RIP.  Otherwise, you'll always
    be transmitting *to* your default route(r), which will send back an
    ICMP redirect (which you'll ignore), and re-send the packet to the
    right host.  Triple the outgoing traffic.
    
Intelligent (and correctly configured) routers will notice that the source
and the next hop are not on the same subnet, and will not send a redirect.

Tony


-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Nov 93 22:51:50 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   RE: ATM Group?

In Article <babb-101193105416@larc.sdsu.edu>
babb@sciences.sdsu.edu (Jeff Babb) writes:
>  I did a search on all groups with the substring   atm   in their name. I
>got alt.comics.bATMman!! Is there an Asynchronous Transfer Mode group out
>there that my nntp server just isn't aware of? Or is it time we established
>the group? If its time to establish the group, perhaps the name could
>contain something other than     atm    in it so that we wouldn't get a lot
>of traffic inquiring about automatic teller machines, eh?  :-)

A definite FAQ. comp.dcom.cell-relay

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov		(510) 422-6955

Disclaimer: Being a know-it-all isn't easy. It's especially tough when you
don't know that much. But I'll keep trying. (Both)

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Nov 1993 00:26:47 GMT
From:      plate@cdsmn.mn.org (Doug Plate)
To:        comp.protocols.tcp-ip
Subject:   Is There a POP3 server for SystemV ?


I am looking for a POP3 mail server for my System V system,
specifically Interactive UNIX System V/386  Release 3.2.
Everything I've looked at so far is very BSD and I lack the
skill to port the software.  If anyone can point me to some
software or even give me tips on how I might port some software,
please drop me a note.

Regards,
Doug Plate Sr.
plate@cdmsn.mn.org

-- 
      ()(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)*(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)()
     /                    plate@cdsmn.mn.org                           \
   /         /      Doug Plate Sr.    | "Assume no malice!"   \          \
 (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Nov 1993 02:56:01 GMT
From:      varney@cbnewsd.cb.att.com (Al Varney)
To:        comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: ISDN (was Re: X.25 through tcp-ip)

In article <1993Nov4.131801.8671W@lumina.edb.tih.no> ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
>In article <2b90oa$fus@pyrnova.mis.pyramid.com>, 
>lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:
>
>>   No, I knew I pushed that button.  The button was aimed at the
>>   computer network types you mention....as well as those who
>>   assume ISDN is a single layer and leave it at that.
>
>Counting layers is a matter of definition. If you look in the 
>I-standards, you'll see that B channels are in fact described
>as a single "layer 1". D channels are described as layers 1, 2
>and 3 (they are explicitly *not* named like the OSI layers,
>just identified by their numerical designations).

   So when the two B-channel layer 1's and the D-channel layers are
segmented into chunks on the T-interface, and then stacked onto
the "U" interface, how many layers are there?  It's obvious that
the OSI Ref. Model is very much packet-oriented, and attempts to
"link" the Model to other non-packet communications, such as circuit-
switched data, are just mental exercises.  Perhaps for new protocols,
the Model may help in the definition stage, even where it is unsuited
for the actual protocol description.  But for much of telecommunications,
OSI constrains solutions and breeds inefficient interfaces.

   Even packet-oriented services, such as SS7, can be (and were)
designed without the Model in mind.  Attempts to warp SS7 into the
Model are only useful in helping those who understand the Model get
a "feel" about SS7.  Some problems in SS7 protocol evolution are
due to people thinking SS7 was OSI-like, or should be.

   But the model is not well-suited to non-packet "layerings", and
can get in the way of understanding.  Try linking the OSI Model to
the existing SONET protocol, for example, or the DS1 interface.

>Switching a B channel is roughly the same as the function of a 
>plug managed by human operators in pre-WW2 crossbar phone 
>switches. You wouldn't consider that plug 4-layered, would you?

   Hmmm, well, there's the brass layer, and the solder, and then
the precious-metal coating.  Guess oxide could be layer 4.  Hot Dog!
The OSIRM can even describe switchboards!!  :)

Al (don't OSI me) Varney -- my opinion only

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Nov 1993 03:07:57 GMT
From:      thomas@datamark.co.nz (Thomas Beagle)
To:        comp.os.ms-windows.setup,comp.os.ms-windows.misc,comp.protocols.tcp-ip
Subject:   Re: Windows for Workgroups over TCP/IP

mab@mdis.co.uk (Martin Bradford) writes:
>
>: It's not a case of WfWG coexisting with TCP/IP - it's using TCP/IP as
>: the transport. Therefore all the normal routers, name servers, and so
>: on should all work with WfWG just as they do with any other TCP/IP
>: networking software. The router doesn't know what networking software
>: you're running, it just knows how to move TCP/IP packets around.
 
>Are there not problems with workstation addressing in that scenario? As I
>understand it, each Windows 4 Workgroups workstation periodically broadcasts
>an "I am here" message which the others pick up to supply the addressing list 
>etc. This works ok on a small lan but would cause havoc across the global
>internet. In the absence of such a mechanism, how do you address workstations
>on a remote lan?

Well, I've just been reading the Microsoft Technet CDROM and I am now
starting to worry about exactly this issue. It shouldn't matter at the
client I've been working with - they don't have an internet connection.

[The following is a little hazy due to my incomplete knowledge...]

Well, it lookes to me as though you won't be able to share NetBios
(WfWG and LanManager) resources over the Internet without sorting this
out. I'm not apprenticely (junior version of wizardly) to even fully
understand the issue.

However as far as I can tell, for a client that is internet connected
but doesn't want to share resources over the Internet, this shouldn't
be a problem as you are only broadcasting to your subnet.

Anyone else got any more information? (BTW, was someone proposing
comp.sys.os.ms-windows.networking? I hope so!)

-- 
   Thomas Beagle |    ,__o    Faster and faster until the thrill of speed 
Technical Writer |  _-\_<,    overcomes the pain of long ears flapping
  Wellington, NZ | (*)/'(*)   in the wind.          thomas@datamark.co.nz

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Nov 1993 03:56:41 GMT
From:      lyle@phoenix.ims.com (Lyle Harris)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Ethernet overload due to faulty TCP/IP implementations

In article <STEINAR.HAUG.93Nov8212345@runit.sintef.no> Steinar.Haug@runit.sintef.no (Steinar Haug) writes:
>>Uh, what would be different?  Wouldn't the routers be passing packets sent to 
>>the IP broadcast addresses?  Furthermore, the routers would be connected to 
>>many networks, not just two, which would compound the situation.
>
>Read RFC 1122. 255.255.255.255 is a broadcast limited to that particular
>physical network segment it is sent on. RFC 1122, section 3.2.1.3:
>
>            (c)  { -1, -1 }
>
>                 Limited broadcast.  It MUST NOT be used as a source
>                 address.
>
>                 A datagram with this destination address will be
>                 received by every host on the connected physical
>                 network but will not be forwarded outside that network.
>
>A router will normally *not* forward a packet addressed to 255.255.255.255.
>
>Steinar Haug, system/networks administrator
>SINTEF RUNIT, University of Trondheim, NORWAY
>Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

Couldn't you just filter broadcasts on the bridges to your 5Mbit/s  
backbone so that those packets would not get forwarded?  


Lyle Harris                                           Email:  lyle@ims.com
Systems Administrator
Integrated Measurement Systems

-- 



-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Nov 1993 06:53:24 GMT
From:      beeler@tech.ascom.ch (Reto Beeler)
To:        comp.protocols.tcp-ip
Subject:   Re: ATM Group?

Dear Jeff,

You are looking for a newsgroup for ATM (Asynchronous Transfer Mode). There is 
one, but its name does not contain the string "atm" at all. 
(maybe because they do not want to be bothered by bankers?  :-)
Well, just have a look at 
comp.dcom.cell-relay.

Best regards
  Reto Beeler	<beeler@tech.ascom.ch>
  Ascom Tech AG
  CH-3018 Bern
====================================================================================
In article 101193105416@larc.sdsu.edu, babb@sciences.sdsu.edu (Jeff Babb) writes:
>Fellow Netters,
>  I did a search on all groups with the substring   atm   in their name. I
>got alt.comics.bATMman!! Is there an Asynchronous Transfer Mode group out
>there that my nntp server just isn't aware of? Or is it time we established
>the group? If its time to establish the group, perhaps the name could
>contain something other than     atm    in it so that we wouldn't get a lot
>of traffic inquiring about automatic teller machines, eh?  :-)
>
>Jeff.





-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Nov 1993 13:45:49
From:      timmi@ftp.com  (Kitchen Staff Supervisor)
To:        comp.protocols.tcp-ip
Subject:   Re: Can't run PC/TCP with windows

In article <CGA9y7.9Bq@inesc.pt> lmd@cayman (Luis Delgado) writes:

*Hello:
*
*I'm experiencing some performance problems with PCTCP 2.2 while running
*windows 3.1.
*
*When I run PCTCP (telnet for example) in DOS, over a SLIP connection, the
*performance is more than satisfactory, but when I run it in windows, it
*freezes (the telnet program- TN) as soon as I'm logged in at the remote node.
*
*So I think, this sould be a windows configuration problem.

Are you having trouble with antyof the other applications in this
case?  In other words, can you PING or FTP under windows, either
using the DOS apps or the Windows applications?  Can you connect
using the WTNVT application.  If the problem is specific to TN, then
it may be a confilct between the TN application and the Windows video
driver you are using.  If the problem is specific to TN, try adding
the line "card=vga" to the [PCTCP SCREEN] section of your PCTCP.INI
file.  If the problem is not specific to TN, please contact me.
--
Timothy G. Reynolds					FTP Software, Inc.
Technical Support					2 High St.
timmi-email@ftp.com					N. Andover, MA
(800) 382-4FTP							01845

  "I just want someone to say to me, 'I'll always be there when you wake'"


-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 93 12:21:12 GMT
From:      tisdall@cbil.humgen.upenn.edu (James Tisdall)
To:        comp.protocols.tcp-ip
Subject:   how can client know server dies?

Hi,
	QUESTION:
	Is there a way for a client to test if a previously established
socket is still kosher before trying to write to it?  (Thus avoiding ugly
signal catching and such.) 

	BACKGROUND:
	I have a client which starts up several servers on several machines.
I want each server to die after a timeout is triggered.  The client should
see that the server has died the next time a service is requested,
and initiate another server.
	The problem is that when the client tries to write to the defunct
server socket, it generates a SIGPIPE.  This normally causes the client
to exit.  It is possible to catch the SIGPIPE signal ... however it
considerably uglifies the code.

(I realize other designs are possible - but is this one?  My skim-search through
the Comer&Stevens books and the Stevens book, and various manual pages,
has been unsuccessful.  Apologies if this is a FAQ - is there a FAQ for
this group? Couldn't find one on rtfm.mit.edu.  Anyway, I'm sure this is
a typical novice question.)

	ANOTHER QUESTION:
	On another topic: my servers are started by inetd.  Does inetd
include a mechanism to limit the number of active copies of a particular
service?  At present I do a system("ps auxww | wc -l") type hack from each new
service to see if the server should kill itself.

Thanks everybody!  - Jim
======================================================================
James Tisdall
Departments of Genetics and Computer and Information Science
Computational Biology and Informatics Laboratory, Human Genome Project
510 Blockley Hall
University of Pennsylvania

tisdall@cbil.humgen.upenn.edu
215-573-3113
fax 215-573-3111
======================================================================

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Nov 1993 13:20:17 GMT
From:      rvt@atl.hp.com (Richard V.C. Tinker)
To:        comp.os.msdos.apps,comp.protocols.tcp-ip,comp.binaries.ibm.pc.wanted
Subject:   Re: Looking for License Management Software

In article <2bogo2INNpvm@maxwell.genrad.com> jpn@genrad.com (John P. Nelson) writes:
>From: jpn@genrad.com (John P. Nelson)
>Subject: Looking for License Management Software
>Date: 9 Nov 1993 11:33:06 -0500
 
>We have a network of about 200 PCs (using the Lan Manager protocol,
>well, really DEC Pathworks TCP/IP).  We've found it convenient to make
>certain commerical packages available on the network, so that they can
>be used from any PC, and so they don't take disk space on every PC.
 
>However, we don't have SITE licenses for these packages, we have a
>limited number of copies that we've bought, and so a limited number
>of licenses to use the software.  We are trying to stay legal by
>limiting the number of copies of each licensed package that can be
>running at a time.
 
>Our current solution is rather clumsy (particularly for windows users),
>and we are looking for software that can help us manage this problem.
>I've found a couple of packages on the usual archive sites (Simtel, etc.)
>but they have been specific to NOVELL networks, and that doesn't help us.
 
>Are there ANY software packages that do licensing that will either
>run on any kind of network, or are designed for a TCP/IP protocol
>stack (perhaps using a winsock interface?)  I'd prefer a free or
>shareware package, but am willing to consider commercial packages
>as well.


Here's a dump of information about a product that we may use for licensing and 
metering.  (At least until Microsoft gets Hermes working...)  It is a 
commercial package, but it will do everything you want it to do and then some.

DC Computer Corp., of Redmond, Wash., has upgraded its 
Express Meter Windows license-management software, bolstering its reporting, 
installation and monitoring capabilities.  Express Meter 2.0 adds the ability 
to monitor and control the use of software suites.  The upgrade also boasts 
simplified installation and expanded reporting, which can be organized by user 
or application and viewed in graphical or numerical form.

Pricing ranges from $395 for 10 users to $1,990 for 200 users.  
hDC can be reached at (206) 885-5550.

Hope it helps!

Rick Tinker
Hewlett-Packard, Co.
Atlanta, GA
rvt@atl.hp.com

__________    ________________________________________________________________
_______    /    ____________   Rick Tinker - Technology Research Engineer   __
_____     /        ________   Atlanta Tech Center-Technology Solutions Lab ___
___      /           _____   email:  rvt@atl.hp.com                       ____
_       __  /  __  /  ___  HPDesk: Rick Tinker / HPATC                   _____
_      /   /  /   /   __  US Mail:    2015 South Park Place, MS 311     ______
__   _/  _/  ____/   __               Atlanta, GA  30339               _______
___         /      ___                                                ________
________  _/ _________________________________________________________________


-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Nov 1993 13:48:48 GMT
From:      leo@elmail.co.uk (E.J.Leoni-Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: thin -vs- RJ-45 concern.  Advice sought.

In article <2brhot$p8o@charm.magnus.acs.ohio-state.edu> tburns@magnus.acs.ohio-state.edu (Timothy A N Burns) writes:
>I am in the process of equiping a classroom lab.  What I have is 24 intel-based
>PCs, and 2 RJ-45 wall jacks (which are connected to an 8 port hub ~100ft away.)
>
>I need to network (strictly TCP/IP today) the 24 PCs. Should I
>
>a) stick a 32-port hub in the room, connected via twisted pair to the wall, 
>then each PC to a port on said hub. (managed or not?)
>
That will work. You need a crossover cable from the hub to the wall though, 
and be careful how many more repeaters there are upstream...

>b) twisted pair from wall to BALUN to thin coax from which I T-off each PC, 
>thus requiring BNC enet card (vs RJ-45 enet cards for option (a))
>
You can't do this. Period. You can buy a two port 10baseT to thin coax
repeater though. 

>c) T-off a coax from phone closet to classroom (not use RJ-45, or twitsted 
>pair) and run thin to each PC as in choice (b)
>

This is feasible also, if the repeater has a coax outlet. Cheap, but 
I wouldn't want to run coax in a classroom environment. One set of
idle fingers and you lose the lot (bitter personal experience).

>d) try (b) whence I find out said BALUN does not work, go with (c).
>
>I am unsure of any benefits of TP vs thin in this case.  The lab I use as a 
>model is like (c), except there was no exsisting TP in the wall.  Also I 
>currently have 1 of the 24 PCs plugged in via TP.  Any limitations or concerns 
>I have not considered , I appreciate ALL advice.
>

Honestly, I would get a pair of 12 port 10baseT repeaters and slave one
to each of the sockets that you have. Some repeaters allow you to 
reverse the polarity on one socket so you don't need the crossover cable

The price of repeaters and cards is so low, that unless you are totally
out of budget, the extra cost is WELL worth the resilience gained. If
little Johnny decides to snip HIS cable, at least the other 19 users
can carry on...:-)

>THanks
>
>tim+@osu.edu



-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 1993 15:08:37 GMT
From:      jzinky@BBN.COM ()
To:        comp.protocols.tcp-ip
Subject:   Performance of Slow Start in the presents of noise?

Has anyone done a study of the performance of slow start with noisy
lines?

One of the basic assumptions of Slow Start is that drops only happen
during congestion. But we are seeing lots of drops (1/50) in some
(not to be named) FDDI environment. We have not chased down the cause
of the drops, so they may be not be random. But it would be nice to
know what the expected TCP throughput would be for a given a pipe with
error rate, maximum windowsize, minimum delay, maximum throughput, and
maximum buffersize.

One idea is to model the states of the connection using a Markov
chain. The states would be the current windowsize and the transitions
would be determined by slowstart algorithm and noise. Solve the
Markov chain for the probability of being in each state, then multiple by
the throughput for each state to get the Steady State throughput. 
This would be fairly irregular Markov chain, but you would be amazed
what you can solve with a symbolic math program, such as Mathematica!


-------------------------------------------------------------------------
John Zinky (jzinky@bbn.com)
BBN Systems and Technologies

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Nov 1993 15:46:07 GMT
From:      tzieg@cosy.sbg.ac.at (Thomas Ziegler)
To:        comp.protocols.tcp-ip
Subject:   V. Jacobson Article

In April 1990 V. Jacobson has written an article called "Modified TCP congestion avoidance algorithm" to the end2end interest
mailing list.
If anybody knows where to find this article - please mail me.

                                Thanks       Thomas Ziegler




-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Nov 1993 15:54:32 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: Tcp Push?

> If you are not 
>experiencing errors, the delay you see may be due to buffer recovery 
>and state synchs. If you are in an IBM mainframe environment, screen data 
>must be reconciled. 

My experience was on a UNIX system.

I found that in an ftp-data session, the typical delay (80%) after
each packet was 2-4 milliseconds. However - after a PUSH - the delay
was 50 milliseconds. 65% of the time the system send 7 packets before
a PUSH. 20% is was 6 packets, 7% of the time it was 5 packets.

The system was using an 8K buffer. I was assuming the difference
between the 2-4 millisecond delays and the 50 millisecond delays was
the speed of the device filling up it's transmit buffer. 


Was I mistaken?
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Nov 1993 15:59:49 GMT
From:      jburnes@csisun.uucp (Jim Burnes)
To:        comp.protocols.tcp-ip
Subject:   ping: socket: permission denied

Subject says it all...

I've never seen this error before.  I'm running SCO Unix with their
TCP/IP package.  Telnet and ftp seem to run fine, but 'ping', 'rlogin',
'rcmd' (rsh) and rcp all respond with the same....

(program name): socket: permission denied

At first I thought that this was a problem with the /etc/hosts.equiv
but that wasnt it.  Then I thought the /etc/services file was screwed
up, but that wasnt it.

Where the heck is this message coming from.  My next best guess is
that is an error returned when these routines try to open a socket.
Why there is a permission problem I don't know.  I can't think of
any file that needs to be used here.  Im running as root and I even
tried pinging the machine's own IP number.  Failing that I tried
pinging 127.0.0.1 (localhost) and still no luck.  Is there some 
strange socket control file out there?

For what its worth ...outside machines can both ping me and rlogin.

Help!

Jim Burnes
jburnes@compusci.com

-- 
Jim Burnes
Software Engineer
CompuSci, Inc.
jburnes@compusci.com

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Nov 1993 16:09:16 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   UDP timeouts on localhost connection?

I have developed a Perl application using UDP sockets on Suns.
There are several servers involved, all communication uses UDP sockets. 

The test application connects to process A, which in turn connects to
process B. All three processes are on the same host.

A in turn talks to 3 different processes on a dozen different
machines. We call process A the dispatcher, as it knows which machine/UDP-port
to talk to.

Anyhow - occasionally the test application gets a timeout when making
a request thru A to B. Why would a system get a timeout when sending
UDP packets to its own address? In addition, the timeout occurs in
sets, so that 8 timeouts occur in a row, and then everything is okay
for a while. 

In some cases, I see an increase in the icmp errors (netstat -s), but
the errors increase many seconds after the timeout problem occurs. I
am not sure they are related.

--
Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 1993 16:54:49 GMT
From:      sriram@glock.tcs.com (Sriram Srinivasan)
To:        comp.protocols.tcp-ip
Subject:   PD or commercial XDR implementations?

I am looking for PD or commercial XDR (Sun's external data representation)
libraries/compilers. I am not sure if this is the right place to ask, but
since a lot of the subscribers to this newsgroup are based on Sun/Unix, I 
thought of it ...

Thanx for any pointers
Sriram
(sriram@tcs.com)

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Nov 1993 16:57:05 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple subnets on same physical wire

In article <752903547snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
>Legal yes, but everyone must be running a TCP/IP package that knows
>how to deal with ICMP redirects and/or RIP.  Otherwise, you'll always
>be transmitting *to* your default route(r), which will send back an
>ICMP redirect (which you'll ignore), and re-send the packet to the
>right host.  Triple the outgoing traffic.

I disagree.  Router Requirements states that a router should not issue a
Redirect unless the source host is on the same (sub)net as the next-hop.
RFC1122 states that a host should ignore a Redirect to a (sub)net different
than the one it is connected to.

Art


-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 1993 16:59:17 GMT
From:      jzinky@BBN.COM ()
To:        comp.protocols.tcp-ip
Subject:   Performance of Slow Start over Leaky Bucket



Has anyone done a study of the performance of slow start over leaky bucket?

A (unnamed) frame relay switch uses a leaky bucket-like access control
scheme.  A PVC has a specified rate and a burst size. Unfortunately,
the vendor thinks that the burst size should be small, on the order of
one ethernet frame. The resulting pipe has a cliff that is to the left
of the knee! 

Since slow start converges on the cliff, slow start should be
converging on a window of one. Of course, slow start wants to probe to
see if the window can be expanded. But when sending a pair of packets
the last one is dropped and the whole recovery mechanism is started.

Has anyone else experienced this problem?
Is there a work around, besides increasing the bucket size?
-------------------------------------------------------------------------
John Zinky (jzinky@bbn.com)
BBN Systems and Technologies

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 1993 17:20:08 GMT
From:      dehaan@ux1.cso.uiuc.edu (Jason DeHaan )
To:        comp.protocols.tcp-ip
Subject:   POP client for UNIX??

Does anyone know of a POP mail client for UNIX?  I would like to read my
mail (held on a novell server) from my UNIX account.  Is there anyone working
on such a client?  Thanks for any info.

-- 
Jason DeHaan -- dehaan@ux1.cso.uiuc.edu -- Univ of Illinois at Urbana-Champaign
CCSO Sites Novell Support -- Manager, CCSO Undergraduate Multimedia Site

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Nov 1993 17:59:26 GMT
From:      jburnes@csisun.uucp (Jim Burnes)
To:        comp.protocols.tcp-ip
Subject:   Re: ping: socket: permission denied

Okay:

Here is a followup to my previous message....

I've done some hacking and found that the commands in question....

ping,rlogin,rcmd,rcp

all are id=bin,bin and have setuid bit set to make them run as
bin, bin obviously....

Well...when I superuser and remove the setuid bit then programs
run fine.  Okay...so its opening a device like /dev/inet or /dev/socksys
or something that is owned by root and not allowed to write by other.

So I tracked down all the /dev/inet/* files and /dev/socksys* files and
..yep...they were all owned by root and disallowed anyone other to
write them.   That figured...the reason that telnet and ftp worked was
because inetd runs out of root and they give access to well known services
so that explains that...problem solved...just chown them all to bin bin and
viola!

Not so fast.  I tracked down all the tcp/ip install files and gave them
bin,bin ownership and it still doenst work.  If I go down to superuser
and turn off their setuid bit, it works again....

I even did a strings through all of the ping and r* binaries and chowned
the filenames I found in there...no luck.

Help!

Mama!

ahem...

Any help is greatly appreciated.

Jim Burnes
jburnes@compusci.com

-- 
Jim Burnes
Software Engineer
CompuSci, Inc.
jburnes@compusci.com

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Nov 93 18:04:49 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.os.ms-windows.setup,comp.os.ms-windows.misc,comp.protocols.tcp-ip
Subject:   Re: Windows for Workgroups over TCP/IP

NetBIOS over IP which is basically the heart of LAN Manager requires name
services on every subnet.  This name service is not DNS based in that the query
is not made via UDP but rather is a DNS query on top of NetBIOS on top of (my
memory fails now) TCP, I think.

Some LAN Manager capable IP stacks have made attempts to use a regular DNS server
for name resolution but there is no standard approach.

Charles.
--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IT Network Services			AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Nov 1993 18:58:05 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: Tcp Push?

I should mention that the system with a 50 millisecond delay after the
PUSH was a sun 3. I have also looked as some older sun 4's, and the
delay there was on the order of 8 msec. 
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Nov 1993 19:21:54 GMT
From:      clu@malihh.hanse.de (Carsten Lutz)
To:        comp.protocols.tcp-ip,de.comp.os.unix
Subject:   IP broadcast conventions

Hi, folx !

I'm posting this for someone without access to the Internet:



The first part of the IP broadcast address is computed with a logical AND 
between the IP address and the netmask. For the last part, two different 
conventions are used by the manufacturers: some fill the last bits ( the ones
which are 0 in the netmask ) with 0 ( e.g. SUN ), others with 1 ( e.g. HP ).

I wonder what can be the consequences if both conventions are used on
the same network. I read it could be a broadcast storm. Why ?

Which main applications use IP broadcast ?

What is the most common convention ?

Jean-Francois Saint-Etienne



greetings,		
		Carsten

-- 
*  Carsten Lutz, Rellingen, FRG / clu@malihh.hanse.de ( NeXTmail accepted )   *
*     Voice : +49 40 8502471  Fax: +49 4101 27757  Zyxel : +49 40 8515315     *
* "Reject their values; Reject tradition; Burn their flag; Fuck their system" *
*                                                      - propagandhi          *

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Nov 93 21:41:41 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   BOOTP is *really* your friend

BOOTP is *really* your friend.  A customer just finished (I hope!)
suffering through a week of service outages because one of their
users hand-configured their computer.  They used the default route as
their IP address.  And every host that they connected to started to
use them as their default route!

This wouldn't have happened if the user had gone through channels and
gotten an entry in the BOOTP tables...

-russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support.
11 Grant St.      | 315-268-1925 (-9201 FAX)       | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 1993 22:21:59 GMT
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: ping: socket: permission denied

In article <CGC9z3.35I@csisun.uucp>, Jim Burnes <jburnes@csisun.uucp> wrote:
>I've done some hacking and found that the commands in question....
>
>ping,rlogin,rcmd,rcp
>
>all are id=bin,bin and have setuid bit set to make them run as
>bin, bin obviously....

This is wrong.  Apparently someone was misguided into thinking all
binaries should be owned by 'bin' and changed them.

They should all be setuid root, not bin.

--Dave
-- 
"There's no place for the state in the bedrooms of the nation"
- Pierre Elliott Trudeau

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Nov 1993 23:54:59 GMT
From:      troyl@dadd.ti.com (Troy Loveday)
To:        comp.protocols.tcp-ip
Subject:   Better FTP client/server?

(I couldn't find any sort of *.*.ftp newsgroups, so I'm posting my
query in comp.protocols.tcp-ip since FTP is implemented on TCP-IP.
If doing so is inappropriate, trash this post, and you have my
apology.)

I've been perusing the RFC 959 (File Transfer Protocol) lately, and
from what I'm able to glean, it provides for many useful features
which are implemented either poorly or not-at-all in all of the
FTP clients/servers I have seen (mostly Unix systems).  To name a few:

  Restart markers (ok, block mode only, whatever that is)
  Third party ("proxy") transfers
  Multiple simultaneous transfers

My question: Are there any good FTP client/server implementations
available (either commercial, or freely available) which implement
as much of RFC 959 as possible (practical?), and/or which have a
reasonably user-friendly interface?

I've tried asking archie and gopher, but nothing looked promising.

Any pointers/recommendations would be appreciated.  How about it?

(I'd really prefer not to have to start from current ftp/ftpd source,
or worse, scratch, to get what I'm looking for.)

--
Troy Loveday                 vox: 214.917.5069        Texas Instruments, Inc.
Email: troyl@dadd.ti.com     fax: 214.917.7966        M.S. 3937
TI msgid: TML                                         P.O. Box 650311
#include <stddisclaimer.h>                            Dallas, TX 75265

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Nov 1993 00:00:15 GMT
From:      syedk@netcom.com (syed khalid)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   NFS benchmarks

Anyone have information of NFS benchmark packages. What are some of the
things to test for , specially, in a high-speed WAN environement?
Any studies on latencies and relationship to "rpc time outs", NFS mount table
integrity? I am looking for any ideas in this area.

Thanks in advance

S. Khalid


-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Nov 1993 00:10:03 GMT
From:      demay@pyramid.unr.edu (Mark DeMay)
To:        comp.protocols.tcp-ip
Subject:   <<< TCP-IP Server example source needed >>>



Howdy,

    I am writing TCP/IP for an embedded system with EtherNET. Between all 
the Public Domain stuff and the Comer/Stevens books, I think I'll
be able to complete the IP, ICMP, and TCP. 

BUT, I am having difficulty finding anything to use as a template or
example of Application level SERVER software, e.g. the daemon for
internet services like RSH, RLOGIN, and FTP.

Any suggestions???

Thanks in advance,


-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Nov 1993 01:07:47 GMT
From:      c.oneill@trl.oz.au (Chris O'Neill)
To:        comp.protocols.tcp-ip
Subject:   Re: V. Jacobson Article

In article <CGC3sv.93q@cosy.sbg.ac.at> tzieg@cosy.sbg.ac.at (Thomas Ziegler)
writes:
>In April 1990 V. Jacobson has written an article called "Modified TCP
 congestion avoidance algorithm" to the end2end interest
>mailing list.
>If anybody knows where to find this article - please mail me.

Me too or perhaps it may be better to post.  Even though I know what the
algorithm is from other papers it would be nice to see the original paper and
read the insights that Van Jacobson includes.

Thanks

Chris O'Neill

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Nov 1993 02:39:00 GMT
From:      TDTRUE@pucc.Princeton.EDU (Tom True)
To:        comp.protocols.tcp-ip
Subject:   Data loss when closing non-blocking socket

I'm using a non-blocking socket in a server.  Data doesn't seem
to get to the client if I close the socket too quickly;  i.e.  if
I'm stepping through with gdb, everything is fine;  if I just let
it run, the client doesn't see the data.  The client, not mine,
is a hypercard application using the TCP xcmds on a mac.  The
server is running on a Sparc station.  The sun documentation
doesn't really cover this case too well.  I've tried setting
SO_LINGER, but that doesn't seem to help.  (By the way, what
units is l_linger in?) Thanks for whatever help you can give.
 
Tom True
Princeton University
CIT - Advanced Applications
TDTRUE@PUCC.PRINCETON.EDU
(609) 258-6064

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 1993 04:24:28 GMT
From:      jgs@hadron.merit.edu (John G. Scudder)
To:        comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: ISDN (was Re: X.25 through tcp-ip)

In article <1993Nov8.185332.29406@sci34hub.sci.com>,
Gary Heston <gary@sci34hub.sci.com> wrote:
[...]
>My quoted price per month for flat-rate usage is $75. Our corporate
>communications manager was amazed....

Here in Michigan, flat-400 "voice" ISDN is in the neighborhood of $25 a
month.  "Voice" is in quotes because bits is bits, at least for local
calls; my bridges run just fine over the usage-insensitive "voice"
service instead of the more expensive "data" service.

(Well, I think the tariff applies to all of MI; I can only really speak
for Ann Arbor, though.)

>Right now, the biggest holdback isn't the availability of connections,
>it's the $2100+ cost of the bridges. If that comes down to under $1000, 
>ISDN will really take off.

Hmm, the somewhat brain-dead bridges I'm using came to a bit under $500
each.  Then you have to add in the cost of the NT-1's.  The catch is
that the bridges do no filtering whatsoever -- just forward everything
they see on the Ether to the other bridge.  You can get a more
expensive model that does filtering, but my office-end bridge just sits
on a stub Ethernet behind a router.  The notion is that you use the
dumb bridge to connect a single machine at home (or wherever) to a
filtering bridge at the office, but you can obviously beat this by
adding a router to the mix.

--John Scudder

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Nov 93 06:28:55 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: Tcp Push?

	How does one send a TCP PUSH? Does one need root priviledges?


-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 1993 17:05:32 -0500
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: how can client know server dies?

In article <161558@netnews.upenn.edu> you write:
>Hi,
>	QUESTION:
>	Is there a way for a client to test if a previously established
>socket is still kosher before trying to write to it?  (Thus avoiding ugly
>signal catching and such.) 

You could try to read() from the socket.  If the client has closed the
connection you should get EOF.

To keep from hanging in read() you could put the socket in async mode, or
use select() to find out whether read() will hang.

>	ANOTHER QUESTION:
>	On another topic: my servers are started by inetd.  Does inetd
>include a mechanism to limit the number of active copies of a particular
>service?  At present I do a system("ps auxww | wc -l") type hack from each new
>service to see if the server should kill itself.

For datagram services you can use the "wait" option, which causes inetd to
start only one copy.  I don't think there's anything like this for stream
connections, and definitely no way to specify a limit other than 1.

Rather than using system(), you could use something like a semaphore that
all the servers register themselves in.  When a new server discovers that
the semaphore has counted down to zero it would exit.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Nov 1993 09:16:47 GMT
From:      me@tartufo.pcs.com (Michael Elbel)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple subnets on same physical wire

In <2br8m3$on9@charm.magnus.acs.ohio-state.edu> maf@dunedin.acs.ohio-state.edu (Mark Fullmer) writes:

>>Legal yes, but everyone must be running a TCP/IP package that knows
>>how to deal with ICMP redirects and/or RIP.  Otherwise, you'll always
>>be transmitting *to* your default route(r), which will send back an
>>ICMP redirect (which you'll ignore), and re-send the packet to the
>>right host.  Triple the outgoing traffic.
 
>Actually it's worse than this since the router can't send ICMP redirects.
>It would need to be an ARP redirect, which ofcourse doesn't exist.
 
>Using RIP sorta works, but the clients need to listen to the RIP  
>advertisements from the router, then install those routes as local routes.
>I did this once - the problem is it won't work for DOS machines, that
>can't run routed.
 
>It's easier in the end to just change the subnet mask to have the hosts
>think they can talk to the entire network, then have the router do proxy
>arp for the subnets on the 'other' ports.

Maybe I'm not understanding the whole point, but what's wrong with
just using static routes that point to the respective other net?
I agree, you'll have to set them up, but so you have to do with the
actual IP-Address and net mask.

We are running two different subnets in this building on the same wire
(16.186.144.0 and 16.186.160.0). We have a router with addresses in
both nets that runs rip (its actual job is to route to the rest of our
net). Without doing anything special, just using routed, machines on
both subnets can talk together through the router. This doesn't make
much sense, however, since the packets get put onto the same wire
again, effectively doubling the net load for communication between
the nets.

All we had to do to have the net run properly was add static routes to
the "other" net on all the workstations. E.g.

	/etc/route add net 16.186.160 tartufo 0

on my machine tartufo (16.186.144.131)

Could somebody please enlighten me, if we actually have a possible
problem with this solution?

Michael
Michael Elbel, Digital-PCS GmbH, Muenchen, Germany - me@dude.pcs.dec.com
Fermentation fault (coors dumped)

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Nov 1993 09:19:08 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple subnets on same physical wire

> Drew Dean (ddean@minerva.rolm.com) wrote:
> : Well, you weren't at Wesley Irish's talk last week at Stanford.  Sniffers
> : have a nasty way of dropping packets, especially after collisions and other
> : abnormal events.  What you really need is a good digital storage
> : oscilloscope, and a little knowledge of Manchester encoding.  BTW, it's
> : fun !

lawson@netcom.com (Steven Lawson) writes:
> Digital storage scope???  A real man could do it with a cap and a #42
> light bulb...  :-)   :-)

Amateurs!  I just hold the end of the cable against my tongue.

-- 
Tom Fitzgerald    Wang Labs, Lowell MA, USA    fitz@wang.com   1-508-967-5278

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Nov 1993 11:24:30 GMT
From:      scott@nova.tcs.tufts.edu (Scott R. Corzine)
To:        comp.protocols.tcp-ip
Subject:   LPD use of client port numbers (does RFC-1179 reflect reality?)

Hi-

    I'm working with a vendor who has written a version of the LPR/LPD
    (aka LPDP) protocol based on the description in RFC-1179.

    Section 3.1 of RFC-1179 limits the valid source ports of clients to
    the range 721 through 731.  This creates a limit of 11 simultaneous
    connections between any pair of hosts.  With large numbers of print
    queues, this has created serious performance trouble on the system
    (due to internal contention for those 11 ports).

    Can we safely ignore this limited range and use connections from any
    port <= 1023?  From reading the sources from the current bsd-sources
    tree it appears that the BSD version uses/allows any reserved port
    (preferring the high end of the range).  Is this just a case of the
    RFC not reflecting reality (especially considering its history)?
    Are there implementation which enforce the 721-731 range?  Are there
    any ports which should be avoided by the client end?  Is there
    anything that would be broken by expanding the range?

			       Thank you,
			   -Scott R. Corzine-
		      New Enagland Medical Center
			    <scott@nemc.org>

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 1993 14:11:15 GMT
From:      marant@univ-lille1.fr (Dominique Marant)
To:        comp.protocols.tcp-ip
Subject:   ntalk - ntalkd

[ Article crossposted from comp.unix.solaris ]
[ Author was Dominique Marant ]
[ Posted on 12 Nov 1993 14:08:38 GMT ]

Does anyone installing successfully ntalk on solaris ?

Thanks in advance to help me.

--
Dominique Marant   -   marant@univ-lille1.fr 

--
Dominique Marant   -   marant@univ-lille1.fr 

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Nov 93 14:19:06 GMT
From:      lroberts@nyx10.cs.du.edu (Larry Roberts)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   How to change the timeout of "connect" system call.

How do I change the timout on the connect system call?  I am
working on a client/server app that will run on a very small
net (3 machines sitting beside each other.)  Currently, if
a machine is down, and my client app tries to "connect",
it takes about a minute for the connect to timeout.  Since
I am on a small network and quick response is important,
I would like the connect to time out after 5 sec or so.
I have looked in Unix Network Programming by Richard Stevens, 
and Internetworking with TCP/IP by Douglass Comer and
David Stevens but I could not find any info about this.
Any assistance anyone could give will be greatly appreciated.
Thanks.

-Larry Roberts
-8450lsr@indy.navy.mil

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Nov 1993 15:08:52 GMT
From:      lawson@netcom.com (Steven Lawson)
To:        comp.protocols.tcp-ip
Subject:   chat program with big user names?

Is there a standard extension to the talk protocol which supports long
user names?  I was going to port the talk client/servers to our o/s
but the user names involved are actually first and last, and can exceed
the 12 characters available in the CTL_MSG packet.  It would be real
nice if the names in the packet were variable length.


-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Nov 1993 16:03:55 GMT
From:      dwoo@jupiter.sun.csd.unb.ca (Dennis Woo)
To:        comp.protocols.tcp-ip
Subject:   PC-XWare & SMC Elite16 Ethernet Card

Hi, 

I have many troubles trying to install PC-XWare on a PC that is equipped
with a SMC Elite16 card. My problem is that the integrated TCP/stack of 
PC-XWare (I think the TCP is by NetManage Inc) will not able to read from the
ethernet card. During startup, all the device drivers are loaded properly 
without any error; when I run PC-XWare, MS Windows quits and gives me back 
the DOS prompt. I called the support technician for help but they are not able 
to solve my problem. At first, I thought my ethernet card might be faulty, but 
I can run other TCP product like NCSA telnet without any problem. 

Have anyone experienced similar problem? Please give me some suggestions.

Thanks a mil.

 
*****************************************************************
*  Dennis Woo              Department of Mechanical Engineering *
*  E-mail: dwoo@unb.ca     University of New Brunswick          *
*  Office Tel: (506) 453-4513                 --------  __o     *       
*  Voice mail: (506) 453-0614                -------  _`\<,_    *
*  FAX       : (506) 453-5025               -------  (*)/ (*)   *
*****************************************************************	
-- 
*****************************************************************
*  Dennis Woo              Department of Mechanical Engineering *
*  E-mail: dwoo@unb.ca     University of New Brunswick          *
*  Office Tel: (506) 453-4513                 --------  __o     *       

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Nov 1993 16:10:14 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.tcp-ip
Subject:   Re: IP broadcast address getting reset

pascoe@MathWorks.Com (Dave Pascoe) writes:

>I'm having a strange problem on a SPARC-10 running SunOS 4.1.3 where
>the IP broadcast address is being reset by some process from all ones
>to all zeros.  i.e., 144.212.255.255 is being changed to 144.212.0.0.
 
>Anyone know what might be doing this?

An "ifconfig" command somewhere. Normally found in /etc/rc.local.

Ian
-- 
Ian Phillipps. Tech support manager, Unipalm.
Phone +44 223 250103, Fax 250101
Pipex phone +44 223 250120. Internic: IP4.

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 1993 14:45:54 +0100
From:      marc@piglet.uni-paderborn.de (Marc Gumbold)
To:        comp.protocols.tcp-ip
Subject:   IPng -- need info

Could some knowledgeable soul please point me to information
about the discussion concerning IPng?

Thank you,
Marc
-- 
Marc Gumbold			
Uni-GH Paderborn/HNI		... you might well expect to be offered
33098 Paderborn, Germany	a choice between an ATM cup or a Jurassic 
Phone: +49 5251 60 3382		Park cup with your burger at McDonald's.
Fax:   +49 5251 60 3426				-Charles Feltman, Fall 1993

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Nov 1993 16:41:46 GMT
From:      arinell@elixir.e.kth.se (Fredrik Arinell)
To:        comp.protocols.tcp-ip
Subject:   A robust pipe over a tcp connection (HOW?)

I'd like to develop a robust connection to a present text-based
application over a tcp socket. 

What I do today - communicationwise
-----------------------------------

parent <-duplex pipe-> child

the parent is sending commands to the child that responds in different
ways.

What I want to achieve
----------------------
parent 
   <-duplex pipe->
      transparent_tcp_client
         <-tcp socket -> 
            transparent_tcp_server
	       <-duplex pipe>
	   	   child

What I lack
-----------
I have seen socket-1.1 by nickel@cs.tu-berlin.de which gave me the
basics about the connection itself. But I need a robust connection
that can handle buffering and re-establishment of a lost connection.

Of course, it doesn't matter if the commuication to the transparent
client and server adds some to the communication.

Has somebody seen such a thing or can you just tell me hints and/or if
the problem is hard to solve.

Maybe there is some packet available...


Thanks,

Fredrik.Arinell@haninge.trab.se

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Nov 1993 16:42:52 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   collection of Van Jacobson's postings

Here's my collection of some of Van's notable postings.  If folks have others
they think are particularly notable, could they forward copies to me?

Thanks

Craig

BBoard-ID: 7621
BB-Posted: Tue, 25 Oct 88 2:06:08 EDT
To: tcp-ip@sri-nic.ARPA
Subject: 4BSD TCP Ethernet Throughput
Date: Mon, 24 Oct 88 13:33:13 PDT
From: Van Jacobson <van@helios.ee.lbl.gov>

Many people have asked for the Ethernet throughput data I
showed at Interop so it's probably easier to post it:

These are some throughput results for an experimental version of
the 4BSD (Berkeley Unix) network code running on a couple of
different MC68020-based systems: Sun 3/60s (20MHz 68020 with AMD
LANCE Ethernet chip) and Sun 3/280s (25MHz 68020 with Intel
82586 Ethernet chip) [note again the tests were done with Sun
hardware but not Sun software -- I'm running 4.?BSD, not Sun
OS].  There are lots and lots of interesting things in the data
but the one thing that seems to have attracted people's
attention is the big difference in performance between the two
Ethernet chips.

The test measured task-to-task data throughput over a TCP
connection from a source (e.g., chargen) to a sink (e.g.,
discard).  The tests were done between 2am and 6am on a fairly
quiet Ethernet (~100Kb/s average background traffic).  The
packets were all maximum size (1538 bytes on the wire or 1460
bytes of user data per packet).  The free parameters for the
tests were the sender and receiver socket buffer sizes (which
control the amount of 'pipelining' possible between the sender,
wire and receiver).  Each buffer size was independently varied
from 1 to 17 packets in 1 packet steps.  Four tests were done at
each of the 289 combinations.  Each test transferred 8MB of data
then recorded the total time for the transfer and the send and
receive socket buffer sizes (8MB was chosen so that the worst
case error due to the system clock resolution was ~.1% -- 10ms
in 10sec).  The 1,156 tests per machine pair were done in random
order to prevent any effects from fixed patterns of resource
allocation.

In general, the maximum throughput was observed when the sender
buffer equaled the receiver buffer (the reason why is complicated
but has to do with collisions).  The following table gives the
task-to-task data throughput (in KBytes/sec) and throughput on
the wire (in MBits/sec) for (a) a 3/60 sending to a 3/60 and
(b) a 3/280 sending to a 3/60.

	_________________________________________________
	|              3/60 to 3/60   |  3/280 to 3/60   |
	|            (LANCE to LANCE) | (Intel to LANCE) |
	| socket                      |                  |
	| buffer     task to          | task to          |
	|  size       task      wire  |  task      wire  |
	|(packets)   (KB/s)    (Mb/s) | (KB/s)    (Mb/s) |
	|    1         384      3.4   |   337      3.0   |
	|    2         606      5.4   |   575      5.1   |
	|    3         690      6.1   |   595      5.3   |
	|    4         784      6.9   |   709      6.3   |
	|    5         866      7.7   |   712      6.3   |
	|    6         904      8.0   |   708      6.3   |
	|    7         946      8.4   |   710      6.3   |
	|    8         954      8.4   |   718      6.4   |
	|    9         974      8.6   |   715      6.3   |
	|   10         983      8.7   |   712      6.3   |
	|   11         995      8.8   |   714      6.3   |
	|   12        1001      8.9   |   715      6.3   |
	|_____________________________|__________________|

The theoretical maximum data throughput, after you take into
account all the protocol overheads, is 1,104 KB/s (this
task-to-task data rate would put 10Mb/s on the wire).  You can
see that the 3/60s get 91% of the the theoretical max.  The
3/280, although a much faster processor (the CPU performance is
really dominated by the speed of the memory system, not the
processor clock rate, and the memory system in the 3/280 is
almost twice the speed of the 3/60), gets only 65% of
theoretical max.

The low throughput of the 3/280 seems to be entirely due to the
Intel Ethernet chip: at around 6Mb/s, it saturates.  (I put the
board on an extender and watched the bus handshake lines on the
82586 to see if the chip or the Sun interface logic was pooping
out.  It was the chip -- it just stopped asking for data.  (The
CPU was loafing along with at least 35% idle time during all
these tests so it wasn't the limit).

[Just so you don't get confused:  Stuff above was measurements.
 Stuff below includes opinions and interpretation and should
 be viewed with appropriate suspicion.]

If you graph the above, you'll see a large notch in the Intel
data at 3 packets.  This is probably a clue to why it's dying:
TCP delivers one ack for every two data packets.  At a buffer
size of three packets, the collision rate increases dramatically
since the sender's third packet will collide with the receiver's
ack for the previous two packets (for buffer sizes of 1 and 2,
there are effectively no collisions).  My suspicion is that the
Intel is taking a long time to recover from collisions (remember
that you're 64 bytes into the packet when you find out you've
collided so the chip bus logic has to back up 64 bytes -- Intel
spent their silicon making the chip "programmable", I doubt they
invested as much as AMD in the bus interface).  This may or may
not be what's going on:  life is too short to spend debugging
Intel parts so I really don't care to investigate further.

The one annoyance in all this is that Sun puts the fast Ethernet
chip (the AMD LANCE) in their slow machines (3/50s and 3/60s)
and the slow Ethernet chip (Intel 82586) in their fast machines
(3/180s, 3/280s and Sun-4s, i.e., all their file servers).
[I've had to put delay loops in the Ethernet driver on the 3/50s
and 3/60s to slow them down enough for the 3/280 server to keep
up.]  Sun's not to blame for anything here:  It costs a lot
to design a new Ethernet interface; they had a design for the
3/180 board set (which was the basis of all the other VME
machines--the [34]/280 and [34]/110); and no market pressure to
change it.  If they hadn't ventured out in a new direction with
the 3/[56]0 -- the LANCE -- I probably would have thought
700KB/s was great Ethernet throughput (at least until I saw
Dave Boggs' DEC-Titan/Seeq-chip throughput data).

But I think Sun is overdue in offering a high-performance VME
Ethernet interface.  That may change though -- VME controllers
like the Interphase 4207 Eagle are starting to appear which
should either put pressure on Sun and/or offer a high
performance 3rd party alternative (I haven't actually tried an
Eagle yet but from the documentation it looks like they did a
lot of things right).  I'd sure like to take the delay loops out
of my LANCE driver...

 - Van

ps: I have data for Intel-to-Intel and LANCE-to-Intel as well as
    the Intel-to-LANCE I listed above.  Using an Intel chip on the
    receiver, the results are MUCH worse -- 420KB/s max.  I chose
    the data that put the 82586 in its very best light.

    I also have scope pictures taken at the transceivers during all
    these tests.  I'm sure there'll be a chorus of "so-and-so violates
    the Ethernet spec" but that's a lie -- NONE OF THESE CHIPS OR
    SYSTEMS VIOLATED THE ETHERNET SPEC IN ANY WAY, SHAPE OR FORM.
    I looked very carefully for violations and have the pictures to
    prove there were none.

    Finally, all of the above is Copyright (c) 1988 by Van Jacobson.
    If you want to reproduce any part of it in print, you damn well
    better ask me first -- I'm getting tired of being misquoted in
    trade rags.

::::::::::::::
Received: from venera.isi.edu by NNSC.NSF.NET id aa06169; 30 Apr 90 4:43 EDT
Posted-Date: Mon, 30 Apr 90 01:40:59 PDT
Received: from vs.ee.lbl.gov by venera.isi.edu (5.61/5.61+local)
	id <AA05073>; Mon, 30 Apr 90 01:39:43 -0700
Received: by helios.ee.lbl.gov (5.61/1.39)
	id AA26743; Mon, 30 Apr 90 01:40:59 -0700
Message-Id: <9004300840.AA26743@helios.ee.lbl.gov>
To: end2end-interest@venera.isi.edu
Subject: modified TCP congestion avoidance algorithm
Date: Mon, 30 Apr 90 01:40:59 PDT
From: Van Jacobson <van@helios.ee.lbl.gov>

This is a description of the modified TCP congestion avoidance
algorithm that I promised at the teleconference.

BTW, on re-reading, I noticed there were several errors in
Lixia's note besides the problem I noted at the teleconference.
I don't know whether that's because I mis-communicated the
algorithm at dinner (as I recall, I'd had some wine) or because
she's convinced that TCP is ultimately irrelevant :).  Either
way, you will probably be disappointed if you experiment with
what's in that note.

First, I should point out once again that there are two
completely independent window adjustment algorithms running in
the sender:  Slow-start is run when the pipe is empty (i.e.,
when first starting or re-starting after a timeout).  Its goal
is to get the "ack clock" started so packets will be metered
into the network at a reasonable rate.  The other algorithm,
congestion avoidance, is run any time *but* when (re-)starting
and is responsible for estimating the (dynamically varying)
pipesize.  You will cause yourself, or me, no end of confusion
if you lump these separate algorithms (as Lixia's message did).

The modifications described here are only to the congestion
avoidance algorithm, not to slow-start, and they are intended to
apply to large bandwidth-delay product paths (though they don't
do any harm on other paths).  Remember that with regular TCP (or
with slow-start/c-a TCP), throughput really starts to go to hell
when the probability of packet loss is on the order of the
bandwidth-delay product.  E.g., you might expect a 1% packet
loss rate to translate into a 1% lower throughput but for, say,
a TCP connection with a 100 packet b-d p. (= window), it results
in a 50-75% throughput loss.  To make TCP effective on fat
pipes, it would be nice if throughput degraded only as function
of loss probability rather than as the product of the loss
probabilty and the b-d p.  (Assuming, of course, that we can do
this without sacrificing congestion avoidance.)

These mods do two things: (1) prevent the pipe from going empty
after a loss (if the pipe doesn't go empty, you won't have to
waste round-trip times re-filling it) and (2) correctly account
for the amount of data actually in the pipe (since that's what
congestion avoidance is supposed to be estimating and adapting to).

For (1), remember that we use a packet loss as a signal that the
pipe is overfull (congested) and that packet loss can be
detected one of two different ways:  (a) via a retransmit
timeout or (b) when some small number (3-4) of consecutive
duplicate acks has been received (the "fast retransmit"
algorithm).  In case (a), the pipe is guaranteed to be empty so
we must slow-start.  In case (b), if the duplicate ack
threshhold is small compared to the bandwidth-delay product, we
will detect the loss with the pipe almost full.  I.e., given a
threshhold of 3 packets and an LBL-MIT bandwidth-delay of around
24KB or 16 packets (assuming 1500 byte MTUs), the pipe is 75%
full when fast-retransmit detects a loss (actually, until
gateways start doing some sort of congestion control, the pipe
is overfull when the loss is detected so *at least* 75% of the
packets needed for ack clocking are in transit when
fast-retransmit happens).  Since the pipe is full, there's no
need to slow-start after a fast-retransmit.

For (2), consider what a duplicate ack means:  either the
network duplicated a packet (i.e., the NSFNet braindead IBM
token ring adapters) or the receiver got an out-of-order packet.
The usual cause of out-of-order packets at the receiver is a
missing packet.  I.e., if there are W packets in transit and one
is dropped, the receiver will get W-1 out-of-order and
(4.3-tahoe TCP will) generate W-1 duplicate acks.  If the
`consecutive duplicates' threshhold is set high enough, we can
reasonably assume that duplicate acks mean dropped packets.

But there's more information in the ack:  The receiver can only
generate one in response to a packet arrival.  I.e., a duplicate
ack means that a packet has left the network (it is now cached
at the receiver).  If the sender is limitted by the congestion
window, a packet can now be sent.  (The congestion window is a
count of how many packets will fit in the pipe.  The ack says a
packet has left the pipe so a new one can be added to take its
place.)  To put this another way, say the current congestion
window is C (i.e, C packets will fit in the pipe) and D
duplicate acks have been received.  Then only C-D packets are
actually in the pipe and the sender wants to use a window of C+D
packets to fill the pipe to its estimated capacity (C+D sent -
D received = C in pipe).

So, conceptually, the slow-start/cong.avoid/fast-rexmit changes
are:

  - The sender's input routine is changed to set `cwnd' to `ssthresh'
    when the dup ack threshhold is reached.  [It used to set cwnd to
    mss to force a slow-start.]  Everything else stays the same.

  - The sender's output routine is changed to use an effective window
    of min(snd_wnd, cwnd + dupacks*mss)  [the change is the addition
    of the `dupacks*mss' term.]  `Dupacks' is zero until the rexmit
    threshhold is reached and zero except when receiving a sequence
    of duplicate acks.

The actual implementation is slightly different than the above
because I wanted to avoid the multiply in the output routine
(multiplies are expensive on some risc machines).  A diff of the
old and new fastrexmit code is attached (your line numbers will
vary).

Note that we still do congestion avoidance (i.e., the window is
reduced by 50% when we detect the packet loss).  But, as long as
the receiver's offered window is large enough (it needs to be at
most twice the bandwidth-delay product), we continue sending
packets (at exactly half the rate we were sending before the
loss) even after the loss is detected so the pipe stays full at
exactly the level we want and a slow-start isn't necessary.

Some algebra might make this last clear:  Say U is the sequence
number of the first un-acked packet and we are using a window
size of W when packet U is dropped.  Packets [U..U+W) are in
transit.  When the loss is detected, we send packet U and pull
the window back to W/2.  But in the round-trip time it takes
the U retransmit to fill the receiver's hole and an ack to get
back, W-1 dup acks will arrive (one for each packet in transit).
The window is effectively inflated by one packet for each of
these acks so packets [U..U+W/2+W-1) are sent.  But we don't
re-send packets unless we know they've been lost so the amount
actually sent between the loss detection and the recovery ack is
U+W/2+W-1 - U+W = W/2-1 which is exactly the amount congestion
avoidance allows us to send (if we add in the rexmit of U).  The
recovery ack is for packet U+W so when the effective window is
pulled back from W/2+W-1 to W/2 (which happens because the
recovery ack is `new' and sets dupack to zero), we are allowed
to send up to packet U+W+W/2 which is exactly the first packet
we haven't yet sent.  (I.e., there is no sudden burst of packets
as the `hole' is filled.)  Also, when sending packets between
the loss detection and the recovery ack, we do nothing for the
first W/2 dup acks (because they only allow us to send packets
we've already sent) and the bottleneck gateway is given W/2
packet times to clean out its backlog.  Thus when we start
sending our W/2-1 new packets, the bottleneck queue is as empty
as it can be.

[I don't know if you can get the flavor of what happens from
this description -- it's hard to see without a picture.  But I
was delighted by how beautifully it worked -- it was like
watching the innards of an engine when all the separate motions
of crank, pistons and valves suddenly fit together and
everything appears in exactly the right place at just the right
time.]

Also note that this algorithm interoperates with old tcp's:  Most
pre-tahoe tcp's don't generate the dup acks on out-of-order packets.
If we don't get the dup acks, fast retransmit never fires and the
window is never inflated so everything happens in the old way (via
timeouts).  Everything works just as it did without the new algorithm
(and just as slow).

If you want to simulate this, the intended environment is:

    - large bandwidth-delay product (say 20 or more packets)

    - receiver advertising window of two b-d p (or, equivalently,
      advertised window of the unloaded b-d p but two or more
      connections simultaneously sharing the path).

    - average loss rate (from congestion or other source) less than
      one lost packet per round-trip-time per active connection.
      (The algorithm works at higher loss rate but the TCP selective
      ack option has to be implemented otherwise the pipe will go empty
      waiting to fill the second hole and throughput will once again
      degrade at the product of the loss rate and b-d p.  With selective
      ack, throughput is insensitive to b-d p at any loss rate.)

And, of course, we should always remember that good engineering
practise suggests a b-d p worth of buffer at each bottleneck --
less buffer and your simulation will exhibit the interesting
pathologies of a poorly engineered network but will probably
tell you little about the workings of the algorithm (unless the
algorithm misbehaves badly under these conditions but my
simulations and measurements say that it doesn't).  In these
days of $100/megabyte memory, I dearly hope that this particular
example of bad engineering is of historical interest only.

 - Van

-----------------
*** /tmp/,RCSt1a26717	Mon Apr 30 01:35:17 1990
--- tcp_input.c	Mon Apr 30 01:33:30 1990
***************
*** 834,850 ****
  				 * Kludge snd_nxt & the congestion
  				 * window so we send only this one
! 				 * packet.  If this packet fills the
! 				 * only hole in the receiver's seq.
! 				 * space, the next real ack will fully
! 				 * open our window.  This means we
! 				 * have to do the usual slow-start to
! 				 * not overwhelm an intermediate gateway
! 				 * with a burst of packets.  Leave
! 				 * here with the congestion window set
! 				 * to allow 2 packets on the next real
! 				 * ack and the exp-to-linear thresh
! 				 * set for half the current window
! 				 * size (since we know we're losing at
! 				 * the current window size).
  				 */
  				if (tp->t_timer[TCPT_REXMT] == 0 ||
--- 834,850 ----
  				 * Kludge snd_nxt & the congestion
  				 * window so we send only this one
! 				 * packet.
! 				 *
! 				 * We know we're losing at the current
! 				 * window size so do congestion avoidance
! 				 * (set ssthresh to half the current window
! 				 * and pull our congestion window back to
! 				 * the new ssthresh).
! 				 *
! 				 * Dup acks mean that packets have left the
! 				 * network (they're now cached at the receiver) 
! 				 * so bump cwnd by the amount in the receiver
! 				 * to keep a constant cwnd packets in the
! 				 * network.
  				 */
  				if (tp->t_timer[TCPT_REXMT] == 0 ||
***************
*** 853,864 ****
  				else if (++tp->t_dupacks == tcprexmtthresh) {
  					tcp_seq onxt = tp->snd_nxt;
! 					u_int win =
! 					    MIN(tp->snd_wnd, tp->snd_cwnd) / 2 /
! 						tp->t_maxseg;
  
  					if (win < 2)
  						win = 2;
  					tp->snd_ssthresh = win * tp->t_maxseg;
- 
  					tp->t_timer[TCPT_REXMT] = 0;
  					tp->t_rtt = 0;
--- 853,864 ----
  				else if (++tp->t_dupacks == tcprexmtthresh) {
  					tcp_seq onxt = tp->snd_nxt;
! 					u_int win = MIN(tp->snd_wnd,
! 							tp->snd_cwnd);
  
+ 					win /= tp->t_maxseg;
+ 					win >>= 1;
  					if (win < 2)
  						win = 2;
  					tp->snd_ssthresh = win * tp->t_maxseg;
  					tp->t_timer[TCPT_REXMT] = 0;
  					tp->t_rtt = 0;
***************
*** 866,873 ****
  					tp->snd_cwnd = tp->t_maxseg;
  					(void) tcp_output(tp);
! 
  					if (SEQ_GT(onxt, tp->snd_nxt))
  						tp->snd_nxt = onxt;
  					goto drop;
  				}
  			} else
--- 866,879 ----
  					tp->snd_cwnd = tp->t_maxseg;
  					(void) tcp_output(tp);
! 					tp->snd_cwnd = tp->snd_ssthresh +
! 						       tp->t_maxseg *
! 						       tp->t_dupacks;
  					if (SEQ_GT(onxt, tp->snd_nxt))
  						tp->snd_nxt = onxt;
  					goto drop;
+ 				} else if (tp->t_dupacks > tcprexmtthresh) {
+ 					tp->snd_cwnd += tp->t_maxseg;
+ 					(void) tcp_output(tp);
+ 					goto drop;
  				}
  			} else
***************
*** 874,877 ****
--- 880,890 ----
  				tp->t_dupacks = 0;
  			break;
+ 		}
+ 		if (tp->t_dupacks) {
+ 			/*
+ 			 * the congestion window was inflated to account for
+ 			 * the other side's cached packets - retract it.
+ 			 */
+ 			tp->snd_cwnd = tp->snd_ssthresh;
  		}
  		tp->t_dupacks = 0;
*** /tmp/,RCSt1a26725	Mon Apr 30 01:35:23 1990
--- tcp_timer.c	Mon Apr 30 00:36:29 1990
***************
*** 223,226 ****
--- 223,227 ----
  		tp->snd_cwnd = tp->t_maxseg;
  		tp->snd_ssthresh = win * tp->t_maxseg;
+ 		tp->t_dupacks = 0;
  		}
  		(void) tcp_output(tp);

::::::::::::::
Received: from venera.isi.edu by NNSC.NSF.NET id aa08372; 30 Apr 90 13:36 EDT
Posted-Date: Mon, 30 Apr 90 10:36:12 PDT
Received: from vs.ee.lbl.gov by venera.isi.edu (5.61/5.61+local)
	id <AA19258>; Mon, 30 Apr 90 10:35:01 -0700
Received: by helios.ee.lbl.gov (5.61/1.39)
	id AA27020; Mon, 30 Apr 90 10:36:14 -0700
Message-Id: <9004301736.AA27020@helios.ee.lbl.gov>
To: end2end-interest@venera.isi.edu
Subject: modified TCP congestion avoidance algorithm (correction)
Date: Mon, 30 Apr 90 10:36:12 PDT
From: Van Jacobson <van@helios.ee.lbl.gov>

I shouldn't make last minute 'fixes'.  The code I sent out last
night had a small error:

*** t.c	Mon Apr 30 10:28:52 1990
--- tcp_input.c	Mon Apr 30 10:30:41 1990
***************
*** 885,893 ****
  			 * the congestion window was inflated to account for
  			 * the other side's cached packets - retract it.
  			 */
! 			tp->snd_cwnd = tp->snd_ssthresh;
  		}
- 		tp->t_dupacks = 0;
  		if (SEQ_GT(ti->ti_ack, tp->snd_max)) {
  			tcpstat.tcps_rcvacktoomuch++;
  			goto dropafterack;
--- 885,894 ----
  			 * the congestion window was inflated to account for
  			 * the other side's cached packets - retract it.
  			 */
! 			if (tp->snd_cwnd > tp->snd_ssthresh)
! 				tp->snd_cwnd = tp->snd_ssthresh;
! 			tp->t_dupacks = 0;
  		}
  		if (SEQ_GT(ti->ti_ack, tp->snd_max)) {
  			tcpstat.tcps_rcvacktoomuch++;
  			goto dropafterack;
::::::::::::::
Received: from rx7.ee.lbl.gov by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
	id AA12583 for popbbn; Wed, 8 Sep 93 01:29:46 -0400
Received: by rx7.ee.lbl.gov for craig@aland.bbn.com (5.65/1.44r)
	id AA05271; Tue, 7 Sep 93 22:30:15 -0700
Message-Id: <9309080530.AA05271@rx7.ee.lbl.gov>
To: Craig Partridge <craig@aland.bbn.com>
Cc: David Clark <ddc@lcs.mit.edu>
Subject: Re: query about TCP header on tcp-ip 
In-Reply-To: Your message of Tue, 07 Sep 93 09:48:00 PDT.
Date: Tue, 07 Sep 93 22:30:14 PDT
From: Van Jacobson <van@ee.lbl.gov>

Craig,

As you probably remember from the "High Speed TCP" CNRI meeting,
my kernel looks nothing at all like any version of BSD.  Mbufs
no longer exist, for example, and `netipl' and all the protocol
processing that used to be done at netipl interrupt level are
gone.  TCP receive packet processing in the new kernel really is
about 30 instructions on a RISC (33 on a sparc but three of
those are compiler braindamage).  Attached is the C code & the
associated sparc assembler.

A brief recap of the architecture:  Packets go in 'pbufs' which
are, in general, the property of a particular device.  There is
exactly one, contiguous, packet per pbuf (none of that mbuf
chain stupidity).  On the packet input interrupt, the device
driver upcalls through the protocol stack (no more of that queue
packet on the netipl software interrupt bs).  The upcalls
percolate up the stack until the packet is completely serviced
(e.g., NFS requests that can be satisfied from in-memory data &
data structures) or they reach a routine that knows the rest of
the processing must be done in some process's context in which
case the packet is laid on some appropriate queue and the
process is unblocked.  In the case of TCP, the upcalls almost
always go two levels: IP finds the datagram is for this host &
it upcalls a TCP demuxer which hashes the ports + SYN to find a
PCB, lays the packet on the tail of the PCB's queue and wakes up
any process sleeping on the PCB.  The IP processing is about 25
instructions & the demuxer is about 10.

As Dave noted, the two processing paths that need the most
tuning are the data packet send & receive (since at most every
other packet is acked, there will be at least twice as many data
packets as ack packets).  In the new system, the receiving
process calls 'tcp_usrrecv' (the protocol specific part of the
'recv' syscall) or is already blocked there waiting for new
data.  So the following code is embedded in a loop at the start of
tcp_usrrecv that spins taking packets off the pcb queue until
there's no room for the next packet in the user buffer or the
queue is empty.  The TCP protocol processing is done as we
remove packets from the queue & copy their data to user space
(and since we're in process context, it's possible to do a
checksum-and-copy).

Throughout this code, 'tp' points to the pcb and 'ti' points to
the tcp header of the first packet on the queue (the ip header was
stripped as part of interrupt level ip processing).  The header info
(excluding the ports which are implicit in the pcb) are sucked out
of the packet into registers [this is to minimize cache thrashing and
possibly to take advantage of 64 bit or longer loads].  Then the
header checksum is computed (tp->ph_sum is the precomputed pseudo-header
checksum + src & dst ports).

int tcp_usrrecv(struct uio* uio, struct socket* so)
{
	struct tcpcb *tp = (struct tcpcb *)so->so_pcb;
	register struct pbuf* pb;

	while ((pb = tp->tp_inq) != 0) {
		register int len = pb->len;
		struct tcphdr *ti = (struct tcphdr *)pb->dat;

		u_long seq = ((u_long*)ti)[1];
		u_long ack = ((u_long*)ti)[2];
		u_long flg = ((u_long*)ti)[3];
		u_long sum = ((u_long*)ti)[4];
		u_long cksum = tp->ph_sum;

		/* NB - ocadd is an inline gcc assembler function */
		cksum = ocadd(ocadd(ocadd(ocadd(cksum, seq), ack), flg), sum);

Next is the header prediction check which is probably the most
opaque part of the code.  tp->pred_flags contains snd_wnd (the
window we expect in incoming packets) in the bottom 16 bits and
0x4x10 in the top 16 bits.  The 'x' is normally 0 but will be
set non-zero if header prediction shouldn't be done (e.g., if
not in established state, if retransmitting, if hole in seq
space, etc.).  So, the first term of the 'if' checks four
different things simultaneously:
 - that the window is what we expect
 - that there are no tcp options
 - that the packet has ACK set & doesn't have SYN, FIN, RST or URG set
 - that the connection is in the right state
and the 2nd term of the if checks that the packet is in sequence:

#define FMASK (((0xf000 | TH_SYN|TH_FIN|TH_RST|TH_URG|TH_ACK) << 16) | 0xffff)

        if ((flg & FMASK) == tp->pred_flags && seq == tp->rcv_nxt) {

The next few lines are pretty obvious -- we subtract the header
length from the total length and if it's less than zero the packet
was malformed, if it's zero we must have a pure ack packet & we
do the ack stuff otherwise if the ack field didn't move we have
a pure data packet which we copy to the user's buffer, checksumming
as we go, then update the pcb state if everything checks:

                len -= 20;
                if (len <= 0) {
                        if (len < 0) {
                                /* packet malformed */
                        } else {
                                /* do pure ack things */
                        }
                } else if (ack == tp->snd_una) {
                        cksum = in_uiomove((u_char*)ti + 20, len, uio, cksum);
                        if (cksum != 0) {
                                /* packet or user buffer errors */
                        }
                        seq += len;
                        tp->rcv_nxt = seq;
                        if ((int)(seq - tp->rcv_acked) >= 0) {
                                /* send ack */
                        } else {
                                /* free pbuf */
                        }
			continue;
		}
	}
	/* header prediction failed -- take long path */
	...

That's it.  On the normal receive data path we execute 16 lines of
C which turn into 33 instructions on a sparc (it would be 30 if I
could trick gcc into generating double word loads for the header
& my carefully aligned pcb fields).  I think you could get it down
around 25 on a cray or big-endian alpha since the loads, checksum calc
and most of the compares can be done on 64 bit quantities (e.g.,
you can combine the seq & ack tests into one).

Attached is the sparc assembler for the above receive path.  Hope
this explains Dave's '30 instruction' assertion.  Feel free to
forward this to tcp-ip or anyone that might be interested.

 - Van

 ----------------
	ld [%i0+4],%l3			! load packet tcp header fields
	ld [%i0+8],%l4
	ld [%i0+12],%l2
	ld [%i0+16],%l0

	ld [%i1+72],%o0			! compute header checksum
	addcc %l3,%o0,%o3
	addxcc %l4,%o3,%o3
	addxcc %l2,%o3,%o3
	addxcc %l0,%o3,%o3

	sethi %hi(268369920),%o1	! check if hdr. pred possible
	andn %l2,%o1,%o1
	ld [%i1+60],%o2
	cmp %o1,%o2
	bne L1
	ld [%i1+68],%o0
	cmp %l3,%o0
	bne L1
	addcc %i2,-20,%i2
	bne,a L3
	ld [%i1+36],%o0
	  ! packet error or ack processing
	  ...
L3:
	cmp %l4,%o0
	bne L1
	add %i0,20,%o0
	mov %i2,%o1
	call _in_uiomove,0
	mov %i3,%o2
	cmp %o0,0
	be L6
	add %l3,%i2,%l3
	  ! checksum error or user buffer error
	  ...
L6:
	ld [%i1+96],%o0
	subcc %l3,%o0,%g0
	bneg L7
	st %l3,[%i1+68]
	  ! send ack
	  ...
	  br L8
L7:
	  ! free pbuf
	  ...
L8:	! done with this packet - continue
	...

L1:	! hdr pred. failed - do it the hard way

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 1993 16:48:08 GMT
From:      maf@dunedin.acs.ohio-state.edu (Mark Fullmer)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple subnets on same physical wire

In article <me.753095807@tartufo> me%dude.pcs.dec.com@inet-gw-2.pa.dec.com writes:
>In <2br8m3$on9@charm.magnus.acs.ohio-state.edu> maf@dunedin.acs.ohio-state.edu (Mark Fullmer) writes:
>
>>It's easier in the end to just change the subnet mask to have the hosts
>>think they can talk to the entire network, then have the router do proxy
>>arp for the subnets on the 'other' ports.
>
>Maybe I'm not understanding the whole point, but what's wrong with
>just using static routes that point to the respective other net?
>I agree, you'll have to set them up, but so you have to do with the
>actual IP-Address and net mask.

That's fine until you are forced to support IP stacks that only know
about a default router - ie. many DOS applications.

>We are running two different subnets in this building on the same wire
>(16.186.144.0 and 16.186.160.0). We have a router with addresses in
>both nets that runs rip (its actual job is to route to the rest of our
>net). Without doing anything special, just using routed, machines on
>both subnets can talk together through the router. This doesn't make
>much sense, however, since the packets get put onto the same wire
>again, effectively doubling the net load for communication between
>the nets.
>
>All we had to do to have the net run properly was add static routes to
>the "other" net on all the workstations. E.g.
>
>	/etc/route add net 16.186.160 tartufo 0
>
>on my machine tartufo (16.186.144.131)
>
>Could somebody please enlighten me, if we actually have a possible
>problem with this solution?

Your setup is correct.  

--
mark
maf+@osu.edu


-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 93 17:12:13 GMT
From:      baine@fozzie.cc.wwu.edu (Baine Werny)
To:        comp.protocols.tcp-ip
Subject:   HELP! SLIP and LANtastic v5.0 AI

Hello,


We have about 30 users on a LANtastic v5.0 AI network. Because of the 
location of the building we are in, the best connection we can get to 
the campus wide network is through a dedicated serial line which is 
connected to a UNIX machine. The UNIX machine is then connected to the 
Internet.

Our users need internet access. I need to provide the Internet access to
my users from MS-Windows using LANtastic and the serial line connected to
the UNIX machine. I am well aware of the multitude of PD software
available for accessing these services from MS-Windows.  Specifically, we
need TELNET, FTP, GOPHER, USENET, and E-MAIL access. 

So, what I think we need to do is set up a machine as a router. This 
machine will be connected to our LANtastic LAN and a serial line directly 
to the campus net.  It will route TCP/IP packets to and from out LAN via
SLIP/CSLIP/PPP.

Therefore, how do I do this? What pieces do I need? In other words, the
how do I do this using Public Domain software and our LANtastic v5.0
network? 

Can someone give me an arbitrary list of software that would work here?



Thanks in advance for your help!



-Baine

baine@cc.wwu.edu
Western Washington University
University Residences
Bellingham, WA  98225-9113
Phone: (206) 650-3288
FAX:   (206) 650-6890








-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Nov 93 17:33:40 GMT
From:      ian@sq.sq.com (Ian Darwin)
To:        comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Re: Public Domain Tooltalk Clone

Scott Wallace (scott@zmax.com) writes:
> I'm looking for a public domain tool which will run using tcp-ip
> with capabilities similar to tooltalk.
> 
>   The reason I don't want to use tooltalk is that it's not widely
> ported enough yet, and I only want to exchange messages between
> different processes in the application I'm writing. I'd prefer not
> to have to use System 5 type shared memory or message queue based
> methods of sharing info between processes.

I think you will find that Tooltalk has already been ported to all major UNIX
platforms. The COSE "Common Desktop (CDE)" - prepared by HP SUN IBM SCO and
Novell/USL/USG and subsequently endorsed by at least DEC - includes
ToolTalk. All those vendors expect to be shipping CDE in 1994.

If you have a Sun to work on, use Tooltalk. If not, and you just can't
wait, talk to your vendor about seeing if they can give you an early
access version of the CDE desktop.


-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 1993 17:40:54 GMT
From:      heathh@cco.caltech.edu (Heath Ian Hunnicutt)
To:        comp.protocols.tcp-ip
Subject:   Re: LPD use of client port numbers (does RFC-1179 reflect reality?)

scott@nova.tcs.tufts.edu (Scott R. Corzine) writes:

>Hi-
 
>    [Do LPD's enforce RFC 1179's claim that clients must use ports
>	721-731.]

	Some do.  HP-UX 8.x is a notable example.  Also, many firmware
implementations of LPD exist, and these implementations often stick
to the very letter of 1179.
	So, you might want to try solving this by only using ports 721-731
if other ports fail.
	BTW, the reason this is an 11 port range is that there was a 
fencepost error in the original LPD.  :)  What a great protocol.
	Also, be warned: most LPD's DO NOT accept variable length jobs,
since the RFC newver says how the client should signal end-of-stream.

Later,
Heath

-- 
--
From the Home for Amnesiac Computer Scientists....
  heathh@cco.caltech.edu


-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 1993 20:16:12 GMT
From:      jbrady@deepriver.East.Sun.COM (John Brady - SunNetworks Consultant)
To:        comp.protocols.tcp-ip
Subject:   NEED: PC X-server recommendation...


What is the consensus choice for the best DOS/Windows PC X-server product?

Also any rules of thumb concerning processor, memory and storage needs associated
with adding an X-server to a PC.

TIA.  E-mail prefered, will summarize.

John Brady
Network Management Consultant
SunNetworks, A Sun Microsystems, Inc. Business
(703) 204-4859
john.brady@East.Sun.Com


-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Nov 1993 21:31:32 GMT
From:      lcz@dptspd.sat.datapoint.com (Lee Ziegenhals)
To:        comp.os.ms-windows.setup,comp.os.ms-windows.misc,comp.protocols.tcp-ip
Subject:   Re: Windows for Workgroups over TCP/IP

philp@universe.digex.net (Phil Perucci) writes:

>For another $49.00, we got an unlimited license for the Microsoft TCP/IP
>layer.  Does the WFW stuff over TCP/IP, but the only utility you get is 
>ping.  No telnet/ftp just the WFW client/server stuff.  I use it whenever
>I have to use a spreadsheet or word-processor on the NT server at work.

Can anyone suggest a source for the TCP/IP stack for WFW?  I've heard a
lot about it but haven't seen it advertized anywhere.

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Nov 1993 22:09:50 GMT
From:      waynej@ncs.com (Wayne Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: Question about SLIP servers

In article <1993Nov7.174919.7974@dscatl.atl.ga.us> lindsay@dscatl.atl.ga.us (Lindsay Cleveland) writes:
>In article <sjsCG1HnC.HzM@netcom.com> sjs@netcom.com (Stephen Schow) writes:
>>I am wondering if there are any kind of SLIP "servers" or some such thing.
>>Basically I need a device which would sit on our ethernet(TCP/IP) network.
>
>We have been using the Telebit NetBlazer for just this function.
>It will establish either SLIP or PPP connections, support a modem
>pool for both in-coming and out-going links (SLIP, PPP, or plain
>old ASCII terminal emulation), and can also function as a router.
>Has Telnet and FTP capability between it and any other network node.

We've been using the Livingston PortMaster modem server for the same purpose.
It comes with 16 lines for less than $1500 (when be bought 15 months ago).
We went with Livingston because it was cheaper than NetBlazer and support
just about any modems.
-- 
Wayne D. T. Johnson       Internet: waynej@ncs.com      Phone: (612) 830-7880
     National Computer Systems, 4401 West 76th Street,  Edina, Mn.  55435 
"He is no fool, who gives up what he cannot keep, for what he cannot lose"
                                           - Jim Elliott

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 93 22:59:08 GMT
From:      thayne@unislc.slc.unisys.com (Thayne Forbes)
To:        comp.protocols.tcp-ip
Subject:   Re: Good books on TCP/IP for beginners

Phuong Thanh Nguyen (nguyen@PHUONG.raleigh.ibm.com) wrote:
: In article <CG8rt9.3GA@ncifcrf.gov>, brownje@ncifcrf.gov (Janet E. Brown) writes:
: |> Have you seen Vol. IV of the Comer books? Also, I can't remember the 
: |> title, but the author is Richard Stevens. I was fortunate to get into 
: |> ione of his classes and his books are excellent. 
: |> 
: 	I don't think there is Vol IV of Comer books yet.  About the book
: of Richard Stevens has the title "UNIX Network Programming" .  There is
: a new Richard Steven's book title "Network Illustrated" is going coming
: out in December if I'm not mistaken.  I expect this one is going to be
: a good one for network programming based on the impression I got from his
: "UNIX Network Programming".

Just so we get this exactly correct.  As D.L. Stevens points out, there
are only three volumes in the Internetworking series.  Further, the
new book by Richard Stevens is titled TCP/IP Illustrated, Volume 1
The Protocols.  As you might infer from the title, it is not about
network programming, but rather a description of the protocols.  The
illustrated part means that he explains all the ins and outs of the
various flags, and fields that are otherwise easy to breeze over and
ignore.  From what I have seen, if you like Richard Stevens presentation 
in Network Programming, you will like TCP/IP Illustrated.  And by the
way, I do love Unix Network Programming.

-- 
Thayne Forbes         thayne@unislc.slc.unisys.com
Unisys Unix Support Engineering,    Salt Lake City.
Phone: (801) 594-4448          Fax: (801) 594-3827

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 1993 23:35:48 GMT
From:      ddavis@osiris.cso.uiuc.edu (Dave Davis)
To:        comp.os.ms-windows.setup,comp.os.ms-windows.misc,comp.protocols.tcp-ip
Subject:   Re: Windows for Workgroups over TCP/IP

lcz@dptspd.sat.datapoint.com (Lee Ziegenhals) writes:

>philp@universe.digex.net (Phil Perucci) writes:
 
>>For another $49.00, we got an unlimited license for the Microsoft TCP/IP
>>layer.  Does the WFW stuff over TCP/IP, but the only utility you get is 
>>ping.  No telnet/ftp just the WFW client/server stuff.  I use it whenever
>>I have to use a spreadsheet or word-processor on the NT server at work.
 
>Can anyone suggest a source for the TCP/IP stack for WFW?  I've heard a
>lot about it but haven't seen it advertized anywhere.

You can call Microsoft Inside Sales (800.426.9400) and buy it for $49.99 + S&H
or you can ftp the disk images from ftp.microsoft.com in the directory
Advsys/MSClient/35 (I believe that's it; if not it's pretty close).  There is
a readme file with disk image version, but no printed documentation of course.
The printed documents can be ordered separately.  

dave

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 93 19:11:18 PST
From:      henderson@mln.com (Javier Henderson)
To:        comp.dcom.lans.misc,comp.protocols.tcp-ip
Subject:   Exceeding a Class C network capacity

We are soon to exceed our Class C network capacity. The Internic suggests
subnetting. Are there any drawbacks to that? By the end of the year, we will
have 300 nodes, and our final network size will be around 3,000 nodes (in about
three to four years). We will have about 1,500 nodes by the end of 1994.

Thanks,

Jav
henderson@mln.com

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Nov 1993 15:08:01 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Ethernet overload due to faulty TCP/IP implementations

> Couldn't you just filter broadcasts on the bridges to your 5Mbit/s  
> backbone so that those packets would not get forwarded?  

Of course not. We still want ARP & friends to work, across the backbone.
Hopefully one day *all* networks will connect to the backbone through
routers, and then that particular problem will no longer exist.

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Nov 1993 19:28:26 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: How to change the timeout of "connect" system call.

Larry Roberts (lroberts@nyx10.cs.du.edu) writes:
> How do I change the timout on the connect system call?

  Use alarm(2) and signal(2).  The connect(2) will fail with EINTR.  Your
  signal handler could set a global flag to distinguish the timeout.

-- Ken Mintz

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Nov 1993 19:41:56 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip,de.comp.os.unix
Subject:   Re: IP broadcast conventions

Carsten Lutz (clu@malihh.hanse.de) writes:
> For the last part, two different 
> conventions are used by the manufacturers: some fill the last bits ( the ones
> which are 0 in the netmask ) with 0 ( e.g. SUN ), others with 1 ( e.g. HP ).
  :
> What is the most common convention ?

  RFC-1122 specifies the use of all-ones.  All-zeros is an old convention
  (4.2BSD).  Some systems permit selecting all-ones or all-ones (e.g., 
  with the ifconfig(1m) command).

> I wonder what can be the consequences if both conventions are used on
> the same network. I read it could be a broadcast storm. Why ?

  RFC-1122 states that systems SHOULD recognize both types of broadcast.
  But that will depend on system implementation.

  The networks could become flooded with ICMP error messages if receiving
  systems do not recognize the IP address as a broadcast and respond, despite
  the fact that the IP datagram was broadcasted at the link layer (not
  RFC-1122 conformant).

  This problem can always arise, notwithstanding broadcast conventions, if
  subnet masks do not agree, again if the receiving IP ignores the fact that
  the datagram had been broadcasted at the link layer.

-- Ken Mintz

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 1993 15:07:11 -0600
From:      swisher@cs.utexas.edu (Janet M. Swisher)
To:        comp.os.ms-windows.apps,alt.winsock,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Slow telnet response w/ QVTNet/trmpwsk/SLIP


I am using WinQVT/Net 3.81 with Trumpet Winsock alpha 17 over a SLIP
connection.  I typically have several telnet sessions open to the same
remote machine at the same.  Occasionally, I will find that one of the
telnet windows develops very poor interactive response -- characters
typed do not appear for several seconds (can be as much as a couple
minutes), which makes normal operations like editing, mail and news
amazingly tedious.  If I switch to a different telnet window, the
response in that window is fine; therefore, the delay would not seem
to be caused by load on the remote machine.  Which window has the
delay is random, and one may quit doing it but another one starts.

Can anyone suggest how to debug what is causing this?  It might be
network traffic between the remote machine and the SLIP server; it
might be in the SLIP server, or it might be in winsock or WinQVT/Net.
I'd like to be able to figure out if there's anything I can do about
it, such as using a different winsock.dll.

-- 
I know who I was when I got up this morning, but I think I must have
changed several times since then -- Alice in Wonderland


-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 93 21:51:43 CDT
From:      kmoch@whscdp.whs.edu
To:        comp.protocols.tcp-ip
Subject:   KA9Q FAQ?

Somewhere I thought I saw a FAQ related to KA9Q and TCP/IP.  Can someone please
help me find it?  If this is the wrong place to post this question, can someone
tell me the appropriate place to post this question?

Thanks for your time.
-- 
--
Joe Kmoch                                   Washington High School
kmoch@whscdp.whs.edu                        2525 N. Sherman Blvd
(414) 449-2765 (office)                     Milwaukee, WI  53210
(414) 444-9250 (fax)                        (414) 444-9760 (gen school phone)

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Nov 1993 17:17:14 GMT
From:      houseman@hopper.ACS.Virginia.EDU (Carl Houseman)
To:        comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Exceeding a Class C network capacity

In article <1993Nov13.191118.196@mln>,
Javier Henderson <henderson@mln.com> wrote:
>We are soon to exceed our Class C network capacity. The Internic suggests
>subnetting. Are there any drawbacks to that? By the end of the year, we will
>have 300 nodes, and our final network size will be around 3,000 nodes (in about
>three to four years). We will have about 1,500 nodes by the end of 1994.

Subnetting?  Subnetting a class C network results in fewer usable addresses.
What was the NIC suggesting, exactly?

When I asked the NIC about the availability of class B addresses, I was told
I needed to predict far more than 1000's of nodes to get one.  They suggested
I apply for additional class C addresses.  Maybe that's what they meant for
"subnetting"?

In this case the only drawback I know of is getting the routing right, if
you want all your internal traffic to stay internal.  I'd like to hear from
anyone else that has done that, too, if there are tricks to be followed.

--
Carl Houseman
houseman@hopper.acs.virginia.edu
GENICOM Corporation, Waynesboro, VA

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 1993 04:21:45 GMT
From:      mferrare@physics.adelaide.edu.au (Mark Ferraretto)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   Problems running Novell, PC-NFS, Windows, eXcursion

Has anyone tried this?

Dos V5.0 or V6.0
Novell Netware 3.11
PC-NFS 4.0
eXcursion (X Window for PC software)
Windows?

By the time I have all the TSRs loaded I have 365K free under Dos 6 and about
300K free in Dos 5.  This is not a lot.  this setup is also a picture of 
instability.  When it does work and I can get into windows, i have more
problems.  PC-NFS installs its own net drivers which means I can't talk to
my novell print queues or run CC:mail and I get a whole lot of GPFs.  
eXcursion GPFs sporadically.  When it does work it is slloooowww.

Anyhow, I seem to be crowding DOSs real memory area.  Is there a better way to
do what I want (NFS and X on a PC) with the above software?  Has anybody else
done it?

If I don't get this working I'll just have to head back to my OS/2 system.
No segmented memory problems there...

PS  I'm running on a 486DX250 with 16MB RAM, lots of disk and DOS 5 & 6 (6 at
the moment).

--
   \ | /   PA38.| Now | Name  : Mark Ferraretto
-----O-----Gotta| Aero| Place : Department of Physics and Mathematical Physics
     |     love |Rated|         University of Adelaide
    ---    it!! |-----| Email : mferrare@physics.adelaide.edu.au

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Nov 1993 04:26:30 GMT
From:      benno@ist.flinders.edu.au (Benno Rice)
To:        comp.protocols.tcp-ip
Subject:   SL/IP info wanted

Hi,
   I want info about SL/IP, either for DOS/Windows, UNIX or Mac.
   Please mail me.
	Benno.




-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Nov 1993 05:00:03 GMT
From:      tsukako@sdl.hitachi.co.jp (Masato Tsukakoshi)
To:        comp.protocols.tcp-ip
Subject:   Re: IPng -- need info


>> Could some knowledgeable soul please point me to information
>> about the discussion concerning IPng?
>> 

I recommend you should read info.big-internet and info.ietf.

--
Masato Tsukakoshi   
Systems Development Laboratory, Hitachi, Ltd.
Voice: +81-44-966-9111   Fax: +81-44-966-6853
E-mail:tsukako@sdl.hitachi.co.jp

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Nov 1993 10:14:37 GMT
From:      lmd@cayman (Luis Delgado)
To:        comp.protocols.tcp-ip
Subject:   Re: Can't run PC/TCP with windows

timmi@ftp.com (Kitchen Staff Supervisor) writes:
: In article <CGA9y7.9Bq@inesc.pt> lmd@cayman (Luis Delgado) writes:
: 
: *Hello:
: *
: *I'm experiencing some performance problems with PCTCP 2.2 while running
: *windows 3.1.
: *
: *When I run PCTCP (telnet for example) in DOS, over a SLIP connection, the
: *performance is more than satisfactory, but when I run it in windows, it
: *freezes (the telnet program- TN) as soon as I'm logged in at the remote node.
: *
: *So I think, this sould be a windows configuration problem.
: 
: Are you having trouble with antyof the other applications in this
: case?  In other words, can you PING or FTP under windows, either
: using the DOS apps or the Windows applications?  Can you connect
: using the WTNVT application.  If the problem is specific to TN, then
: it may be a confilct between the TN application and the Windows video
: driver you are using.  If the problem is specific to TN, try adding
: the line "card=vga" to the [PCTCP SCREEN] section of your PCTCP.INI
: file.  If the problem is not specific to TN, please contact me.
: --
: Timothy G. Reynolds					FTP Software, Inc.
: Technical Support					2 High St.
: timmi-email@ftp.com					N. Andover, MA
: (800) 382-4FTP							01845
: 
:   "I just want someone to say to me, 'I'll always be there when you wake'"
: 
Hello, thanks for your reply, Timmi:

I'm having problems with all PCTCP DOS apps, when being run within windows.
If run from DOS, no problem occours.
The problem is the following: the application just hang almost after logging
in at the remote node. Some times it recover after a few minutes and then 
hang again.
If I use the PCTCP WIN apps no problem occours. Everithing goes smothly.
The applications I tried that gave me problems are TN and FTP for DOS.

I thing this must be some conflict between DOS and WINDOWS, but can't figure
what.

I tried your sugestion of puting, "card = vga" in "[pctcp screen]" group
in pctcp.ini file, but whithout any success.

Thanks for any further help.

Best Regards,
Luis Delgado, lmd@inesc.pt, cis:10024,3520
INESC-CCAE, Lisbon, Portugal

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 1993 12:39:39 GMT
From:      liebe@sun2.hrz.th-darmstadt.de (Andreas Liebe)
To:        comp.protocols.tcp-ip
Subject:   Re: ARCHIE client protcol specs

In article <rmercer.4.0@cybercon.nb.ca>, rmercer@cybercon.nb.ca (Ron Mercer) writes:
|>  I want to write an ARCHIE client for an ibm-pc does any one know where
|> I can find the protocol specification. I've looked in the RFC's but no luck.
|> Thanks.

Hi Ron,

 c-archie-1.4.1 should run with DOS, but I've never tried it. The sources are
in ftp.th-darmstadt:/pub/archie/clients/c-archie-1.4.1.tar.Z. You should also
take a look at the sources if you want to write a client from scratch.

 If you want to find out more about prospero, the protocol used by archie,
you should search for 'prospero-alpha.5.2a.tar.Z', e.g.
wuarchive.wustl.edu:/packages/prospero

 If you wrote a nice archie-client, please let me know,

	-Andreas

-- 
     _        _  _  _  TH-Darmstadt               Voice: +49 6151 16 3150
   /_/ /  / /_ /_//_   Network Department         Fax:   +49 6151 16 3050     
  / /./_ / /_ /_//_    Petersenstrasse 30         EMail:
                       D-64287 Darmstadt (Germany)  liebe@hrz.th-darmstadt.de

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 1993 23:02:59 -0600
From:      devil@daisy.cc.utexas.edu (Khurram Qureshi)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   TELNET control

If you telnet to a server port from a client machine, 
how do you get the server to execute one of its files?
and send its i/o to the user's terminal?

For example, there is a file called 'action' on the 
server hermes. The server is listening for connections
to port 6500. The remote user telnet's to hermes port 
6500. How does the server go about executing 'action'
once the telnet connection is established? and displaying
any i/o required in the remote user's terminal?

Thanks,
Khurram Qureshi.

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 93 15:03:19
From:      amoss@picton.cs.huji.ac.il (Amos Shapira)
To:        comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Exceeding a Class C network capacity

houseman@hopper.ACS.Virginia.EDU (Carl Houseman) writes:

|Javier Henderson <henderson@mln.com> wrote:
|>We are soon to exceed our Class C network capacity. The Internic suggests
|>subnetting. Are there any drawbacks to that? By the end of the year, we will
|>have 300 nodes, and our final network size will be around 3,000 nodes (in about
|>three to four years). We will have about 1,500 nodes by the end of 1994.
 
|Subnetting?  Subnetting a class C network results in fewer usable addresses.
|What was the NIC suggesting, exactly?

Nothing short of expanding the name space will help here (class C networks
are limited to 254 hosts, aren't they?).

Maybe they ment "supernetting",  which as far as I know means combining
closely-numbers networks into a "super"-network, e.g. 132.64 and 132.65 (our
local class B networks) can be combined into one network by using a network
mask of ff.fe.0.0.

|When I asked the NIC about the availability of class B addresses, I was told
|I needed to predict far more than 1000's of nodes to get one.  They suggested
|I apply for additional class C addresses.  Maybe that's what they meant for
|"subnetting"?

Maybe that's a stage towards "suprnetting".  But you'll need very certain
numbers for it to work.

Cheers,

--Amos
--
--Amos Shapira (Jumper Extraordinaire) | "Of course Australia was marked for
C.S. System Group, Hebrew University,  |  glory, for its people had been chosen
Jerusalem 91904, ISRAEL                |  by the finest judges in England."
amoss@cs.huji.ac.il                    |                         -- Anonymous

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Nov 1993 15:22:49 GMT
From:      brownje@ncifcrf.gov (Janet E. Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: IP broadcast address getting reset

This actually may be OK; the process seems to be taking your network 
mask and converting it to the network address. I've seen a few processes 
that do this. Unless you are seeing errors, the packet should be going to 
the router/gateway with that address. 



-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Nov 1993 15:49:48 GMT
From:      RINDFUSS-S@medea.wz-berlin.de (Peter Rindfuss)
To:        comp.protocols.tcp-ip
Subject:   stty: TCGETS: Operation not supported on socket

When I rexec to SunOS 4.1.2 or HP-UX, I get error messages like

stty: TCGETS: Operation not supported on socket
ESC?7h  (Sun) or

stty: : Can't assign requested address  (HP) 

as the first part of the response. After that, output continues normally.
I understand that this comes from the fact that there is no controlling 
terminal when a remote command executes. On the Sun, the same happens with 
mailed output from batch commands, the reason being similar. Is there a way to 
suppress these messages? I need clean output from a rexec command.


-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 1993 17:11:22 GMT
From:      vijay@hicomb.hi.com (Vijay Kumar)
To:        comp.protocols.tcp-ip
Subject:   IP & TCP headers


I am intending to use the following bit positions in the IP and TCP 
headers for internal purposes. I was wondering if they are safe to use.
Please let me know if you feel it could do harm in one way or the other.

	Bits 6 & 7 of the TOS field of the IP header. They are
		marked UNUSED.

	The 'RESERVED' field in the TCP header. They follow the
		'HLEN' field. Supposedly they are reserved for future
		 use.

Vijay

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Nov 1993 17:22:56 GMT
From:      RINDFUSS-S@medea.wz-berlin.de (Peter Rindfuss)
To:        comp.protocols.tcp-ip
Subject:   rexec output incomplete

I use rexec to a Siemens MX-300 host with System V to obtain output from a 
certain command. Unfortunately, the last few lines of about 250 are always 
missing. Apparently, when rexec terminates, the host drops the connection 
immediately, but some buffer still contains unsent data. So far, I help myself 
by adding a command to the rexec line which simply spends some extra time. 
That works. But is there an official way to force network buffers to flush? 

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Nov 1993 17:28:15 GMT
From:      braun@novell.com (Karl Braun)
To:        comp.protocols.tcp-ip
Subject:   Re: Good books on TCP/IP for beginners

In article <1993Nov12.225908.22208@unislc.slc.unisys.com> thayne@unislc.slc.unisys.com (Thayne Forbes) writes:
>
>Further, the
>new book by Richard Stevens is titled TCP/IP Illustrated, Volume 1
>The Protocols.  As you might infer from the title, it is not about
>network programming, but rather a description of the protocols.

Do you know which protocols are covered?

Karl Tunnell-Braun   408/645-2031			braun@novell.com
Network Scapegoat in Training				Novell IS Lan Eng.
"That which does not kill us, makes use stronger" 		- Nietzche
"Embrace Tiger, Return to Mountain"

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Nov 1993 17:37:29 GMT
From:      praveen@deimos.aggregate.com (Praveen)
To:        comp.protocols.tcp-ip
Subject:   recvfrom signal re-entrant ?

 Does anybody know if recvfrom() and sendto() are signal re-entrant and 
restartable on SunOS 4.1.x and Solaris 2.x ?

-Praveen
praveen@aggregate.com


-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Nov 1993 17:50:11 GMT
From:      SPIRHONEN@FINABO.ABO.FI (Sami Pirhonen AT)
To:        comp.protocols.tcp-ip
Subject:   NetwareLite and TCP/IP



I have networked about 20 PC:s with Novell NetwareLite.
I have considered on that it uses IPX protocol.

Now I would like to add some more PCs but the new macines
are located at another site. There are a 64 kb modem line
and  Intergraph remoute routers  that uses TCP/IP protocol	
between sites (we use also unix systems in our network).
The routers can only pass TCP/IP protocol.

Is there any software or hardware available to translate
packets from TCP/lP to IPX and from IPX to TCP/IP at
DOS / Novell NetwareLite environment.

Thank you in advance

Sami Pirhonen



                                                     
                                    

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Nov 1993 18:31:03 GMT
From:      chandler@chatham.progress.com (Peter Chandler)
To:        comp.protocols.tcp-ip
Subject:   Socket Read Error 54

I am get an error on a socket read, return code -1, errno 54.

in errno.h:

#define ECONNRESET      54              /* Connection reset by peer */

Can anyone provide additional information on this error?
The cause?  Any type on recover/retries to complete the read?

Thanks Peter Chandler





-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 1993 18:38:10 GMT
From:      adiwan@bbn.com (Arif Diwan)
To:        comp.protocols.tcp-ip
Subject:   Re: IP broadcast address getting reset

In article <2bm33o$b4f@zippy.MathWorks.Com>, pascoe@MathWorks.Com (Dave Pascoe) writes:
 I'm having a strange problem on a SPARC-10 running SunOS 4.1.3 where
 the IP broadcast address is being reset by some process from all ones
 to all zeros. i.e., 144.212.255.255 is being changed to 144.212.0.0.
...

I do not know of a background process doing this, but running ifconfig
without specifying the broadcast address will set the broadcast zero in
the host part.

-- 

				-- Arif Diwan (adiwan@bbn.com)
						617/873-6274

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 93 20:00:25 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: V. Jacobson Article

Here's the posting and a later followup with a minor fix.  BTW, there's
a real example of Van's fast-retransmit-fast-recovery (English text and
timeline output) along with a graph showing what happens with the "cwnd"
window variable, in my new book "TCP/IP Illustrated" (Addison-Wesley,
1994) that'll be available in mid-December.  (Send me e-mail if you'd
like the table of contents.)

	Rich Stevens  (rstevens@noao.edu)

-------------------------------------------------------------------
From van@helios.ee.lbl.gov Mon Apr 30 01:44:05 1990
To: end2end-interest@ISI.EDU
Subject: modified TCP congestion avoidance algorithm
Date: Mon, 30 Apr 90 01:40:59 PDT
From: Van Jacobson <van@helios.ee.lbl.gov>
Status: RO

This is a description of the modified TCP congestion avoidance
algorithm that I promised at the teleconference.

BTW, on re-reading, I noticed there were several errors in
Lixia's note besides the problem I noted at the teleconference.
I don't know whether that's because I mis-communicated the
algorithm at dinner (as I recall, I'd had some wine) or because
she's convinced that TCP is ultimately irrelevant :).  Either
way, you will probably be disappointed if you experiment with
what's in that note.

First, I should point out once again that there are two
completely independent window adjustment algorithms running in
the sender:  Slow-start is run when the pipe is empty (i.e.,
when first starting or re-starting after a timeout).  Its goal
is to get the "ack clock" started so packets will be metered
into the network at a reasonable rate.  The other algorithm,
congestion avoidance, is run any time *but* when (re-)starting
and is responsible for estimating the (dynamically varying)
pipesize.  You will cause yourself, or me, no end of confusion
if you lump these separate algorithms (as Lixia's message did).

The modifications described here are only to the congestion
avoidance algorithm, not to slow-start, and they are intended to
apply to large bandwidth-delay product paths (though they don't
do any harm on other paths).  Remember that with regular TCP (or
with slow-start/c-a TCP), throughput really starts to go to hell
when the probability of packet loss is on the order of the
bandwidth-delay product.  E.g., you might expect a 1% packet
loss rate to translate into a 1% lower throughput but for, say,
a TCP connection with a 100 packet b-d p. (= window), it results
in a 50-75% throughput loss.  To make TCP effective on fat
pipes, it would be nice if throughput degraded only as function
of loss probability rather than as the product of the loss
probabilty and the b-d p.  (Assuming, of course, that we can do
this without sacrificing congestion avoidance.)

These mods do two things: (1) prevent the pipe from going empty
after a loss (if the pipe doesn't go empty, you won't have to
waste round-trip times re-filling it) and (2) correctly account
for the amount of data actually in the pipe (since that's what
congestion avoidance is supposed to be estimating and adapting to).

For (1), remember that we use a packet loss as a signal that the
pipe is overfull (congested) and that packet loss can be
detected one of two different ways:  (a) via a retransmit
timeout or (b) when some small number (3-4) of consecutive
duplicate acks has been received (the "fast retransmit"
algorithm).  In case (a), the pipe is guaranteed to be empty so
we must slow-start.  In case (b), if the duplicate ack
threshhold is small compared to the bandwidth-delay product, we
will detect the loss with the pipe almost full.  I.e., given a
threshhold of 3 packets and an LBL-MIT bandwidth-delay of around
24KB or 16 packets (assuming 1500 byte MTUs), the pipe is 75%
full when fast-retransmit detects a loss (actually, until
gateways start doing some sort of congestion control, the pipe
is overfull when the loss is detected so *at least* 75% of the
packets needed for ack clocking are in transit when
fast-retransmit happens).  Since the pipe is full, there's no
need to slow-start after a fast-retransmit.

For (2), consider what a duplicate ack means:  either the
network duplicated a packet (i.e., the NSFNet braindead IBM
token ring adapters) or the receiver got an out-of-order packet.
The usual cause of out-of-order packets at the receiver is a
missing packet.  I.e., if there are W packets in transit and one
is dropped, the receiver will get W-1 out-of-order and
(4.3-tahoe TCP will) generate W-1 duplicate acks.  If the
`consecutive duplicates' threshhold is set high enough, we can
reasonably assume that duplicate acks mean dropped packets.

But there's more information in the ack:  The receiver can only
generate one in response to a packet arrival.  I.e., a duplicate
ack means that a packet has left the network (it is now cached
at the receiver).  If the sender is limitted by the congestion
window, a packet can now be sent.  (The congestion window is a
count of how many packets will fit in the pipe.  The ack says a
packet has left the pipe so a new one can be added to take its
place.)  To put this another way, say the current congestion
window is C (i.e, C packets will fit in the pipe) and D
duplicate acks have been received.  Then only C-D packets are
actually in the pipe and the sender wants to use a window of C+D
packets to fill the pipe to its estimated capacity (C+D sent -
D received = C in pipe).

So, conceptually, the slow-start/cong.avoid/fast-rexmit changes
are:

  - The sender's input routine is changed to set `cwnd' to `ssthresh'
    when the dup ack threshhold is reached.  [It used to set cwnd to
    mss to force a slow-start.]  Everything else stays the same.

  - The sender's output routine is changed to use an effective window
    of min(snd_wnd, cwnd + dupacks*mss)  [the change is the addition
    of the `dupacks*mss' term.]  `Dupacks' is zero until the rexmit
    threshhold is reached and zero except when receiving a sequence
    of duplicate acks.

The actual implementation is slightly different than the above
because I wanted to avoid the multiply in the output routine
(multiplies are expensive on some risc machines).  A diff of the
old and new fastrexmit code is attached (your line numbers will
vary).

Note that we still do congestion avoidance (i.e., the window is
reduced by 50% when we detect the packet loss).  But, as long as
the receiver's offered window is large enough (it needs to be at
most twice the bandwidth-delay product), we continue sending
packets (at exactly half the rate we were sending before the
loss) even after the loss is detected so the pipe stays full at
exactly the level we want and a slow-start isn't necessary.

Some algebra might make this last clear:  Say U is the sequence
number of the first un-acked packet and we are using a window
size of W when packet U is dropped.  Packets [U..U+W) are in
transit.  When the loss is detected, we send packet U and pull
the window back to W/2.  But in the round-trip time it takes
the U retransmit to fill the receiver's hole and an ack to get
back, W-1 dup acks will arrive (one for each packet in transit).
The window is effectively inflated by one packet for each of
these acks so packets [U..U+W/2+W-1) are sent.  But we don't
re-send packets unless we know they've been lost so the amount
actually sent between the loss detection and the recovery ack is
U+W/2+W-1 - U+W = W/2-1 which is exactly the amount congestion
avoidance allows us to send (if we add in the rexmit of U).  The
recovery ack is for packet U+W so when the effective window is
pulled back from W/2+W-1 to W/2 (which happens because the
recovery ack is `new' and sets dupack to zero), we are allowed
to send up to packet U+W+W/2 which is exactly the first packet
we haven't yet sent.  (I.e., there is no sudden burst of packets
as the `hole' is filled.)  Also, when sending packets between
the loss detection and the recovery ack, we do nothing for the
first W/2 dup acks (because they only allow us to send packets
we've already sent) and the bottleneck gateway is given W/2
packet times to clean out its backlog.  Thus when we start
sending our W/2-1 new packets, the bottleneck queue is as empty
as it can be.

[I don't know if you can get the flavor of what happens from
this description -- it's hard to see without a picture.  But I
was delighted by how beautifully it worked -- it was like
watching the innards of an engine when all the separate motions
of crank, pistons and valves suddenly fit together and
everything appears in exactly the right place at just the right
time.]

Also note that this algorithm interoperates with old tcp's:  Most
pre-tahoe tcp's don't generate the dup acks on out-of-order packets.
If we don't get the dup acks, fast retransmit never fires and the
window is never inflated so everything happens in the old way (via
timeouts).  Everything works just as it did without the new algorithm
(and just as slow).

If you want to simulate this, the intended environment is:

    - large bandwidth-delay product (say 20 or more packets)

    - receiver advertising window of two b-d p (or, equivalently,
      advertised window of the unloaded b-d p but two or more
      connections simultaneously sharing the path).

    - average loss rate (from congestion or other source) less than
      one lost packet per round-trip-time per active connection.
      (The algorithm works at higher loss rate but the TCP selective
      ack option has to be implemented otherwise the pipe will go empty
      waiting to fill the second hole and throughput will once again
      degrade at the product of the loss rate and b-d p.  With selective
      ack, throughput is insensitive to b-d p at any loss rate.)

And, of course, we should always remember that good engineering
practise suggests a b-d p worth of buffer at each bottleneck --
less buffer and your simulation will exhibit the interesting
pathologies of a poorly engineered network but will probably
tell you little about the workings of the algorithm (unless the
algorithm misbehaves badly under these conditions but my
simulations and measurements say that it doesn't).  In these
days of $100/megabyte memory, I dearly hope that this particular
example of bad engineering is of historical interest only.

 - Van

-----------------
*** /tmp/,RCSt1a26717	Mon Apr 30 01:35:17 1990
--- tcp_input.c	Mon Apr 30 01:33:30 1990
***************
*** 834,850 ****
  				 * Kludge snd_nxt & the congestion
  				 * window so we send only this one
! 				 * packet.  If this packet fills the
! 				 * only hole in the receiver's seq.
! 				 * space, the next real ack will fully
! 				 * open our window.  This means we
! 				 * have to do the usual slow-start to
! 				 * not overwhelm an intermediate gateway
! 				 * with a burst of packets.  Leave
! 				 * here with the congestion window set
! 				 * to allow 2 packets on the next real
! 				 * ack and the exp-to-linear thresh
! 				 * set for half the current window
! 				 * size (since we know we're losing at
! 				 * the current window size).
  				 */
  				if (tp->t_timer[TCPT_REXMT] == 0 ||
--- 834,850 ----
  				 * Kludge snd_nxt & the congestion
  				 * window so we send only this one
! 				 * packet.
! 				 *
! 				 * We know we're losing at the current
! 				 * window size so do congestion avoidance
! 				 * (set ssthresh to half the current window
! 				 * and pull our congestion window back to
! 				 * the new ssthresh).
! 				 *
! 				 * Dup acks mean that packets have left the
! 				 * network (they're now cached at the receiver) 
! 				 * so bump cwnd by the amount in the receiver
! 				 * to keep a constant cwnd packets in the
! 				 * network.
  				 */
  				if (tp->t_timer[TCPT_REXMT] == 0 ||
***************
*** 853,864 ****
  				else if (++tp->t_dupacks == tcprexmtthresh) {
  					tcp_seq onxt = tp->snd_nxt;
! 					u_int win =
! 					    MIN(tp->snd_wnd, tp->snd_cwnd) / 2 /
! 						tp->t_maxseg;
  
  					if (win < 2)
  						win = 2;
  					tp->snd_ssthresh = win * tp->t_maxseg;
- 
  					tp->t_timer[TCPT_REXMT] = 0;
  					tp->t_rtt = 0;
--- 853,864 ----
  				else if (++tp->t_dupacks == tcprexmtthresh) {
  					tcp_seq onxt = tp->snd_nxt;
! 					u_int win = MIN(tp->snd_wnd,
! 							tp->snd_cwnd);
  
+ 					win /= tp->t_maxseg;
+ 					win >>= 1;
  					if (win < 2)
  						win = 2;
  					tp->snd_ssthresh = win * tp->t_maxseg;
  					tp->t_timer[TCPT_REXMT] = 0;
  					tp->t_rtt = 0;
***************
*** 866,873 ****
  					tp->snd_cwnd = tp->t_maxseg;
  					(void) tcp_output(tp);
! 
  					if (SEQ_GT(onxt, tp->snd_nxt))
  						tp->snd_nxt = onxt;
  					goto drop;
  				}
  			} else
--- 866,879 ----
  					tp->snd_cwnd = tp->t_maxseg;
  					(void) tcp_output(tp);
! 					tp->snd_cwnd = tp->snd_ssthresh +
! 						       tp->t_maxseg *
! 						       tp->t_dupacks;
  					if (SEQ_GT(onxt, tp->snd_nxt))
  						tp->snd_nxt = onxt;
  					goto drop;
+ 				} else if (tp->t_dupacks > tcprexmtthresh) {
+ 					tp->snd_cwnd += tp->t_maxseg;
+ 					(void) tcp_output(tp);
+ 					goto drop;
  				}
  			} else
***************
*** 874,877 ****
--- 880,890 ----
  				tp->t_dupacks = 0;
  			break;
+ 		}
+ 		if (tp->t_dupacks) {
+ 			/*
+ 			 * the congestion window was inflated to account for
+ 			 * the other side's cached packets - retract it.
+ 			 */
+ 			tp->snd_cwnd = tp->snd_ssthresh;
  		}
  		tp->t_dupacks = 0;
*** /tmp/,RCSt1a26725	Mon Apr 30 01:35:23 1990
--- tcp_timer.c	Mon Apr 30 00:36:29 1990
***************
*** 223,226 ****
--- 223,227 ----
  		tp->snd_cwnd = tp->t_maxseg;
  		tp->snd_ssthresh = win * tp->t_maxseg;
+ 		tp->t_dupacks = 0;
  		}
  		(void) tcp_output(tp);

From van@helios.ee.lbl.gov Mon Apr 30 10:37:36 1990
To: end2end-interest@ISI.EDU
Subject: modified TCP congestion avoidance algorithm (correction)
Date: Mon, 30 Apr 90 10:36:12 PDT
From: Van Jacobson <van@helios.ee.lbl.gov>
Status: RO

I shouldn't make last minute 'fixes'.  The code I sent out last
night had a small error:

*** t.c	Mon Apr 30 10:28:52 1990
--- tcp_input.c	Mon Apr 30 10:30:41 1990
***************
*** 885,893 ****
  			 * the congestion window was inflated to account for
  			 * the other side's cached packets - retract it.
  			 */
! 			tp->snd_cwnd = tp->snd_ssthresh;
  		}
- 		tp->t_dupacks = 0;
  		if (SEQ_GT(ti->ti_ack, tp->snd_max)) {
  			tcpstat.tcps_rcvacktoomuch++;
  			goto dropafterack;
--- 885,894 ----
  			 * the congestion window was inflated to account for
  			 * the other side's cached packets - retract it.
  			 */
! 			if (tp->snd_cwnd > tp->snd_ssthresh)
! 				tp->snd_cwnd = tp->snd_ssthresh;
! 			tp->t_dupacks = 0;
  		}
  		if (SEQ_GT(ti->ti_ack, tp->snd_max)) {
  			tcpstat.tcps_rcvacktoomuch++;
  			goto dropafterack;

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Nov 1993 09:43:26 -0800
From:      frank@calcom.socal.com (Frank Keeney)
To:        comp.protocols.tcp-ip
Subject:   HELP! SLIP and LANtastic v5.0 AI

On Nov 12 17:12, Baine Werny wrote:

 > Can someone give me an arbitrary list of software that would 
 > work here?

I can help ypu with the Lantastic side of this problem. To route the packets
I've heard that Pcroute or KA9Q will work.

Here is my setup:


Config.sys;

DEVICE=C:\QEMM\QEMM386.SYS R:2 IA RAM ROM DBF=2 ST:M NOSH
INSTALL=C:\QEMM\LOADHI.COM /TSR /R:2 C:\BIN\HYPER386.EXE HS OB:32 OR T:3 V
XB:1 C:1024
DEVICE=C:\QEMM\LOADHI.SYS /R:1 C:\BIN\MOUSE501.SYS
SHELL=C:\DOS\COMMAND.COM C:\DOS\ /E:512 /p
INSTALL=C:\QEMM\LOADHI.COM /TSR /R:2 C:\DOS\SHARE.EXE
FILES=35
BUFFERS=1
LASTDRIVE=Z
FCBS=16,8
STACKS=0,0
DEVICE=C:\QEMM\LOADHI.SYS /R:2 C:\STACKER\STACKER.COM /M0 /EMS C:\STACVOL.DSK
DEVICE=C:\STACKER\SSWAP.COM C:\STACVOL.DSK /SYNC
DEVICE=C:\QEMM\LOADHI.SYS /R:1 C:\LANTASTI\PROTMAN.DOS /I:C:\LANTASTI
DEVICE=C:\QEMM\LOADHI.SYS /R:1 C:\LANTASTI\AEXNDIS.DOS
DEVICE=C:\QEMM\LOADHI.SYS /R:1 C:\LANTASTI\DIS_PKT9.DOS


Autoexec.bat;

@ECHO OFF
C:\QEMM\LOADHI /R:1 C:\QEMM\BUFFERS=7
PATH=C:\WAFFLE\BIN;C:\BINK;C:\QEMM;C:\DOS;C:\LANTASTI;C:\BIN
set configtel=c:\tcp\config.tel
prompt $e[1;31m$p$e[34m$g$e[33m
CD \LANTASTI
C:\QEMM\LOADHI /R:2 AI-NDIS BIND_TO=AEXNDIS_NIF
C:\QEMM\LOADHI /R:2 AILANBIO
C:\QEMM\LOADHI /R:2 REDIR FRANK LOGINS=3
CD \
C:\D\NET\ANET.COM LOGIN FRANK FRANK
SET TZ=PST8PDT
SET NAME=Frank Keeney
SET PMUSER=FRANK
SET WAFFLE=C:\WAFFLE\SYSTEM\STATIC
SET LAN_DIR=C:\LANTASTI.NET
SET LAN_CFG=C:\LANTASTI
SET BINKLEY=C:\BINK
SET LIST=C:\TEMP
SET COMMO=D:\COMMO
SET DSZLOG=D:\COMMO\COMMO.LOG
SET DSZPORT=1
SET DSZOPT=rZ
rem SET CCLPATH=D:\CCPLUS
C:\QEMM\LOADHI /R:2 PKTMUX 4
CD \DVX
DVX
PROMPT=$P$G



Protocol.ini;

[PROTMAN]
  DRIVERNAME = PROTMAN$
  DYNAMIC = YES
 
[AEXNDIS_NIF]
  IOBASE = 0x300
  INTERRUPT = 15
  DRIVERNAME = AEXNDS$

[PKTDRV]
  DRIVERNAME = PKTDRV$
  BINDINGS = AEXNDIS_NIF
  INTVEC = 0x60

  Frank

 * Origin: yume no naka ni... (1:102/645)

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Nov 1993 09:45:54 -0800
From:      frank@calcom.socal.com (Frank Keeney)
To:        comp.protocols.tcp-ip
Subject:   Multiple Telnet Sessions into a Desqview machine?

Is there any way to allow multiple Telnet sessions into a Desqview or
Desqview/X machine? I'd like to allow multiple users to access a character
based application from anywhere on our net. Any ideas?

  Frank

 * Origin: yume no naka ni... (1:102/645)

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 1993 21:02:48 GMT
From:      tim.drury@gtri.gatech.edu (Tim Drury)
To:        comp.protocols.tcp-ip
Subject:   PCNFS programming, O_NONBLOCK not working


I'm trying to use the PCNFS programmers toolkit ver 2.0 with PCNFS ver 5.0
in asynchronous mode.  I set O_NONBLOCK in my call to t_open() but t_listen()
and t_rcv() still hang the PC when called.  Shouldn't they immediately return
with some sort of TNODATA error or something?  

I noticed that the example in the manual says they are doing event-driven,
asynchronous programming, but they do not set O_NONBLOCK in t_open().  What
is going on?

Any help would greatly be appreciated.

-tim


-tim drury
tim.drury@gtri.gatech.edu
georgia tech research institute


-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 1993 02:21:49 GMT
From:      lam@mrcnext.cso.uiuc.edu (Ken Lam)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   Re: Problems running Novell, PC-NFS, Windows, eXcursion

mferrare@physics.adelaide.edu.au (Mark Ferraretto) writes:

>Has anyone tried this?
>
>Dos V5.0 or V6.0
>Novell Netware 3.11
>PC-NFS 4.0
>eXcursion (X Window for PC software)
>Windows?
>
>By the time I have all the TSRs loaded I have 365K free under Dos 6 and about
>300K free in Dos 5.  This is not a lot.  this setup is also a picture of
>instability.  When it does work and I can get into windows, i have more
>problems.  PC-NFS installs its own net drivers which means I can't talk to
>my novell print queues or run CC:mail and I get a whole lot of GPFs.
>eXcursion GPFs sporadically.  When it does work it is slloooowww.

I don't know about pcnfs4, but with v5, you can run over ODI drivers.  Doing
this allows Netware connectivity, (ODI is easier to load hi also) and tcp/ip.
(NOTE: I dislike PCNFS, it's a b*tch to work with)

I belive, that you can get somewheres over 500k free.  (But I never spent
much time optimizing that config)

Best of luck..

Ken

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Nov 1993 04:50:10 GMT
From:      eel@auspost.com.au (Elena Leong)
To:        rec.games.hack,comp.protocols.tcp-ip
Subject:   Uh oh...

Fellow addicts, I spent an hour today trying to figure out why my very 
simple gated configuration wasnt working - only to discover this in my
configuration file.  ...... (I dont know what was on my mind when I typed
it all in.)

If you cant figure out immediately which word doesnt belong in this file,
then you, too, may have a problem. ;-)


Elena Leong
System Administrator
EDIPost Australia Post.

----- CUT HERE --------

options noresolv;
interfaces
{
        define 192.189.54.29 pointopoint 192.245.13.1 nethack 255.255.255.240;
};

rip yes {
        broadcast;
};
 

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 93 12:42:07 CST
From:      allebrandi@inland.com (Tom Allebrandi)
To:        comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Exceeding a Class C network capacity

In article <AMOSS.93Nov15150319@picton.cs.huji.ac.il>, amoss@picton.cs.huji.ac.il (Amos Shapira) writes:
> Maybe they ment "supernetting",  which as far as I know means combining
> closely-numbers networks into a "super"-network, e.g. 132.64 and 132.65 (our
> local class B networks) can be combined into one network by using a network
> mask of ff.fe.0.0.
> 
> |When I asked the NIC about the availability of class B addresses, I was told
> |I needed to predict far more than 1000's of nodes to get one.  They suggested
> |I apply for additional class C addresses.  Maybe that's what they meant for
> |"subnetting"?
> 
> Maybe that's a stage towards "suprnetting".  But you'll need very certain
> numbers for it to work.
> 

You'll also need the right software. The IP implementations from Sun
and Silicon Graphics don't understand this. (Or at least they didn't
when we tried it in early '92.) At that time I was told that in theory
this would work but it was not the intent of the architects and that in
particular most Berkeley derivations would not work.

--- Tom
Tom Allebrandi
Inland Steel Research Labs
Allebrandi@Research.Inland.Com

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Nov 1993 08:02:05 GMT
From:      arinell@elixir.e.kth.se (Fredrik Arinell)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: TELNET control

In article <2c9mu3$kia@daisy.cc.utexas.edu> devil@daisy.cc.utexas.edu (Khurram Qureshi) writes:

>  If you telnet to a server port from a client machine, 
>  how do you get the server to execute one of its files?
>  and send its i/o to the user's terminal?
>   For example, there is a file called 'action' on the 
>  server hermes. The server is listening for connections
>  to port 6500. The remote user telnet's to hermes port 
>  6500. How does the server go about executing 'action'
>  once the telnet connection is established? and displaying
>  any i/o required in the remote user's terminal?
>   Thanks,
>  Khurram Qureshi.

<nickel@cs.tu-berlin.de> har written a package called socket-1.1 that
does what you wanna do. Send him a mail asking him where to get it -
or use archie.

I'm looking for an extension of the same thing that can handle
re-establishment of a lost connection, but never mind that,

/Fred


-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Nov 1993 08:37:02 GMT
From:      koepke@gmd.de (Franz Koepke)
To:        comp.protocols.tcp-ip
Subject:   Re: NetwareLite and TCP/IP

In article <1993Nov15.175011.11589@abo.fi> SPIRHONEN@FINABO.ABO.FI (Sami Pirhonen AT) writes:
>From: SPIRHONEN@FINABO.ABO.FI (Sami Pirhonen AT)
>Subject: NetwareLite and TCP/IP
>Date: Mon, 15 Nov 1993 17:50:11 GMT



>I have networked about 20 PC:s with Novell NetwareLite.
>I have considered on that it uses IPX protocol.
 
>Now I would like to add some more PCs but the new macines
>are located at another site. There are a 64 kb modem line
>and  Intergraph remoute routers  that uses TCP/IP protocol      
>between sites (we use also unix systems in our network).
>The routers can only pass TCP/IP protocol.
 
>Is there any software or hardware available to translate
>packets from TCP/lP to IPX and from IPX to TCP/IP at
>DOS / Novell NetwareLite environment.

We have used Novell's LWP for Dos for this purpose, it contains an
IPTUNNEL. Instead of binding IPX to the Ethernet Card, IPX is bound
to IPTUNNEL which uses TCPIP (also contained in LWP) and that runs
on ODI Card Driver!
That sound complicated, but it works fine.

Franz Koepke

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Nov 1993 12:00:41 GMT
From:      leo@elmail.co.uk (E.J.Leoni-Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: <<< TCP-IP Server example source needed >>>

In article <1993Nov12.001003.17186@news.unr.edu> demay@pyramid.unr.edu (Mark DeMay) writes:
>
>
>Howdy,
>
>    I am writing TCP/IP for an embedded system with EtherNET. Between all 
>the Public Domain stuff and the Comer/Stevens books, I think I'll
>be able to complete the IP, ICMP, and TCP. 
>
>BUT, I am having difficulty finding anything to use as a template or
>example of Application level SERVER software, e.g. the daemon for
>internet services like RSH, RLOGIN, and FTP.
>
1/. Try the BSD code.

2/. Some of the POP daemons that run under inetd are very sensible
places to start. (Some are total abortions :-))

Oh - I just realised you are reinventing inetd yourself. Well then the
POP stuff is still relevant but you will need to look for code that allows
you to run them standalone.

Chief problems I have seen with this stuff is incorrect handling of signals
and bad error-handling (i.e. what happens if client 'dies')



-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 1993 13:36:03 GMT
From:      jfjr@mbunix.mitre.org (Freedman)
To:        comp.protocols.tcp-ip
Subject:   pseudo-drivers and IP


   I am trying to install a pseudo-driver in a Sun IPX running 4.1.3. 
This driver implements a protocol (swipe) which is a sort of IP tunneled
through IP. I am not a wizard by any means but I have had the standard
internals course(s) and I understand about the cdevsw, major and minor
devices (this is apparently character device) BTW I have the code but 
next to no documentation, Anyway this also interacts with IP and the 
protosw in manners which I don't quite understand. For instance there
are two ioctl routines, one is the standard type which gets put in the
cdevsw, the other is a sort of interface ioctl and takes a pointer as the
first argument.

 I got the character device part to work okay - ifconfig sees it and it
responds but I can't get the interaction between the device and IP to happen
correctly. I realize that this is vague stuff but if anybody can give me
any help concerning the interaction between pseudo-devices and the IP stack
I would appreciate it.

                            Jerry Freedman,Jr

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Nov 1993 14:08:54 GMT
From:      tim.shaw@ndm.ox.ac.uk (Tim Shaw)
To:        comp.protocols.tcp-ip
Subject:   Quote of the day protocol

Does anyone have any information about how to implement the quote of the day 
protocol ?

I've read RFC 865 but there isn't very much there.  I'm hoping someone can 
point me to some other sources of information

Tim Shaw

email tim.shaw@ndm.ox.ac.uk

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 1993 17:05:04 GMT
From:      gthaker@atl.ge.com (Gautam H. Thaker)
To:        comp.protocols.tcp-ip
Subject:   Can UDP with with only one way link between 2 machines?


We wish to connect two computer that are several thousand miles 
apart via a oneway satellite connection. We wish to transmit data
from machine A->B via UDP datagrams. We can't send any bytes back
from B to A. We can live with unreliability etc. 

Please excuse this novice questions. can IP/UDP work under
these conditions?

Any hints or pointers welcome.

--
Gautam H. Thaker (gthaker@atl.ge.com) 609-866-6412 (fax x6397. Dialcom 8-777)
Martin Adv. Tech. Lab., MS 145-2; Route 38; Moorestown, NJ 08057. 767-4396 (H)

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Nov 93 19:30:54 GMT
From:      dap@hammer.network.com (Dave Peterson)
To:        comp.protocols.tcp-ip
Subject:   Re: pseudo-drivers and IP

In article fsp@linus.mitre.org, jfjr@mbunix.mitre.org (Freedman) writes:
>
>   I am trying to install a pseudo-driver in a Sun IPX running 4.1.3. 
>This driver implements a protocol (swipe) which is a sort of IP tunneled
>through IP. I am not a wizard by any means but I have had the standard
>internals course(s) and I understand about the cdevsw, major and minor
>devices (this is apparently character device) BTW I have the code but 
>next to no documentation, Anyway this also interacts with IP and the 
>protosw in manners which I don't quite understand. For instance there
>are two ioctl routines, one is the standard type which gets put in the
>cdevsw, the other is a sort of interface ioctl and takes a pointer as the
>first argument.
>
> I got the character device part to work okay - ifconfig sees it and it
>responds but I can't get the interaction between the device and IP to happen
>correctly. I realize that this is vague stuff but if anybody can give me
>any help concerning the interaction between pseudo-devices and the IP stack
>I would appreciate it.
>
>                            Jerry Freedman,Jr

What type of interaction are you interested in ?? Can you be more
specific about what is not working ??

---
===================================================================
Dave Peterson           phone : 612-493-1008
Senior Engineer 
Network Systems Corp.	email: dap@network.com
===================================================================


-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Nov 1993 22:01:46 GMT
From:      msells@undergrad.math.uwaterloo.ca (Marty Sells)
To:        comp.protocols.tcp-ip,comp.lang.ada
Subject:   Wanted: TCP/IP in ADA (code & advice)

I got the packages DDN and DDN2 from the Simtel Ada Software 
Repository. Does anybody know of any other TCP and or IP 
implementations in ADA? I'm quite impressed with DDN2 and will
attempt to contact the autor by e-mail but I am also interested in
net-opinion.

Does anybody know how to contact the NTIS (National Technical
Information Service) who are supposed to have full documentation
(with figures) for DDN2 or where I can get full documentation for
DDN2. The header information in DDN2 is unclear as to the status (PD,
copyright, ?) of DDN2. Anybody know? Also I expect that there is
a newer version. Where?

e-mail replies prefered.

Marty

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Nov 1993 22:42:02 +0000
From:      tim@winwiz.demon.co.uk (Tim Carmichael)
To:        comp.protocols.tcp-ip
Subject:   IBM Token Ring promiscuous driver


-- 
--------------------------
Tim Carmichael
Communic8 Software Europe
+44 81 878 0066
--------------------------

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 1993 00:19:54 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Supernetting (Was: Re: Exceeding a Class C network capacity)


In article <1993Nov16.124207.4022@inland.com>, allebrandi@inland.com 
(Tom Allebrandi) writes:
|In article <AMOSS.93Nov15150319@picton.cs.huji.ac.il>, 
 amoss@picton.cs.huji.ac.il (Amos Shapira) writes:
|> Maybe they ment "supernetting",  which as far as I know means combining
|> closely-numbers networks into a "super"-network, e.g. 132.64 and 132.65 (our
|> local class B networks) can be combined into one network by using a network
|> mask of ff.fe.0.0.
|> 
|> |When I asked the NIC about the availability of class B addresses, I was told
|> |I needed to predict far more than 1000's of nodes to get one.  They suggested
|> |I apply for additional class C addresses.  Maybe that's what they meant for
|> |"subnetting"?
|> 
|> Maybe that's a stage towards "suprnetting".  But you'll need very certain
|> numbers for it to work.
|> 
|
|You'll also need the right software. The IP implementations from Sun
|and Silicon Graphics don't understand this. (Or at least they didn't
|when we tried it in early '92.) At that time I was told that in theory
|this would work but it was not the intent of the architects and that in
|particular most Berkeley derivations would not work.

It was my impression that there is no intention to make supernetting
work on end systems, but rather that it was only designed to allow 
for aggregation of routing information between intermediate systems,
so as to forestall memory exhaustion on the backbone routers.

If anyone *does* know of a plan to allow for supernetting on end
systems - i.e. where 2^n contiguous class C networks can be
handled as a single network by host software - I'd like to hear
about it.  The "Supernetting" RFC (1338) does *not* address host
routing issues; it only takes the provider-centric (network 
assignment and route aggregation) perspective.

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Nov 1993 00:42:40 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: Quote of the day protocol

tim.shaw@ndm.ox.ac.uk (Tim Shaw) writes:
+---------------
| Does anyone have any information about how to implement the quote of the day 
| protocol ?
| 
| I've read RFC 865 but there isn't very much there.  I'm hoping someone can 
| point me to some other sources of information
+---------------

What else do you need? RFC 865 is quite complete. Your server just sits
there listening for connections (if TCP) or packets (if UDP), and replies
with a quote. That's it!


-Rob

p.s. If it's coding examples you want, look inside inetd.c (from any
recent BSD release) at routines echo_stream() & echo_dg() [each of which
are 3 or 4 lines of code] which implement the RFC 862 Echo Protocol,
which is almost identical to RFC 865 Quote of the Day Protocol, and
instead of echoing insert your favorite quote.

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		Phone: 415-390-1673
2011 N. Shoreline Blvd.		FAX:   415-967-8496
Mountain View, CA  94043


-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Nov 1993 00:43:11 GMT
From:      thayne@unislc.slc.unisys.com (Thayne Forbes)
To:        comp.protocols.tcp-ip
Subject:   Re: Can UDP with with only one way link between 2 machines?

Gautam H. Thaker (gthaker@atl.ge.com) wrote:

: We wish to connect two computer that are several thousand miles 
: apart via a oneway satellite connection. We wish to transmit data
: from machine A->B via UDP datagrams. We can't send any bytes back
: from B to A. We can live with unreliability etc. 
 
: Please excuse this novice questions. can IP/UDP work under
: these conditions?

If I understand your situation correctly, what you are trying to
do is a fairly trivial hack.  Take a look at Chapter 6 (I think)
of Unix Network Programming.  I has an example of what you need,
and you can probably just drop the information you need to
write into the code that is there.  Also, you could probably 
lift some good code from time or ping, but those both have a few
specific issues that you wouldn't be interested in.

-- 
Thayne Forbes         thayne@unislc.slc.unisys.com
Unisys Unix Support Engineering,    Salt Lake City.
Phone: (801) 594-4448          Fax: (801) 594-3827

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Nov 93 00:56:05 GMT
From:      irishjd@nscultrix2.network.com (john d. irish)
To:        comp.protocols.tcp-ip
Subject:   Source for berkeley TCP/IP code?

Does anyone know where I can find a current source for
a Berkeley TCP/IP implementation?

E-mail response prefered.  Thanks!



-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 1993 15:03:57 -0800
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: Unix boxes with multiple ethernet cards

In article <CGnL9M.A1C@cbfsb.cb.att.com> mvm@cbnewsb.cb.att.com (michael.v.murphy) writes:
>
>    I have a situation where I am planning to connect two seperate TCP-IP 
>based nets to one Sun SPARC. I will have an ethernet card for each net 
>termination. Is it possible to pass data through the Sun from one net
>to the other without writing custom code? 
  
  Repost which revision of which Sun operating system you are using for
  getting specific settings....

  e.g. on a SVR4 system, turn on routed and set IPFORWARDING=1 in the
  kernel, but your tcp/ip SAG from Sun should give you the details for
  your operating system.  On the unixen I'm familiar with, you then
  set the Sun as the default gateway for the other machines on both
  nets. 

>Is there any references that deal with machines
>with multiple network terminations (multiple ethernet cards) ?

RFC 1122 notes the pleasures of multi-homed hosts.  

The safest answer is don't use the same network in your internet
address for the two nets.


-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Nov 1993 02:54:16 GMT
From:      acc00jpb@unccvm.uncc.edu
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,alt.winsock
Subject:   VxDTCP


I'am looking for a vxdtcp winsock v1.1 complient stack 
I understand that their is one called vxdtcp by Jagane 
D Sundar if any one knows where the code is located.
I would appricate the info and if anyone knows how to
reach Jagane D. Sundar I would appricate that also.

Thanks

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 1993 13:58:44 GMT
From:      jal@acc.flint.umich.edu (John Lauro)
To:        comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Exceeding a Class C network capacity

In article <1993Nov16.124207.4022@inland.com> allebrandi@inland.com (Tom Allebrandi) writes:
>In article <AMOSS.93Nov15150319@picton.cs.huji.ac.il>, amoss@picton.cs.huji.ac.il (Amos Shapira) writes:
>> Maybe they ment "supernetting",  which as far as I know means combining
>> closely-numbers networks into a "super"-network, e.g. 132.64 and 132.65 (our
>> local class B networks) can be combined into one network by using a network
>> mask of ff.fe.0.0.
>> 
>> |When I asked the NIC about the availability of class B addresses, I was told
>> |I needed to predict far more than 1000's of nodes to get one.  They suggested
>> |I apply for additional class C addresses.  Maybe that's what they meant for
>> |"subnetting"?
>> 
>> Maybe that's a stage towards "suprnetting".  But you'll need very certain
>> numbers for it to work.
>> 
>
>You'll also need the right software. The IP implementations from Sun
>and Silicon Graphics don't understand this. (Or at least they didn't
>when we tried it in early '92.) At that time I was told that in theory
>this would work but it was not the intent of the architects and that in
>particular most Berkeley derivations would not work.

You can get it to work with almost any software, but it might cause
all packets from one class C to another to bounce off the router even
if they are on the same physical wire...  Should be fine if it's only
occational...  I suggest getting a router and have each port on the
router be a different class C network.  It may mean more class C networks
then not using a router but that will be easier then getting a class B.

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Nov 93 14:32:59 GMT
From:      g552536@kirk.lasc.lockheed.com ()
To:        comp.client-server,comp.protocols.tcp-ip
Subject:   Help! Non-interactive file transfer

I am interested in non-interactive file transfer of large amounts
of data. I've begun reading rfc's for BFTP, TFTP, & SFTP and was 
wondering if there is a standard for non-interactive file transfer
or a library interface to third party ftp packages as mentioned
in rfc1068.

My goal is file transfer initiated automaticaly from a controlling
remote program. What is the best approach.

Thanks in advance.

Trey Jarnaging552536@lasc.lockheed.com
Lockheed Aeronautical Systems Company
86 South Cobb Drive 
Marietta, GA 30063
g552536@kirk.lasc.lockheed.com
(404) 793-0612

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Nov 1993 15:21:33 GMT
From:      simonp@fulcrum.co.uk (Simon Parsons)
To:        comp.protocols.tcp-ip
Subject:   bootp client end code


Has anyone got an example of some client end 'bootp' code. I
eventually wish to run bootp on a pSOS embedded system.

Thanks in advance
Simon
--
===========================================================================
Simon Parsons                                        (simonp@fulcrum.co.uk)
"Nervous energy makes him tick, he's a health fanatic - MAKES YOU SICK!"
                                                         John Cooper-Clarke
===========================================================================
Fujitsu Fulcrum Telecommunications Ltd., Fordrough Lane, Birmingham,
                                                           B9 5FL, ENGLAND.

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Nov 1993 16:46:15 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.dcom.lans.fddi,comp.protocols.tcp-ip
Subject:   Re: FDDI and Ethernet

>PS, (another can of worms) surely the various 100Mb/s ethernet squabble
>    groups are going to use the FDDI MTU?!?

Surely they will use a more sensible MTU size like the 9180 octets 
chosen for IP over ATM and SMDS. :-)

Ran
atkinson@itd.nrl.navy.mil




-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Nov 1993 16:59:46 GMT
From:      hhimes@ria.com
To:        comp.protocols.tcp-ip
Subject:   Re: NEED: PC X-server recommendation...


In article <2c0quc$de6@sixgun.East.Sun.COM>, <jbrady@deepriver.East.Sun.COM> 
writes:
> Path: 
csn!att!att-out!pacbell.com!decwrl!decwrl!koriel!newscast.West.Sun.COM!seven-up
East.Sun.COM!sixgun.East.Sun.COM!deepriver!jbrady
> From: jbrady@deepriver.East.Sun.COM (John Brady - SunNetworks Consultant)
> Newsgroups: comp.protocols.tcp-ip
> Subject: NEED: PC X-server recommendation...
> Date: 12 Nov 1993 20:16:12 GMT
> Organization: Sun Microsystems, Inc.
> Lines: 14
> Distribution: world
> Message-ID: <2c0quc$de6@sixgun.East.Sun.COM>
> Reply-To: jbrady@deepriver.East.Sun.COM

Hummingbird has a good product and I have heard that XVision is good.  I just 
got XVision and I'm not that impressed so far. 
> NNTP-Posting-Host: deepriver.east.sun.com
> 
> 
> What is the consensus choice for the best DOS/Windows PC X-server product?
> 
> Also any rules of thumb concerning processor, memory and storage needs 
 associated
> with adding an X-server to a PC.
> 
> TIA.  E-mail prefered, will summarize.
> 
> John Brady
> Network Management Consultant
> SunNetworks, A Sun Microsystems, Inc. Business
> (703) 204-4859
> john.brady@East.Sun.Com
> 


-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 1993 17:00:44 GMT
From:      yanamand@eemips.tamu.edu (Radhe S Yanamandra)
To:        comp.protocols.tcp-ip
Subject:   FAQ on TCP-IP

Hello Guys,
           My name is Radhe Yanamandra. I am new to this group. Is their a
FAQ on tcp-ip?. If their is one I request you to please send to following
email address.

My email address: yanamand@eemips.tamu.edu

Thanking You
-- 
/***********************************************************************

 RADHE YANAMANDRA
 EE TAMU

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Nov 93 17:34:28 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.dcom.lans.fddi,comp.protocols.tcp-ip
Subject:   Re: FDDI and Ethernet

In Article <CGnAL3.HF0@ra.nrl.navy.mil>
atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
>>PS, (another can of worms) surely the various 100Mb/s ethernet squabble
>>    groups are going to use the FDDI MTU?!?
>
>Surely they will use a more sensible MTU size like the 9180 octets 
>chosen for IP over ATM and SMDS. :-)

Sorry, but all of the 100 MHz Ethernet type proposals I've seen retain the
Ethernet packet limits. The only change is in the IPG which is reduced from 9.6
usec to 960 ns. This is done to make transparent bridging possible. Grand
Junction specifically states in the 10Base-X papers that the maximum is
unenforced. AT&T has also told me that the 1518 byte size in 100Base-VG is for
Ethernet compatability.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov		(510) 422-6955

Disclaimer: Being a know-it-all isn't easy. It's especially tough when you
don't know that much. But I'll keep trying. (Both)

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 1993 17:51:34 -0000
From:      barryf@iol.ie (Barry Flanagan)
To:        comp.protocols.tcp-ip
Subject:   rlogind Hanging! Help!

 I am running SCO ODT 2.0 (3.2.4.0) and have a terminal server which is set
 up to use rlogin when a caller connects via modem. In the last few days it
 has hung a couple of times and not accepted any rlogin connections. Sending
 a HUP signal to inetd got it back working. Telnet and everything else
 remains fine, and no errors are recorded.

 The only other thing to have cropped up at around the same time is an
 occaisional lack of 4K Streams buffers.

 All help much appreciated.


-- 
Barry Flanagan - <barryf@iol.ie>
 ----
| Ireland On-Line, West Wing, Udaras Complex, Furbo, Galway,Ireland
| Tel/Fax : +353 91 92727 / 26 * BBS : +353 91 92722 (4 Lines)

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Nov 1993 19:04:35 GMT
From:      waynej@ncs.com (Wayne Johnson)
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   UDP/IP broadcast

I'm trying to do a UDP Broadcast on out IBM AIX system.  If I use the broadcast
address 127.255.255.255, I can issue the broadcast on the local loopback.  If
I use the broadcast address 159.182.42.255 (our local network is 159.182.42) I
can issue the broadcast on the network segment.  I would like to issue the 
broadcast on 255.255.255.255 so as to broadcast on both.  This worked on our
MIPS machines and the earlier version of AIX (3.1.5) but not any more.  

What gives?
-- 
Wayne D. T. Johnson       Internet: waynej@ncs.com      Phone: (612) 830-7880
     National Computer Systems, 4401 West 76th Street,  Edina, Mn.  55435 
"He is no fool, who gives up what he cannot keep, for what he cannot lose"
                                           - Jim Elliott

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Nov 1993 20:05:56 GMT
From:      geertj@ica.philips.nl (Geert Jan de Groot)
To:        comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Supernetting explained (was: Exceeding a Class C network capacity)

amoss@picton.cs.huji.ac.il (Amos Shapira) writes:

>houseman@hopper.ACS.Virginia.EDU (Carl Houseman) writes:
 
>|Javier Henderson <henderson@mln.com> wrote:
>|>We are soon to exceed our Class C network capacity. The Internic suggests
>|>subnetting. Are there any drawbacks to that? By the end of the year, we will
>|>have 300 nodes, and our final network size will be around 3,000 nodes (in about
>|>three to four years). We will have about 1,500 nodes by the end of 1994.
 
>|Subnetting?  Subnetting a class C network results in fewer usable addresses.
>|What was the NIC suggesting, exactly?
 
>Nothing short of expanding the name space will help here (class C networks
>are limited to 254 hosts, aren't they?).
 
>Maybe they ment "supernetting",  which as far as I know means combining
>closely-numbers networks into a "super"-network, e.g. 132.64 and 132.65 (our
>local class B networks) can be combined into one network by using a network
>mask of ff.fe.0.0.
 
>|When I asked the NIC about the availability of class B addresses, I was told
>|I needed to predict far more than 1000's of nodes to get one.  They suggested
>|I apply for additional class C addresses.  Maybe that's what they meant for
>|"subnetting"?
 
>Maybe that's a stage towards "suprnetting".  But you'll need very certain
>numbers for it to work.

A couple of comments:
1. For most organisations, having one class C number (254 hosts) is 
   usually too small, but a class B number (65534 hosts) is usually
   too big. Because these used to be only choices, people were given
   class B network numbers, which lead to a quick depletion of class
   B numbers (we would have ran out of them about now if assignment
   policies didn't change), while in many cases, the assignments 
   would not nearly be used in full (in this case, 3000/60000 is 
   only 5% !)
2. Therefore, these days the NIC prefers to assign blocks of 
   class C network numbers (at least in Europe, but this should be
   common practice by now). These block are usually grouped in a
   'bitwise fashion', like 192.128.128.0-192.128.255.255, which
   means that they can be easy described in one number with 
   separate mask like 192.128.128.0 mask 255.255.128.0. If you
   bitwise AND those, you see that the first 17 bits of the address
   are the same for your complete allocation (why, see below).
   Notice that the old class A, B and C numbers are just a special
   case, where the mask is 255.0.0.0, 255.255.0.0, 255.255.255.0
   respectively.
3. Using the IP address and mask, one can still describe the whole
   network as one thing. This is called supernetting: making one
   super net of a group of networks. (that is why the networks
   are grouped in a bitwise fashion).
4. Given the current state of the class B numbers, it has become much
   more difficult to get one. In this situation, 6 class C's
   would also be sufficient (but do plan for extra expansion: networks
   always grow faster as planned!).
   This gives big savings in available IP number space.
5. If you connect all those networks to the Internet, you would take
   more space in the routing tables (you would have taken one class
   B routing entry; now you would take 6 class C entries, so 6 times
   as much). There are plans to redisign the routing mechanism using
   the masks described above. This is called CIDR. You can read more
   about this in various RFC's and internet drafts (telnet to
   info.ripe.net and look around with the tools provided there).
   Things go even further: assignment is done in such a way that
   different network assignments can be aggregated on the Internet
   itself (i.e. if 192.128.128.0 255.255.128.0 is assigned to you, 
   192.128.0.0 255.255.128.0 preferrably would not be assigned 
   to someone at the other end of the world because that would
   mean that those routes cannot be 'combined' at other continents.
6. I assume that those 3000 hosts are NOT machines that would only
   be switched on for an hour per week or so. If that would be the case,
   you might look for dynamic assignment scheme.
7. You probably would NOT hook up those 3000 hosts on the same ethernet
   anyway. First, because those would all share a 10 Mbit ethernet
   (with the current fast workstations, 10-20 normally are enough
   to fill the network). Second, because you would need extra
   equipment to do so (there is a maximum of network taps per
   ethernet, and a maximum number of repeaters you can use).
   So, you probably want to split the network in smaller parts
   anyway. You can do that via subnetting, and your network would
   be split in 6 parts anyway if you would get 6 class C numbers
   (most machines still have the network class mechanism in their OS).
   Based on the points above, I'd consider this a Good Thing.
   I would probably split up those networks even further (use
   subnetting) for performance reasons.
   I'd prefer routers between those networks (you could run multiple
   network numbers on the same cable, but performance would suffer,
   and you cannot connect them all anyway).
8. I have seen comments that many BSD-derived hosts do understand
   subnetting, but don't understand supernetting, and that this would 
   cause problems using supernetting. I don't understand this problem
   because one would use much smaller networks anyway, and
   you could look at this scheme as 'having obtained 6 class C networks',
   which is a common situation in which these machines should simply
   work.

Based on this, I would obtain a suitable block of C's from your NIC
and start from there.  I hope this gives you some idea. 

Geert Jan



--8<--nip-nip---------------------------------------------------------------
Geert Jan de Groot,                                    'Typos hapen'
Philips Consumer Electronics, 
Building SFJ2-218, P.O. box 80002, 5600 JB Eindhoven, The Netherlands.
Internet:geertj@ica.philips.nl   Phone:+31 40 797408   FAX:+31 40 732340


-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 1993 20:24:37 GMT
From:      mprice@RBSE.Mountain.Net (Margie Price)
To:        comp.protocols.tcp-ip
Subject:   udp/ip -- Ada version?


I'm looking for udp/ip implementation, especially the Ada version.
Any information would be greatly appreciated, public domain/
commercial.  Thank you!

Margie Price
mprice@rbse.mountain.net



-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Nov 1993 20:36:57 GMT
From:      mvm@cbnewsb.cb.att.com (michael.v.murphy)
To:        comp.protocols.tcp-ip
Subject:   Unix boxes with multiple ethernet cards

    I have a situation where I am planning to connect two seperate TCP-IP 
based nets to one Sun SPARC. I will have an ethernet card for each net 
termination. Is it possible to pass data through the Sun from one net
to the other without writing custom code? It is impossible to bridge the
two nets for other reasons. Is there any references that deal with machines
with multiple network terminations (multiple ethernet cards) ?

						Mike Murphy
						mvmurphy@attmail.att.com

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Nov 93 01:27:00 +0000
From:      bryan.leaman@bitbytes.clark.net (Bryan Leaman)
To:        comp.protocols.tcp-ip
Subject:   seed

seed message

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 1993 14:26:59 -0500
From:      daoad@ucunix.san.uc.edu (Andrew)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Unreachable host ?

Hi,
Please help!  I CAN NOT telnet or FTP to a remote host.
The software we are using is DEC TCP/IP V2.0 runs under 
VAX/VMS V5.5. I don't understand why I can loop (ping) to 
this host but can not telnet to it.

The message bellow I get when I try to loop to this host.
------------------------------------------
$ ucx loop elvis
"icp --> icmp_type(3) != ICMP_ECHOREPLY (0)
%UCX-I-LOOPACT, ELVIS is alive "
-------------------------------------------

But when I try to telnet to this node, I get the message bellow.

---------------
$ telnet elvis
Trying...192.35.46.22
%UCX-E-TELNET_CONECT, Failed to connect to remote host
-SYSTEM-F-UNREACHABLE, remote node is not currently reachable."
-----------------------------------------------------------------------

Thanks in advance.
Andrew Dao
daoad@ucunix.san.uc.edu

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 93 13:21:15 CST
From:      allebrandi@inland.com (Tom Allebrandi)
To:        comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Exceeding a Class C network capacity

In article <2cdamkINNam8@srvr1.engin.umich.edu>, jal@acc.flint.umich.edu (John Lauro) writes:
> You can get it to work with almost any software, but it might cause
> all packets from one class C to another to bounce off the router even
> if they are on the same physical wire...  Should be fine if it's only
> occational...  I suggest getting a router and have each port on the
> router be a different class C network.  It may mean more class C networks
> then not using a router but that will be easier then getting a class B.

Correct. My warning was in response to the idea of taking two class C
networks and trying to combine them into one by fiddling the net mask.
In other words combining A.B.0.x and A.B.1.x by using a netmask of
255.255.254.0. This idea drives some IP implementations into fits.
        ^^^

--- Tom
Tom Allebrandi
Inland Steel Research Labs
Allebrandi@Research.Inland.Com

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 1993 18:24:03 -0600
From:      ucacjon@ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: IPng -- need info

well, its amazing how fast things change - here is an article i wrote about 10 weeks ago...

its 30% wrong now! (it was probably only 17% wrong then!

-----------Figure 1-----------
A View of the Internet
------------------------------------

The Internet 

Introduction

The Internet is a global network comprising in excess of 1.8 Million
computers, over 10 million users, reaching over 120 countries.
It is growing exponentially in number of computers attached,
in speed and in number of applications used, at around 100% every
year.

The fastest growth is in Europe and the Pacific rim. For instance, the
UK expanded from a small number of computers in London to over 100,000 
nationally in 2 years. Capacity in North America, Australia and Europe
has moved from 56 or 64kbps to 45 or 34 Mbps in the long-hail links (and at
many access points too). Most recent growth is not through the
installation of new computers, but from the interconnection of Islands
of Local Area Networks, Campus networks, national research
networks and commercial internetwork services, such as the UK Pipex
and UKNet services. 

---------------------Figure 2------------------
Graph of Growth of Internet
-------------------------------------------


The Internet is _not_ merely an electronic mail network. It provides
full interactive connectivity, from remote terminal access, file
transfer, file sharing, archiving and software distribution, remote
windows, through to low bandwidth audio and video conferencing.
This general functionality is feasible because it is a packet switched
network that links intelligent computing devices, in contrast to the
PSTN which is circuit switched and links simple telephones.

The Internet is not a managed network service. It _is_ a network of
networks, some of which are managed services, while others are 
run through goodwill and spare effort of the community.

In this article, we describe some of the history of the Internet, the
technology, how it is funded, whether and where it is managed,
problems, the various forum for discussion of the Internet, and the
Future.

---------------Figure 3-------------
Diagramatic Map of UK Academic part of Internet 

In the diagram, we see a number of sites interconnected by a mesh of
lines by routers. A site might consist of anything from a single 
computer, to a local area network of computers, right up to a large
university network with thousands of computers on Local Area Networks
("LANs") (e.g. Ethernets)  interconnected by a larger Metropolitan 
Area Network (e.g. FDDI).
------------------------------------

History

There are three key technologies that contributed to the success of
the Internet.

1. In the 1970's, the US research agency ARPA (Advanced Research Project
agency, later renamed Defense ARPA or DARPA, still later re-named ARPA
to reflect the 'peace dividend') funded the development of a
packet switched network called the ARPANET, together with a small
number of sites in Europe Connected by a satellite network called
SATNET.

2. The early 1980s saw the development of low cost high bandwidth Local
Area Network technology, in particular the Ethernet that permits
10Mbps networking over large buildings or small sites at costs as low as 100
dollars per machine attached.

3. In the early 1980s, DARPA funded the development of a networked
operating system, the Berkeley Standard Definition of Unix. This was
shipped with the software that could communicate in the same way as
systems used in the ARPANET at no extra cost.
Indeed, the software was made freely available in source form to
anyone.

Through the 1980's, the research and engineering community came to rely
more and more on Unix workstations as their main computing tool. The
economy of scale of workstations versus disks meant that an approach
called fileserving became key to larger installations of workstations.
Indeed, this has become commonplace in the DOS world too now.
Most universities in the US came to have very large numbers of such
systems interconnected by LANs. At no extra cost, network sharing of printers
and other devices came to be standard.

Meanwhile, a variety of wide area networks (WANs) were springing up in
the wake of the ARPANET, that allowed access to resources _between_
LANs. Early key access included:

- terminal access to remote supercomputing facilities
- file transfer (especially of documents for collaboration
- electronic mail

Towards the end of the 80s, the applications had evolved to include
- remote bitmap display (e..g X Windows)
- file sharing (e.g. Network File System)

It was these latter developments that led to the wide area uptake of
internet technology in countries and communities more traditionally
committed to the International Standards Organisation's Open Systems
Interconnection and associated protocols. 

One possible explanation is that the Standards process had failed to 
produce specifications that kept pace with the evolution of new 
application services. Another view is that the US defense budget
buying power seriously skewed the vendors view of what were key
products they could profit from. 

Whichever view is correct, the Unix workstation companies and network
vendors soon became major players in the Fortune 500, and the uptake
of their products overwhelmed other solutions.


Technology

The Internet is based on some extremely simple concepts.

All devices attached to the network have a unique address assigned by
a central authority. This has (essentially) two parts, a "host" part 
and a "network" part. Typically, a site with a LAN is assigned a
network number, and assigns each of the hosts on the LAN numbers with
different values of the host part.


-----------Figure 4-----------

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Every "packet" in the network is like a letter that contains the
destination and source addresses.
------------------------------


The Internet connects LANs together by devices called routers or gateways, 
that are intelligent in calculating routes between different network
numbers (using a variety of routing algorithms from a fertile research
community!).


IP:
The basic communication service provided by the IP protocol
is a "datagram" or "best effort"
packet switched service. This means that the network makes an attempt
to deliver a packet of data sent by any device to the right place.
However, there is little or no resource set aside to carry this out.
The assumption has been that the links between routers have sufficient
capacity for the traffic offered, or else packets are discarded after
some buffering capacity in a router is exceed (or a delay is
exceeded).  This service is called the "Internet Datagram Protocol", or
IP for short. IP defines a packet format that is ubiquitous. The key
part is that every packet carries the source and destination 32 bit IP
address.

TCP:
To cope with lost packets (for overload reasons, or for simple line
noise/corruption reasons), end systems implement a more complex
protocol above the IP service ("Above" simply means that packets are
encapsulate in IP packets). This is the "Transmission Control
Protocol" or TCP, which performs error detection and recovery, as
well as flow control and congestion avoidance.

Using TCP, hosts can communicate with one or more other hosts in the
Internet reliably. Applications are build directly on the 'reliable
bit-pipe' that TCP provides. Hence, file transfer and remote terminal
access are very straightforward. Differences of file structure, or
terminal type have been largely avoided in the Internet community by
assuming that people that wish to communicate will have compatible
filesystem structures (largely true in the Unix and DOS worlds) or are
using a terminal that is understood by the remote system. Thus
difficulties of data representation have been to some extent
finessed. Even the richer X Windows protocol dismisses these beyond
questions of big-endian versus little-endian integer representation.

Much of the Internet protocol "stack" is Plug-and-play. Once the
address assignment for IP has been made, many systems simply work.
Having said that, address assignment is a non-trivial problem.

Routing:

As sites build larger networks and install routers to permit more
flexible topologies (for bandwidth and administrative reasons) they
soon learn that routing is also a complex matter. unlike most
telephony trunk networks, the Internet uses fully dynamic routing.
Each and every packet is (can be) subject to a different routing
decision. This permits extremely fast recovery to link or node outage
since problems can be routed around (provided redundant paths) at the
very next packet, and end system recovery will fill in the missing
data if necessary. This does lead to complex fault diagnosis when
there are intermittent failures inside a large network.

Funding & Policing

Contrary to popular myth, the Internet is not a free good for all,
still less a free-for-all. It is funded in a variety of ways, and 
is lightly policed in variety of ways.

The underlying links are either provided by leased lines or by dial-up
(whether X.25 based, ISDN based or even low-bandwidth modem and
analog telephone line doesn't matter). Each of these must be paid for.

Typically, the infrastructure is paid for in one of 2 ways:

a) Bulk buy by a community of interest
b) Buying in access at a given speed to a commercial internet provider

In each case, it is up to the IP provider to apportion cost - this is
again usually done on the basis of access speed or site size, rather
than on fine-grain usage basis. It turns out that the economy of scale
of collecting in such a way suits both provider and subscriber quite
well.

The various communities that make up the Internet also have a variety
of policies that have a bearing on who can use the networks and for
what.

Due to its origins, most of the Internet is for "not-for-profit"
Organisation, such as US and other Universities and research
institutions, and there are stated policies on usage which include
policy for detaching mis-behaving sites. Policies include
non-commercial use only, and technical measures include filtering of
routes so that pure commercial sites cannot use the non-commercial part
s of the Internet to communicate directly with other purely
commercial sites  (they traverse the commercial parts of the Internet
instead).

This level of granularity of funding and policing has not seen many
violations in the few years it has been running.


Management

In the late 80s there was a perception (correctly) that the Internet
was very weak in management tools. This was rapidly overcome through
the development and deployment of the Simple Network Management
Protocol (SNMP). Indeed, so successful was the community's effort that 
SNMP has come to be a de facto standard for managing networks that run
altogether different protocols.

It must be stressed that bandwidth management is not a strong point 
in the current Internet mode (although nor is it in any other 'standard'
data network architecture), although the community is now very hard at
work on solving this important problem, and several solutions are4 at
the point of testing (of which more below).

Problems

The Internet has been said to be a victim of its own phenomenal success.
The growth has far outstripped anything dreamed of by the original
designers, and this had led to three key problems:

1. The Internet is running out of addresses to assign. The method used
to assign addresses has meant that most sites are given a lot more
addresses (or 'address space') than they use.
2. The Internet Routing system is unable to cope with the size,
dynamics and complexity of the simple flat address space.
3. Newer applications are putting the network under severe load 
and without bandwidth management techniques, the network is likely to
succumb to congestion.

The first two problems have been solved in the short term by the
introduction of an aggregation address assignment mechanism -
addresses are given in smaller blocks that can be aggregated togerther
as sites need and are assigned more. Longer
term solutions entail changing the Internet Protocol to accommodate a
larger, more structured address space. A "structured" address space is
one that ressembles the system used in the telephone and post office
delivery systems - where different parts of the address have differnt
meanings. To allow this, and still have plenty of addresses to go
round, we probably need a variable length address.

The research community has produced two proposals for radical
restructuring the IP service, called PIP and SIP PIP is radical in
that it proposes subtle complex routing mechanisms that permit very
complex hierarchies and policies to be expressed. SIP is the opposite,
and takes a RISC approach by enlarging but at the same time
simplifying the IP packet structure. 

A third proposal calls for the use of the ISO Connectionless Network Protocol 
in place of IP, and its associated 20 octet (aka byte) Network Service Access 
Points instead of 32 bit IP addresses.  This is called TUBA (TCP using 
Bigger Addresses). This has the main advatange that it is an
international standard, and already part of several Governement OSI
Procurement statements.

The key problem in deploying any new protocol is logistical. The sheer
number and variety of systems in place defies any complete plan.
Because of this, the fact that many of the routers in the Internet
already provide CLNP has been seen as a major plus point. However, few
hosts implement this protocol yet, so many people have argued that the
marketplace should be left to choose.

To provide bandwidth management, a variety of techniques are being
tested in the research community. These include techniques based on
novel queuing algorithms such as Hierarchical Fair Queuing, Class
Based Queuing or Virtual Clock. A Variety of theoretical underpinnings
include the model of Generalized Processor Sharing from MIT which is
very general and applicable to many packet switched network
architectures.

Forum for discussion

The Internet is unusual in the openness of its forum for discussion.
There is a professional Organisation which individuals and company and
not-for-profit Organisation can join called the Internet Society".
This appoints a group of experts called the Internet Architecture
Board who oversee the Internet Engineering Steering Group and the
Internet Engineering Task Force (IETF), who address problems to do with the
short to medium term in the Internet in regular meetings and via
electronic mail using mail lists. in the longer term, a number of
research groups look at solving the evolutionary problems seen on the
horizon.

The Internet Society has started negotiating working relationships
with other standards making organisations such as the ISO and
the ITU.

Future

The capacity for growth i nthe Internet seems a long way from being
exhausted. Indeed, although some researchers have predicted a
logistic curve of growth which should slow up very soon, in fact, each
stage of growth is followed by another step function in the level of
interconnection.

For example, there are plans for a Pan-European 34 Mbps IP (or
multiprotocol) infrastructure. There are moves afoot to start building
some 'super-router' sites called Global Internet Exchanges (GIX) to
mirror some of the US National Federal Internet Exchanges and
Commercial Internet Exchanges.

There is a great deal of interest in the CIS and ex-Warsaw Pact
countries in connecting to the internet, and the third world can
benefit from low cost flexible data communications enourmously in
coordinating meager or scattered resources.

At the hi-tech end, the last two years has seen the emergence of a
phenomenon I would term a Virtual Public Internet called the Multicast
Backbone or Mbone which builds new services by encapsulating them in 
the old IP service.

-----------Figure 3-----------
Map of the Mbone
------------------------------------

In particular, the Mbone permits multimedia traffic to traverse the
medium and higher bandwidth parts of the Internet to provide services
not seen anywhere before such as the dissemination of IETF meetings
to over 200 sites simultaneously, with audio and several video streams
being multicast efficiently across the world. The same Mbone is used
to disseminate Satellite images as they arrive at various
super-computing sites for weather systems analysis. It has also been
used for regular small meetings, for entertainment audio and video on
a small experimental scale. This is illustrated in Figure 1.


The real challenge to the Internet community however can be seen in
the form of the Broadband-ISDN initiatives. Asynchronous Transfer
Technology promises many of the technical solutions to some of the
problems of scaling found in the Internet. 

There are two ways that this may be used:

1. The Internet Community adopts ATM as simply another mechanism to
provide IP packet transfer, and uses its own traffic management
interfaces to talk to the underlying ATM service.

2. The Internet Community adopts ATM directly in some form as the
underlying architecture for carrying application traffic.

The former is currently a far more likely approach since (in the
opinion of the author at least) the communities providing ATM and 
Broadband ISDN technology have not really grasped the full
implications of the Internetworking approach for data and the open nature of
such networks, and are predominantly addressing the problems 
of telephony and data trunk services only. (This is reasonable 
from their point of view since there are 100s of millions of telephone
subscribers, and still only several million data service subscribers
worldwide.)

However, it is also possible that the Internet technology will not
evolve fast enough to match demand for new large scale multimedia
services, and B-ISDN will develop quickly enough to compete on an
even footing.

The preferred outcome of course would be technology transfer and a 
merging of expertise and experience.


-- 
jon crowcroft (hmmm...)

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 1993 09:01:10 GMT
From:      marant@univ-lille1.fr (Dominique Marant)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Searching talk BSD4.3 for Solaris


I would want to install talk that has compatibility with the talk BSD4.3
(ntalk, port 518/udp) on Solaris.

Where can I retrieve this one ?
Anyone can help me ?

--
Dominique Marant   -   marant@univ-lille1.fr 

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Nov 1993 09:07:41 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.dcom.lans.fddi,comp.protocols.tcp-ip
Subject:   Re: FDDI and Ethernet

oberman@ptavv.llnl.gov writes:
+---------------
| >Surely they will use a more sensible MTU size like the 9180 octets 
| >chosen for IP over ATM and SMDS. :-)
| 
| Sorry, but all of the 100 MHz Ethernet type proposals I've seen retain the
| Ethernet packet limits. The only change is in the IPG which is reduced from
| 9.6 usec to 960 ns.
+---------------

*All* times in the MAC protocol must scale down by a factor of 10,
not just IPG. For example, the maximum "diameter" of the net must
also be reduced from 51.2us to 5.12us, which is the new "slot time". 


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		Phone: 415-390-1673
2011 N. Shoreline Blvd.		FAX:   415-967-8496
Mountain View, CA  94043


-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Nov 1993 09:24:04 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.client-server,comp.protocols.tcp-ip
Subject:   Re: Help! Non-interactive file transfer

g552536@kirk.lasc.lockheed.com writes:
+---------------
| I am interested in non-interactive file transfer...
| wondering if there is a standard for non-interactive file transfer
| or a library interface to third party ftp packages...
| My goal is file transfer initiated automaticaly from a controlling
| remote program....
+---------------

The easiest thing is probably just to get the source for "ftp" and hack
it up to do what you want. Several years ago (when I was consulting for
another company) we did exactly this, and called it "netcp", since we
gave it "rcp"-like command-line syntax. That is, you just said:

	% netcp local_file remote_user@remote_host:remote_file

like you would with "rcp", but it used the FTP protocol to talk to a
standard FTP server on the remote. Password information was gotten from
the standard BSD "~/.netrc" file on the client side. By allowing "-"
as a "local_file", you could pipe to/from stdout/stdin, which meant
that you could use "popen()" to send/receive from some other program
that knew about "netcp". That is:

	FILE *fp;

	fp = popen("netcp larry@king:file/shows/NAFTA.debate", "r");

would give you a file handle for reading the file "NAFTA.debate" as it
came across from the remote FTP server.

I wish I could point you to a free source somewhere, but as I said,
this was done while I was a consultant. However, it was really fairly
straightforward to do starting from the source of the BSD "ftp" program...


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		Phone: 415-390-1673
2011 N. Shoreline Blvd.		FAX:   415-967-8496
Mountain View, CA  94043


-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Nov 1993 12:03:41 GMT
From:      kaaza@Informatik.TU-Muenchen.DE (Kaaz)
To:        comp.protocols.tcp-ip
Subject:   parallel RPC



Hi everybody

I'm trying to develop and implement a Client-Server-Modell based on RPC 
(transport mechanism TCP!) for parallel programming environments (like
PVM, P4, NX).

With an ordinary RPC the server gets one request, process it, an sends 
back a reply to that Client. But unfortunately this is not enough for 
my purposes. 

Under certain circumstances the server first must get requests by ALL 
clients involved in a parallel application (e.g. to check for consistence 
of the passed arguments by each client), process the according procedure, 
and than he should send back replies to ALL clients. 

Because the need of TCP I'm not able to use something like "callback 
broadcasting".

Does anybody has any clue or a hint, where to find articles about it?

Answers via email preferred.

Thanks, Andre

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Nov 1993 13:03:56 GMT
From:      mchase@world.std.com (MICHAEL P CHASE)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Help with Cameleon printer and SYSVR4

Hody Net,
 Could someone help with the following, I would like to have the printer
on my pc available to other UNIX boxes on my network, I have PC running
cameleon and a Ncr 3000 running SYSVR4, could someone please help, we
just want to have the people on the unix machine to be able to print to
the PC's printer, which is running windows with cameleon. I have everything
else working NFS, FTP, TELNET etc.

Thanks in advance

mchase@world.std.com



-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Nov 1993 14:36:11 GMT
From:      stacy@sobeco.com (Stacy L. Millions)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   connecting DECwanrouter 90 to a cisco router


I am looking at options for connecting a remote network to our network. The
remote network was built using DECwanrouter 90s and our net is built with
ciscos. I don't know much about the DECwanrouters, I have a few marketing
blurbs but they don't tell me much. Does any one know if the DECwanrouters
support PPP (or is there any other way to connect them to a cisco)?

Thanks.

-stacy

-- 
"... there are no absolute rights. Except maybe               stacy@sobeco.com
not to be shot by the police."                                 stacy@sobeco.ca
   - Al Blakeny                                                   sobeco!stacy

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Nov 1993 14:55:21 GMT
From:      sprowt@world.std.com (Steve Prowten)
To:        comp.protocols.tcp-ip
Subject:   SCO TCP/IP -- How to kill port or patch kernel?


When a TCP port gets hung in the CLOSING state, it is impossible to
restart the server for that port. Does anyone know of a standard
way to clear a TCP/IP port which has hung in the CLOSING state?
We found a method on the Mother Gopher (umn.edu) which uses `dbx'
to patch the running kernel. Unfortunately, our system (SCO 3.2...)
doesn't seem to have `dbx'. Does anyone know if this system has
a kernel patcher? We would like to avoid having to reboot just
to clear this problem.

A "netstat -A" of the culprit looks like:

f159e804 tcp      0    206  myhost.4500       mgz-164-89.p.12278 CLOSING

If anyone knows how to (1) easily unstick a hung TCP port or
(2) patch a running SCO kernel, please reply via e-mail to this
or directly to sprowt@infor.com and I'll sumamrize if there seems
to be interest.

Thanks in advance,

Steven

-- 
Steven Prowten   Inforonics, Inc.   sprowt@infor.com

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Nov 1993 15:05:07 GMT
From:      davidh@azurite.use.com (David Holland)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   WORKING version of KA9Q with PPP support STILL in it.

Hello

Can anyone tell me where to find a working version of KA9Q?
Don't tell me to read the fripping FAQ. I've done that.
The precompiled version that is on ucsd.edu doesn't have
PPP still in it.

Ah, so I say - I'll go get the source code...<BZZZZT>
Seems whom ever packaged up rcsdsrc.zip forgot several
source files. (And why the distributed it in RCS format I'll never know)

I did find a semi working version on wuarchive.wustl.edu. the
(930603 version to be exact) however the dialer was broken.
I fixed that, and recompiled it.

However, it still has several problems.

I'm using it as basically a simple router, between a stupid remote
machine that doesn't to PPP or SLIP (does have TCP-IP on ethernet)
into a real Livingston Portmaster.

I suspect that all of my problems are related to the following one:

It seems to loose interrupts at high speeds. (The DTE-DCE rate is 38400, 
and the DCE-DCE rate is 9600 via V.42/V.42bis)
Uncompressed data through this setup just simply gets lost, and stops.
Compressed data works fine. This is also with a 16550 I/O card
(FIFO's on), on a SX386-16, so I really doubt that the processor is too small.
(???)

It will not route X protocol. The modem lights work for a while, 
they stop, then eventually the client dies with basically a I/O error.

I've got files that I simply can not ftp through it. jpeg image
files to be exact. A couple of packets go across the wire, then it 
just stops.

Oh, yes, also, new sessions started while one is in the middle of dieing 
work fine.

So did I forget anything?

So, can anyone tell me either whats wrong - I really don't want to 
try reprogramming the tcp-ip layer - Its above my head.

Or where I can find a nice stable working version WITH ppp support
still in it? I'll even take suggestions for another 
public domain/shareware program that'll do routing.

Thank you!
Email replies prefered - I can summarize if desired.

David Holland

--
David Holland
davidh@dorite.use.com

Dream another dream, this dream is over. (Van Halen)
-- 
David Holland
davidh@dorite.use.com

Dream another dream, this dream is over. (Van Halen)

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Nov 93 17:48:46 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.dcom.lans.fddi,comp.protocols.tcp-ip
Subject:   Re: FDDI and Ethernet

In Article <lp03nji@sgi.sgi.com>
rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:
>oberman@ptavv.llnl.gov writes:
>+---------------
>| >Surely they will use a more sensible MTU size like the 9180 octets 
>| >chosen for IP over ATM and SMDS. :-)
>| 
>| Sorry, but all of the 100 MHz Ethernet type proposals I've seen retain the
>| Ethernet packet limits. The only change is in the IPG which is reduced from
>| 9.6 usec to 960 ns.
>+---------------
>
>*All* times in the MAC protocol must scale down by a factor of 10,
>not just IPG. For example, the maximum "diameter" of the net must
>also be reduced from 51.2us to 5.12us, which is the new "slot time". 

Yes and no. Only the IPG is specified in terms of time. Most network constants
in 802.3 are specified in bit times, so, while they do scale, the numbers in
the spec are constant. 

The time budget would limit networks running 100Base-X to a 250 meter diameter
and places severe constraints on the topology of the network when hierarchic
hub connections are used. For example, with a single hub, runs of the 100 meter
physical spec work fine, but if you link two hubs you must limit either the
link between hubs or all lines out of one of the hub to about 70 meters to make
the budget. In a heirarchy you may find limits of about 10 meters between the
"top" hub and the "bottom" ones.

Clearly bridging will be important in 100Base-X.

All information is from Grand Junction public documents, primarily from "Fast
Ethernet:Technology Approach" presented to the IEEE P802.3 CSMA/CD Working
Group in November, 1992 by Larry Birenbaum of Grand Junction.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov		(510) 422-6955

Disclaimer: Being a know-it-all isn't easy. It's especially tough when you
don't know that much. But I'll keep trying. (Both)

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Nov 1993 18:23:20 GMT
From:      mac@trantor.harris-atd.com (Mike McDonald)
To:        comp.protocols.tcp-ip
Subject:   SLIP for SunOS


  Does anyone know where I can get an implementation of SLIP for SunOS 4? Our sys
admin claims there's no mention of SLIP in any of the Sun docs or literature.

  Thanks,

  Mike McDonald				Advanced Technology Dept.	
					Harris Corp.
  Email: mac@trantor.harris-atd.com	M.S. 16-1912
  Voice: (407) 727-5060			P.O. Box 37
  Fax:   (407) 729-3363			Melbourne, Florida 32902


-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Nov 1993 21:48:40 GMT
From:      evansmp@mb48059.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP is *really* your friend

Russell Nelson (nelson@crynwr.com) wrote:
: BOOTP is *really* your friend.  A customer just finished (I hope!)
: suffering through a week of service outages because one of their
: users hand-configured their computer.  They used the default route as
: their IP address.  And every host that they connected to started to
: use them as their default route!

This is more a reason why people who do configuration should know 
what they are doing.

: This wouldn't have happened if the user had gone through channels and
: gotten an entry in the BOOTP tables...

It just means that there is only one central place where mistakes can
be made. Thus hopefully it will be easier if fault finding is needed.


-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Nov 1993 21:53:24 GMT
From:      evansmp@mb48059.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip,de.comp.os.unix
Subject:   Re: IP broadcast conventions

Ken Mintz (mintz@cup.hp.com) wrote:

:   RFC-1122 states that systems SHOULD recognize both types of broadcast.
:   But that will depend on system implementation.
 
:   The networks could become flooded with ICMP error messages if receiving
:   systems do not recognize the IP address as a broadcast and respond, despite
:   the fact that the IP datagram was broadcasted at the link layer (not
:   RFC-1122 conformant).
 
:   This problem can always arise, notwithstanding broadcast conventions, if
:   subnet masks do not agree, again if the receiving IP ignores the fact that
:   the datagram had been broadcasted at the link layer.

Many systems were written pre rfc-1122, also this rfc appears to be
frequently overlooked by software writers.

There are quite a few other things which you will be hard pressed to find
in implimentations, like support for source routing on connected sockets.

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 93 22:20:52 GMT
From:      sonecha@pepper.rutgers.edu (Darshan)
To:        comp.protocols.tcp-ip
Subject:   bufferning the received msg

if I am using datagram to send (usng sendto() function call). But at the
other end if I do not read right away does my datagram gets thrown away or
does it get buffered! If so how to invoke buffering fascilities! Thanks 

Darshan

email: sonecha@paul.rutgers.edu

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 93 00:18:34
From:      perrot_s@ion.epita.fr (Stephane Perrot)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP for SunOS


> Does anyone know where I can get an implementation of SLIP for SunOS 4?
> Our sys admin claims there's no mention of SLIP in any of the Sun docs or literature.


Give your sysadim UnixWorld, April 1992.
The tutorial title is "Giving your Sun the SLIP" ;-)


Have fun with SLIP !


--
Stephane Perrot                                           perrot_s@epita.fr
MORPHO Systemes                               (load-library "std-disclaim")

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Nov 93 22:55:10 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Exceeding a Class C network capacity

In article <1993Nov13.191118.196@mln>,
	Javier Henderson <henderson@mln.com> wrote:
>>We are soon to exceed our Class C network capacity. The Internic suggests
>>subnetting. Are there any drawbacks to that? By the end of the year, we will
>>have 300 nodes, and our final network size will be around 3,000 nodes
>>(in about three to four years). We will have about 1,500 nodes by the
>>end of 1994.

It sounds as if you would be very comfortable in a block of 16
contiguous class C networks.

In article <CGHs0r.99G@murdoch.acc.Virginia.EDU>
   houseman@hopper.ACS.Virginia.EDU (Carl Houseman) writes:
>When I asked the NIC about the availability of class B addresses, I was told
>I needed to predict far more than 1000's of nodes to get one.  They suggested
>I apply for additional class C addresses.

A contigous (bitmask-aligned) block of class C numbers is just as easy
for the backbone network operators to carry as a class B network, and
unless you really have over 30,000 hosts, it is less wasteful.
-- 
/ Lars Poulsen			Internet E-mail: lars@CMC.COM
  CMC Network Products		Phone: (011-) +45-31 49 81 08
  Hvidovre Strandvej 72 B	Telefax:      +45-31 49 83 08
  DK-2650 Hvidovre, DENMARK	Internets: designed and built while you wait

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Nov 93 22:59:37 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Exceeding a Class C network capacity

In article <1993Nov16.124207.4022@inland.com>
   allebrandi@inland.com (Tom Allebrandi) writes:
>You'll also need the right software. The IP implementations from Sun
>and Silicon Graphics don't understand this. (Or at least they didn't
>when we tried it in early '92.) At that time I was told that in theory
>this would work but it was not the intent of the architects and that in
>particular most Berkeley derivations would not work.

Anyone with a couple thousand hosts is hopefully beginning to impose
some structure on their network, matching subnet numbers and physical
cables with each other. And using a "real" router to connect them.
All hosts can forget about the supernet; really, only the backbone
service provider needs to aggregate the supernet.

The above statement may be true, but it is a non-problem.
-- 
/ Lars Poulsen			Internet E-mail: lars@CMC.COM
  CMC Network Products		Phone: (011-) +45-31 49 81 08
  Hvidovre Strandvej 72 B	Telefax:      +45-31 49 83 08
  DK-2650 Hvidovre, DENMARK	Internets: designed and built while you wait

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 93 01:38:43 GMT
From:      randy@psg.com (Randy Bush)
To:        comp.mail.uucp,comp.protocols.tcp-ip
Subject:   UUCP-t failure

On a UUCP-t over TCP link (both Suns running 4.1.x) we are getting a
repeatable failure in the first big outbound file which looks like the
appended -x9 output.  Any clues?

...
twrdata writing 1024 ...ret 1028
twrdata writing 1024 ...ret 1028
twrdata writing 1024 ...ret 1028
twrdata writing 1024 ...ret 1028
twrdata writing 1024 ...ret 1028
twrdata writing 1024 ...ret 1028
twrdata writing 1024 ...ret 1028
twrdata writing 1024 ...ret 1028
twrdata writing 1024 ...twrdata failed
cntrl - -1
omsg "OOOOOO"
send OO 0,omsg "OOOOOO"
imsg >^POOOOOO^@exit code -1
Conversation Complete: Status FAILED

TM_cnt: 0
--
randy@psg.com   ...!uunet!m2xenix!randy

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 1993 03:17:22 GMT
From:      rens@lorax.imsi.com (Rens Troost)
To:        comp.protocols.tcp-ip
Subject:   Wanted: Internetwork modeling software

Hi-

Can anyone point me to any work that has been done at modeling
(TCP/IP) internetwork performance? I need to do some capacity
planning for a network expansion. I'm especially interested in
anything that has been done with modeling NFS behavior over conditions
of varying latency and degradation.

Thanks!

-Rens
--
  o===============================================================o
  | J. Laurens Troost - UNIX Systems  | At Work: rens@imsi.com    |
  | Investment Management Svcs, Inc.  | At Play: rens@century.com |
  | 12 East 49th Street,  35th floor  |   Phone: (212) 339-2823   |
  | New York, New York         10017  |     Fax: (212) 339-2854   |
  o===============================================================o
     -- IMS is unlikely to share any of the above opinions --

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Nov 1993 03:50:28 GMT
From:      amatthi1@gwdu03.gwdg.de (Andreas Matthias )
To:        comp.protocols.tcp-ip
Subject:   Free DOS-Telnet with NE2000 - where?

Hi,

I'm searching for a free DOS TCP/IP implementation that would allow me
to connect with telnet to a Linux host. I'm using AE-2 cards (NE2000 compa-
tible) and no one of the packages I've seen so far seems to support those
cards. 
Do you know where I can find something that can work with my hardware, or
is it possible to use some other driver that is compatible with the cards
but labeled differently?
I don't have any experience with networking, so if this is the wrong
newsgroup for my question, please point me to the right one.

Thanks and Ciao,

Andreas


-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 93 10:49:16 MDT
From:      dwing@uh01.Colorado.EDU (Dan Wing)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: Unreachable host ?

In article <2cgia3$iie@ucunix.san.uc.edu>, daoad@ucunix.san.uc.edu (Andrew) writes:

>Hi,
>Please help!  I CAN NOT telnet or FTP to a remote host.
>The software we are using is DEC TCP/IP V2.0 runs under 
>VAX/VMS V5.5. I don't understand why I can loop (ping) to 
>this host but can not telnet to it.
>
>The message bellow I get when I try to loop to this host.
>------------------------------------------
>$ ucx loop elvis
>"icp --> icmp_type(3) != ICMP_ECHOREPLY (0)
>%UCX-I-LOOPACT, ELVIS is alive "
>-------------------------------------------
>
>But when I try to telnet to this node, I get the message bellow.
>
>---------------
>$ telnet elvis
>Trying...192.35.46.22
>%UCX-E-TELNET_CONECT, Failed to connect to remote host
>-SYSTEM-F-UNREACHABLE, remote node is not currently reachable."

I've heard that UCX's PING is broken.  Kaput.  Doesn't return the correct
information.  Try using UCX's Traceroute to check the path to the host
in situations like this.

There are other TCP/IP implementations for VMS which are considered by 
many to be superior to DEC's "UCX" product.

[followups re-directed.]

-Dan Wing, Systems Administrator, University Hospital, Denver
 dwing@uh01.colorado.edu or wing@eisner.decus.org
 
 Vote to sacrifice Ratbert!  Send Email to scottadams@aol.com

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 1993 13:59:14 -0500
From:      nalley@ssdc.SSDC.Sterling.COM (Nancy Alley)
To:        comp.protocols.tcp-ip
Subject:   FTP RFC Needed


Can anyone tell me where to find the FTP RFC?  I need it for an FTP port.
Thanks.

Nancy Alley 
Nancy.Alley@ssdc.ssdc.sterling.com
Packet: NT3Z @WB3V
_______________________________________________________________________________
The views expressed are not necessarily 
those of my employer.

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 1993 15:00:07 -0500
From:      brett@titan.ucs.umass.edu (BRETT A MILLER)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: Unreachable host ?

Andrew-

Is your ELVIS host running a telnet deamon(server)? 
Or the max number of connections on ELVIS could be in use.
(but that might be a different message.)

Good luck.

-Brett Miller
brett@student.umass.edu
millerba@mail.fws.gov
---------------------


-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Nov 1993 07:41:05 GMT
From:      simonp@fulcrum.co.uk (Simon Parsons)
To:        comp.protocols.tcp-ip
Subject:   Re: parallel RPC

 On Thu, 18 Nov 1993, Kaaz wroteOriginator: kaaza@sunbode29.informatik.tu-muenchen.de



> Hi everybody
 
> I'm trying to develop and implement a Client-Server-Modell based on RPC 
> (transport mechanism TCP!) for parallel programming environments (like
> PVM, P4, NX).
 
> With an ordinary RPC the server gets one request, process it, an sends 
> back a reply to that Client. But unfortunately this is not enough for 
> my purposes. 
 
> Under certain circumstances the server first must get requests by ALL 
> clients involved in a parallel application (e.g. to check for consistence 
> of the passed arguments by each client), process the according procedure, 
> and than he should send back replies to ALL clients. 
 
> Because the need of TCP I'm not able to use something like "callback 
> broadcasting".
 
> Does anybody has any clue or a hint, where to find articles about it?
 
> Answers via email preferred.
 
> Thanks, Andre

A good book is "Power Programming With RPC" John Bloomer (O'Reilly &
Associates Inc.) ISBN 0-937175-77-3

Basically any asynchronous calls need to be done yourself, i.e.
instead of using the Call/Reply of RPC it is broken down into two
calls, both with zero timeout, one from the client and then one from
the server. 

Simon
--
===========================================================================
Simon Parsons                                        (simonp@fulcrum.co.uk)
"Nervous energy makes him tick, he's a health fanatic - MAKES YOU SICK!"
                                                         John Cooper-Clarke
===========================================================================
Fujitsu Fulcrum Telecommunications Ltd., Fordrough Lane, Birmingham,
                                                           B9 5FL, ENGLAND.

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 1993 10:35:06 GMT
From:      Klaus Lenssen <klaus@informatik.rwth-aachen.de>
To:        comp.protocols.tcp-ip
Subject:   CfP: Broadband Islands 1994



    ######  ######    ###    #####            ###    #####  #
    #     # #     #    #    #     #           ###   #     # #    #
    #     # #     #    #    #                  #    #     # #    #
    ######  ######     #     #####            #      ###### #    #
    #     # #   #      #          #                       # #######
    #     # #    #     #    #     #                 #     #      #
    ######  #     #   ###    #####                   #####       #


------------------------------------------------------------------------
                            CALL FOR PAPER

                     3rd International Conference
                                  on
                        Broadband Islands 1994

                           Hamburg, Germany
                             June 7-9, 94


Important Dates
---------------
January  10, 1994       Deadline for submission
February 11, 1994       Notification of acceptance
March    11, 1994       Camera ready paper !!!

June      7, 1994       Tutorials
June    8-9, 1994       Conference


Objectives and Scope
--------------------
The widespread deployment of broadband networks creates possibilities for 
end users to exploit the capabilities of multimedia communications, thus 
adding to the competitive advantage of their business operations. Turning 
this possibility into a reality requires the successful transfer of the 
technology to end users, and the solution of key technical problems. The 
main goals of the conference are to provide a forum where technical 
problems and their solutions will be discussed, and to demonstrate 
multimedia applications on broadband networks. 
The conference aims to bring together network operators, service
providers, 
multimedia application designers and end-users to accelerate the 
development of distributed multimedia applications for broadband
networks. 

The following issues will be addressed: 
-   Technical problems involved in adapting applications for use on 
    broadband networks 
-   New services and applications for broadband networks
-   Use of multimedia applications in a distributed multi-user
environment 
-   Multimedia to residential end user
-   Multimedia access to mobile end users

The conference will be held in Hamburg to emphasise its importance as one 
of the three locations in Germany to be provided with an ATM-Switch as 
part of the Deutsche Telekom ATM Field Trial. The conference is being 
organised by the RACE projects EuroBridge and CIO projects and the ATM 
Forum. It is the first official conference of the Advanced Communication 
Experiments Projects of the RACE Programme. This conference follows the 
highly successful conferences on Broadband Islands held in Athens, in
1993 
and in Dublin, in 1990.


Structure of the Conference
---------------------------
The conference will comprise four dedicated streams
-    Technical Stream
    Latest research results will be communicated
-    Strategic Stream
    Strategic and political issues will be addressed by invited experts 
    in the field
-    Applications and Market Stream
    Market trends and forecasts will be presented
-    Demonstration Stream
    Non-commercial multimedia and broadband related developments will 
    be on show
    
    
Paper Submissions
-----------------

TECHNICAL STREAM:
-----------------
Original full papers on all technical aspects related to multimedia and 
broadband communication are solicited. Topics of particular interest 
include, but are not limited to:
-    Multimedia applications and services
-    Multimedia communication requirements
-    Network interconnection
-    High performance protocols

APPLICATIONS AND MARKET STREAM:
-------------------------------
Submit extended abstracts (one A4 page) or full papers focusing on 
applications, economic and organisational issues, including
-    Applications development
-    Usability aspects
-    Market trends and economic implications

DEMONSTRATION STREAM:
---------------------
Please contact:
        Dr. Wulf Bauerfeld
        DeTeBerkom GmbH
        Voltastrasse 5
        D-13355 Berlin, Germany
        Phone (+49) 30 467 01310
        Fax (+49) 30 467 01445
        e-mail: Bauerfeld@deteberkom.detecon.d400.de
        
        
Send four copies of the paper/extended abstract (please state the
intended 
stream) to:
        Kai Jakobs
        Technical University of Aachen
        Computer Science Department, Informatik IV
        Ahornstrasse 55
        D-52074 Aachen, Germany
        Phone (+49) 241 80 21405
        Fax: (+49) 241 80 21429
        e-mail: BRIS94@informatik.rwth-aachen.de 
        
For further information, please contact:
        Jane Korsager
        Ericsson Eurolab Deutschland GmbH
        Ericsson Allee 1
        D-52134 Herzogenrath, Germany
        Phone (+49) 2407 575 118
        Fax: (+49) 2407 575 400
        e-mail: eedjak@chapelle.ericsson.se 


#========================================================================#
|                         *****************                              |
|                          Important Dates                               |
|                         *****************                              |
|                                                                        |
|          January  10, 1994    Deadline for submission                  |
|          February 11, 1994    Notification of acceptance               |
|          March    11, 1994    Camera ready paper !!!                   |
|                                                                        |
|          June      7, 1994     Tutorials                               |
|          June    8-9, 1994     Conference                              |
|                                                                        |
| The proceedings will be published by Elsevier Science Pulbishers B.V.  |
#========================================================================#


        
PROGRAMME COMMITTEE
===================
        S. Konidaris (Chair)    CEC, Belguim
        E. Andersen             SAS, Denmark
        W. Bauerfeld            DeTeBerkom, Germany
        A. Casaca               INESC, Portugal
        A. Clark                HUSAT, UK
        B. Cooper               JANET, UK
        A. Danthine             Univ. of Lie`ge, Belgium
        A. Entwistle            Analysys, UK
        D. Ferrari              Univ. of Berkeley, USA
        N. Georganas            Univ. of Ottawa, Canada
        U. Killat               MAZ Hamburg, Germany
        P. Kuehn                Univ. of Stuttgart, Germany
        Y. Liang                RIC, Belgium
        P. Linington            Univ. of Kent, UK
        P. Martini              Univ. of Paderborn, Germany
        A. Patel                Univ. College Dublin, Ireland
        R. Popescu-Zeletin      GMD FOKUS, Germany
        P. Potin                IBM, France
        V. Reible               DeTeBerkom, Germany
        T. Saito                Univ. of Tokyo, Japan
        D. Shepherd             Univ. of Lancaster, UK
        O. Spaniol              Univ. of Aachen, Germany
        A. Spinner              Ericsson Eurolab, Germany
        R. Steinmetz            IBM ENC, Germany
        K. Uhde                 MAZ Hamburg, Germany
        
STRATEGIC COMMITTEE
===================
        R. Hueber (Chair)       CEC DG XIII, Belgium
        M. Buchmayer            Ericsson, Germany
        A. Danthine             IFIP
        R. Dorn                 ATM Forum, Belgium
        B. Ericson              Ericsson, Sweden
        S. Schindler            TELES, Germany
        J. Baal-Schem           IEEE Region 8
        O. Spaniol              IFIP
        K. Ullmann              DFN, Germany
        W. Zucker               MAZ Hamburg, Germany
        A. Funck                Telekom, Germany
        
ORGANISING COMMITTEE
====================
        F. Williams (Chair)     Ericsson Eurolab, Germany
        S. Bruyn                BNR Europe Limited, UK
        H. Escola               TELES, Germany
        M. Guenay               MAZ Hamburg, Germany
        K. Jakobs               Univ. of Aachen, Germany
        N. Kerforn              DeTeBerkom, Germany
        J. Korsager             Ericsson Eurolab, Germany
        K. Lenssen              Univ. of Aachen, Germany
        J. Nolan                CEC, Belgium

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 1993 12:02:57 GMT
From:      kat@aida.inflab.tuwien.ac.at (Thomas Keil)
To:        comp.protocols.tcp-ip
Subject:   PD-Source of tftp

Does anyone know where to get a PD-source of tftp/tftpd?

Thanks
Thomas Keil

kat@carmen.inflab.tuwien.ac.at


-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Nov 1993 12:41:01 GMT
From:      leo@elmail.co.uk (E.J.Leoni-Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: rlogind Hanging! Help!

In article <2cdob6$3jr@ulysses.iol.ie> barryf@iol.ie (Barry Flanagan) writes:
> I am running SCO ODT 2.0 (3.2.4.0) and have a terminal server which is set
> up to use rlogin when a caller connects via modem. In the last few days it
> has hung a couple of times and not accepted any rlogin connections. Sending
> a HUP signal to inetd got it back working. Telnet and everything else
> remains fine, and no errors are recorded.
>
> The only other thing to have cropped up at around the same time is an
> occaisional lack of 4K Streams buffers.
>
I think that may be significant. IME lack of streams buffers screws TCP/IP
up badly, and hanging server daemons is not untypical.

Increase the relevnat kernel parameters and rebuild...



-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 1993 11:14:07 +0100
From:      swe@tau.informatik.tu-chemnitz.de (Steffen Weber)
To:        comp.protocols.tcp-ip
Subject:   bootp info ?

Hi,

i`m looking for a description for bootp. (drafts, a.s.o.)

Thanks !

Please mail me: email: Steffen.Weber@informatik.tu-chemnitz.de

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 1993 04:33:51 -0800
From:      skl@Connectivity.com (Samuel Lam)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: connecting DECwanrouter 90 to a cisco router

In article <1993Nov18.143611.8862@sobeco.com>, stacy@sobeco.com
 (Stacy L. Millions) wrote:
>Does any one know if the DECwanrouters support PPP (or is there any
>other way to connect them to a cisco)?

The software in the DECwanrouter 90 is basically Cisco software with
DEC's enhancements, so you should be able to get it to talk to a real
Cisco over a WAN link using the usual way you get two Cisco's to talk
to each other over a WAN link.

...Sam
-- 
<skl@Connectivity.com> -- Connectivity Technology Inc.

"NetNews on CD's" product information: <NewsCD@CDPublishing.com>
			   or {ftp,gopher,www}.CDPublishing.com


-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Nov 1993 16:31:44 GMT
From:      larry@cchtor.cch.com (Larry Chin)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Public Domain TCP/IP for PC ?


Greetings all.

I am looking for a tcp/ip implementation for the PC that will provide a
tcp/ip stack to a terminal emulator and I am hoping somebody out there
can help me.

The terminal emulator hooks into the existing tcp/ip stack ( if there is
one ) and accesses a host computer over the LAN. I need something along 
the lines of the PC-NFS or FTP software set up where the IP stack is memory
resident and accessible by any software that knows how to access the stack.

I am NOT looking for something like CUTCP/CUTE, unless of course somebody
can tell me how to access the tcp/ip stack included with this package
from a terminal emulator.
I don't necessarily need the telnet or ftp capabilities 
( although I imagine they would be included ), which is why CUTCP is not
necessarily what I need. 


If anyone knows of anything similar to what I have described above I would
really appreciate hearing about it.

Please reply by e-mail as our news feed is on a very short expiry - we
blew a disk and are using a smaller one for news until a replacement
shows up.


Thanks,

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

Larry Chin {larry@cchtor.cch.com}		CCH Canadian Ltd.
System Administrator				6 Garamond Court
Research and Development			North York, Ontario.
(416) 441-4001 ext. 349				M3C 1Z5

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


-- 
================================================================================

Larry Chin {larry@cchtor.cch.com}		CCH Canadian Ltd.
System Administrator				6 Garamond Court

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Nov 1993 16:31:48 +0000
From:      akirkby@pentala.demon.co.uk ("Andrew P.Kirkby")
To:        comp.protocols.tcp-ip
Subject:   Re: Free DOS-Telnet with NE2000 - where?

In article <FRAJB34N@gwdu03.gwdg.de> amatthi1@gwdu03.gwdg.de writes:

>Hi,
>
>I'm searching for a free DOS TCP/IP implementation that would allow me
>to connect with telnet to a Linux host. I'm using AE-2 cards (NE2000 compa-
>tible) and no one of the packages I've seen so far seems to support those
>cards.

Hello,
     Try looking at either KERMIT 3.12 (I think thats the right version - 
Its the current one anyhow.) That will support TELNET to a UNIX host. It 
requires packet drivers for the card, but there shouldn't be any problem 
there. OR WNQVTNET - Simtel /msdos/windows - It will provide FTP, TELNET & 
other goodies for use in MS Windows. It again uses the packet drivers.

>Thanks and Ciao,
 No problem.
>
>Andreas
>
 Andy
>
-- 
+------------------------------------------------------------------------+
| Andrew P.Kirkby                | Telephone +44 (0) 850 381789 Mobile   |
| Leeds, West Yorkshire          | Internet  akirkby@pentala.demon.co.uk |
| ENGLAND                        | ...C'est la vie! - Or as they         |
|    'The Heart of the North!'   |           say in France - Thats Life! |
+--------------------------------+---------------------------------------+

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Nov 93 16:33:11 GMT
From:      bansal@ccrl.nj.nec.com (Vivek Bansal)
To:        comp.protocols.tcp-ip
Subject:   IP multicast ...

 
I am having problem starting mrouted after I added the IP multicast
patch to my kernel. When I start mrouted the error I get is:
 
can't enable DVMRP routing in kernel: Operation not supported on socket
 
Where did I go wrong ????
 
Vivek..


-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Nov 1993 17:16:33 GMT
From:      mbrady@pnet16.cts.com (Rmc M. Brady)
To:        comp.protocols.tcp-ip
Subject:   NEWS POSTING PROBLEM

HELP!!! SCO TPC/IP 'e' protocol news hands during peak load hours!!!

I am finally posting this problem because frankly I'm going nuts trying to
figure it out. I am the assistant system administrator of a SCO UNIX 3.2v4.1 
system. We use the SCP TCP/IP Protocol. About 3 months or so ago we started 
having a problem with our news feed hanging up during the polling process. 
About 1 month before that we went from polling news from uucp to TCP/IP  
directly from the internet.
This seems to happen only during "peak" hours (mid morning to mid afternoon HST)
It started out just once or twice a day and has now grown to about 10 times or
better per day. Most of the time the bit count hangs at 42000 and must be killedmanually in order to poll during the next news period. The bit count also
has hung at 81936 and at 83984 but not NEAR as often. Has any one else          experienced or even HEARD of this happening??? If any additional information
is required please let me know. 

 Thanks in advance.     

                 Mike

 
UUCP: nctams1.navy.mil!pnet16!mbrady
INET: mbrady@pnet16.cts.com

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Nov 1993 19:34:59 GMT
From:      ihsan@nmti.com (jaleel ihsan)
To:        comp.protocols.tcp-ip
Subject:   TCI/IP vs OSI comparison book


There is book favourably comparing TCP/IP against ISO protocols (some
people have accused the author of being opinionated !).  Could some one
please provide me with information regarding this book.

Thanks a lot.

Jaleel

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Nov 1993 20:42:14 GMT
From:      msc@ssigate.ssinc.com (Michael S. Cross)
To:        comp.protocols.tcp-ip
Subject:   Re: definition of 'internet'

>>I'm doing a presentation for one of my classes on 'internet'.  I
>>haven't come across a good definition.  Would anyone have a good
>>definition for it?

Well, anyone can have an internet.  Internets are backbone networks, possibly
between networks of different types (like ours is).  Now, "The Internet"
on the other hand, is a Global network:

>Internet:   The largest collection of academic and commercial networks, 
>primarily based on the protocol TCP/IP.  This network facilitates Email, Remote
>logins, access to public and private files, programs, and information services.

I usally refer to it as the Global Internet to avoid confusion.  I didn't
come up with the name, I saw it on UseNet and published in some books whos
names escape me at the moment.

Hope it helps (tm).

Mike

-- 
Michael S. Cross    Work: msc%ssigate.UUCP@tellab5.tellabs.com    708-505-4508
    Home:   msc@genesis.MCS.COM    and/or    73750.1363@CompuServe.com
Systems and Synchronous Inc., 900 E. Diehl Rd, Suite 110, Naperville, IL 60563
________It's good to be important, but it's more important to be good_________

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Nov 1993 21:07:50 GMT
From:      mturc@berlioz.nsc.com (Moe Turcotte)
To:        comp.protocols.tcp-ip
Subject:   Fragmentation & Reassembly

I've got a question about F&A. If the answer is in a FAQ, please point me to it.

RFC 1122 (Host Requirements) says that the Internet model requires hosts
to support reassembly.

Our monitoring of random internet traffic has failed to produce a single
fragmented packet. Even though we are sending FTP traffic accross an X.25
link.

So, is this a completeness requirement or a real-world necessity?

Will a host that does not do reassembly fail miserably on the internet, or
will it fail to talk to some small percentage of hosts?

 
-- 
 Maurice R. Turcotte            Staff Software Engineer
 mturc@atlanta.nsc.com          National Semiconductor 
 Ph:  (404) 903-1886            500 Pinnacle Court, Suite 525 
 Fax: (404) 903-1827            Norcross, GA 30071 

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 93 22:49:43 GMT
From:      davek@melupl (Dave Kennedy)
To:        comp.protocols.tcp-ip,comp.client-server
Subject:   Timed for DOS, Windows, and OS/2

Is there is a port(s) of timed to DOS, Windows, or OS/2?  If so, is 
there an archive for them?  I've got the BSD source and will do the 
port if necessary, but if the wheel's already been built why bother?  
Right?  

If the port(s) has not been done, is there a reason?
-- 
| Dave Kennedy             UUCP:   {gatech,emory}!dscatl!melupl!davek    |
| Voice: 404-409-4575  Internet: davek%melupl.atl.ga.us@mathcs.emory.edu |
|                      "Accept no pianos as payment"                     |

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 1993 23:31:52 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Fragmentation & Reassembly

In article <1993Nov19.210750.4586@berlioz.nsc.com> mturc@berlioz.nsc.com
(Moe Turcotte) writes: 
    I've got a question about F&A. If the answer is in a FAQ, please point
    me to it. 
    
    RFC 1122 (Host Requirements) says that the Internet model requires hosts
    to support reassembly.
    
    Our monitoring of random internet traffic has failed to produce a single
    fragmented packet. Even though we are sending FTP traffic accross an X.25
    link.
    
    So, is this a completeness requirement or a real-world necessity?
    
Real-world requirement.  NFS, for example, depends on fragmentation
(unfortunately).

    Will a host that does not do reassembly fail miserably on the internet, or
    will it fail to talk to some small percentage of hosts?

Fail miserably.  For proof, turn down the MTU on your X.25 connection so
that your router has to fragment.

BTW, doing reassembly is NOT tough.

Tony



-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Nov 1993 23:53:01 GMT
From:      fenner@cmf.nrl.navy.mil (William C Fenner)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: Unreachable host ?

In article <2cgia3$iie@ucunix.san.uc.edu>,
Andrew <daoad@ucunix.san.uc.edu> wrote:
>The message bellow I get when I try to loop to this host.
>------------------------------------------
>$ ucx loop elvis
>"icp --> icmp_type(3) != ICMP_ECHOREPLY (0)
>%UCX-I-LOOPACT, ELVIS is alive "
>-------------------------------------------

UCX is lying to you.  icmp_type 3 is "Unreachable".

  Bill
-- 
Bill Fenner                  fenner@cmf.nrl.navy.mil

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 1993 10:59:43 -0600
From:      CELUSTP@cslab.felk.cvut.cz
To:        comp.protocols.tcp-ip
Subject:   Red book - info needed

Hi all,

Could anybody tell me where to find (electronically if possible) "The 
Trusted Network Interpretation" ("Red Book")?

Also any (and all) info about measures taken to improve security of TCP/IP 
protocol suite - authentication, encryption, sensitivity labels, etc., 
will be appreciated. Thanks.

Cheers,

Suzana
---------------------------------------------------------------------------
Suzana Stojakovic-Celustka                e-mail addresses:
Department of Computers                   celustka@sun.felk.cvut.cz
Faculty of Electrical Engineering         celustkova@vax.felk.cvut.cz
Karlovo Namesti 13.                       celust@cslab.felk.cvut.cz
12135 Prague 2                            phone : (+42 2) 293485
Czech Republic                            fax : (+42 2) 290159

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20 Nov 1993 01:47:04 GMT
From:      johna@netcom.com (John Allen)
To:        comp.protocols.tcp-ip
Subject:   FTP and buffers full

I am trying to use FTP to transfer a file from a PC using NCSA telnet
to a VAX with WINTCP. IF I put the file from the PC to the VAX
I keep getting a error message from the VAX TCP that buffers have 
overflowed or are full.  If I get the file from to PC on the VAX
no problem.
Both machines have packet sizes set at 1024.  The Vax window size is 7
the PC 4.  It is like the flow control is not working when putting from
the PC. I have little experience with the NCSA S/W.  Are there known
problems?  The file in question is clear text with records delimited
only with newlines (the file originates on a UNIX system).

Much thanks for any pointers.
-- 
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
John F. Allen               johna@netcom.com           (408) 426-8146 Home
Unisys Corp.                johna@vnet.ibm.com         (408) 235-2481 Work
"The difference between genius and stupidity is that genius has its limits."
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20 Nov 1993 03:37:57 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: Fragmentation & Reassembly

Moe Turcotte (mturc@berlioz.nsc.com) writes:
> Our monitoring of random internet traffic has failed to produce a single
> fragmented packet. Even though we are sending FTP traffic accross an X.25
> link.

  That's because TCP (which FTP uses) reduces its packet size to avoid
  IP fragmentation.

  UDP (which NFS uses) does not do that.  If you set the wsize and rsize
  for NFS about the MTU, you will see lots of fragmentation.

> Will a host that does not do reassembly fail miserably on the internet, or
> will it fail to talk to some small percentage of hosts?

  Generally, it will fail miserably.  Even though a TCP will try to 
  avoid IP fragmentation, it might not have the right picture of the
  "connection" MTU.

  Most TCPs only know the MTU for the directly-connected network.  When
  the packet is transmitted through many gateways, fragmentation becomes
  more likely.

  The receiving host must be able to reassemble the fragments.

-- Ken Mintz

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20 Nov 1993 03:40:36 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: IP multicast ...

Vivek Bansal (bansal@ccrl.nj.nec.com) writes:
> I am having problem starting mrouted after I added the IP multicast
> patch to my kernel. When I start mrouted the error I get is:
>  
> can't enable DVMRP routing in kernel: Operation not supported on socket
>  
> Where did I go wrong ????

  Quite likely, nothing.  Not all kernels that support IP multicast
  support the kernel functions need to support mrouted.  It is not
  a requirement for RFC-1112 compliance.

-- Ken Mintz

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20 Nov 1993 03:44:17 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: bufferning the received msg

Darshan (sonecha@pepper.rutgers.edu) writes:
> if I am using datagram to send (usng sendto() function call). But at the
> other end if I do not read right away does my datagram gets thrown away or
> does it get buffered! If so how to invoke buffering fascilities! Thanks 

  Of course, that really depends on the implementation.  But I can't 
  imagine a viable (marketable) host implementation that does not buffer
  incoming messages.  Of course, the buffer size can vary, causing lost
  messages.

  For BSD, the "buffer" is the socket.  The receive socket buffer can be
  controlled by setsockopt(SO_RCVBUF).

-- Ken Mintz

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20 Nov 93 04:04:07 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: Fragmentation & Reassembly

In article <1993Nov19.210750.4586@berlioz.nsc.com> mturc@berlioz.nsc.com (Moe Turcotte) writes:
>I've got a question about F&A. If the answer is in a FAQ, please point me to it.
>
>RFC 1122 (Host Requirements) says that the Internet model requires hosts
>to support reassembly.
>
>Our monitoring of random internet traffic has failed to produce a single
>fragmented packet. Even though we are sending FTP traffic accross an X.25
>link.
>
>So, is this a completeness requirement or a real-world necessity?
>
>Will a host that does not do reassembly fail miserably on the internet, or
>will it fail to talk to some small percentage of hosts?
>

You seem to be lucky, not having to worry about fragmentation.

Many people in the Linux community have had a lot of problem with internet 
access (both Ethernet and Serial Line Internet Protocol (SLIP)) because 
reassembly was not available for quite a while.

In other words, you might get away without fragmentation/reassembly support, 
but it can be a real bitch if you can't!


-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Nov 93 17:03:34 +0700
From:      "Vladimir Sovetov" <sova@bank.kemerovo.su>
To:        comp.protocols.tcp-ip
Subject:   What doed _sliplogin[1345]:ioctl(SLIOCGUNIT):Device not configured_ mean?

   Hello, folks

  We tried to connect DOS PC/TCP 286 with BSD/386 1.0 server via
SLIP. But surly failed to configure RISCOM ttya1.
  Right before this port worked pretty well as dialup port and
the line in /etc/ttys was

ttya1 "/usr/libexec/getty bidir.19200" dialup on

and we didn't change it.

   Just added the new user in /etc/passwd

slp:*:1012:1:Testing SLIP Line:/usr/users/sl1:/usr/sbin/sliplogin

   And created two one line files
       /etc/slip.hosts
#
slp 193.124.197.1 193.124.197.2 ffffffe0

       /etc/slip.login
#
0 19200

and then tried to login
    as PC/TCP client with comscrpt command
    and as plain user from ttyc4

 The result was the same
    -on user tty message

	     starting  slip login for slip

  and at the same time on /dev/console

   -sliplogin[1345]:ioctl(SLIOCGUNIT): Device not configured

  so nothing comes in fact, and  netstat -in informed
  sl0*

   Thanks in advance for any tip and advise


 ----------------------------+------------------------------------------
 Vladimir Sovetov           |  Still, it's out of the question to shoot
                            |  an old Harrovian
                            |                  Evelyn Waugh



-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 1993 18:16:55 -0800
From:      skl@Connectivity.com (Samuel Lam)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: connecting DECwanrouter 90 to a cisco router

In article <2cl2rf$4qc@vanbc.wimsey.com>, I wrote:
>In article <1993Nov18.143611.8862@sobeco.com>, stacy@sobeco.com
> (Stacy L. Millions) wrote:
>>Does any one know if the DECwanrouters support PPP (or is there any
>>other way to connect them to a cisco)?
>
>The software in the DECwanrouter 90 is basically Cisco software with
>DEC's enhancements, so you should be able to get it to talk to a real
>Cisco over a WAN link using the usual way you get two Cisco's to talk
>to each other over a WAN link.

I was just informed by Scott Bradner <sob@harvard.edu> (the router
benchmarking guru) that the DECbrouter 90 is the one that's based
on Cisco software while the DECwanrouter 90 is based on DEC's own
router software.

Sorry for the confusion between the products.

...Sam
-- 
<skl@Connectivity.com> -- Connectivity Technology Inc.


-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 1993 18:02:34 -0500
From:      hauben@news.cs.columbia.edu (Michael Hauben)
To:        alt.culture.internet,comp.protocols.tcp-ip,comp.misc,alt.amateur-comp
Subject:   RFC1000 - Questions about the origins of ARPANET Protocols 1/2

The history contained in the introduction to RFC 1000 raises some
interesting questions. Please answer either publically or via
email. I'm sure others might be interested in the answers, so
even if answers are not public I will either post a summary
and/or my paper when it is done. I am working on an independent
study looking into the history of TCP/IP. This is Part 1 of 2.

>THE ORIGINS OF RFCS - by Stephen D. Crocker
 
>   The DDN community now includes hundreds of nodes and thousands of
>   users, but once it was all a gleam in Larry Roberts' eye.  While much
>   of the development proceeded according to a grand plan, the design of
>   the protocols and the creation of the RFCs was largely accidental.

Is this accidental nature of the design of protocols and
invention of RFC's instrumental to the network being what
it is today?  Does this manner of creation from (perhaps)
bottom-up reflect a fundamental difference from the way OSI has
been designed from top-down?

>   The procurement of the ARPANET was initiated in the summer of 1968 --
>   Remember Vietnam, flower children, etc?  There had been prior

Why is 	the summer of '68 connected to the procurement of the
ARPANET? Can someone explain the significance of this? This is a
very interesting statement and I would be interested if anyone
has any understanding as to its meaning.


   [...Sections deleted....]

>   To stimulate
>   this process, a meeting was called during the summer with
>   representatives from the selected sites, chaired by Elmer Shapiro
>   from SRI.... At this point we knew only that the network was
>   coming, but the precise details weren't known.

The whole experimental nature of the ARPANET project was very
important and crucial to the work that was being done. As such
the "precise details" being unknown fit. What seemed to be the
challenge and what problems were anticipated? Can anyone
recommend someone to write to in order to find out more details?

>   That first meeting was seminal.  We had lots of questions -- how IMPs

Could anyone further explain why this meeting was seminal? Was
this a "first" meeting in that it was the first raising of such
questions of the interconnection of computers as such? Was the
Networking Working Group of such an importance in breaking ground?

>   and hosts would be connected, what hosts would say to each other, and
>   what applications would be supported.  No one had any answers, but
>   the prospects seemed exciting.  We found ourselves imagining all
>   kinds of possibilities -- interactive graphics, cooperating
>   processes, automatic data base query, electronic mail -- but no one
>   knew where to begin.  

Is there any kind of notes or information (similar to an RFC)
which might exist about this first meeting? It would be immensely
interesting if more "artifacts" existed about the very beginnings
of this all. What are other people's thoughts about this first
meeting from the details in this RFC?

>   We weren't sure whether there was really room
>   to think hard about these problems; surely someone from the east
>   would be along by and by to bring the word.  

So the NWG in the West consisted of graduate students. This line
seems to hit at some untold expectations they had. Is there any
way to recreate the times? In order to fully understand how the
development of the ARPANET, NCP and then TCP/IP, it would be
important to best understand the very beginnings of the
development - which is why I am posting these questions. Does
anyone have any further references that they could suggest? How
available are the early RFCs? Also, why were graduate students
picked to develop the earliest protocols for the ARPANET and not
BBN or other possibilities?

>   But we did come to one conclusion: We ought to meet again.
>   Over the next several months, we  managed to parlay that idea
>   into a series of exchange meetings at each of our sites,
>   thereby setting the most important precedent in protocol design.

What was the precedent? Was it the idea that protocol design is
best facilitated by meetings between various sites? Could
someone further explain this, as I want to understand the importance.

>   The first few meetings were quite tenuous.  We had no official
>   charter.  Most of us were graduate students and we expected that a
>   professional crew would show up eventually to take over the problems
>   we were dealing with.  Without clear definition of what the host-IMP
>   interface would look like, or even what functions the IMP would
>   provide, we focused on exotic ideas.  We envisioned the possibility

Ditto on my questioning how and why the Network Working Group was
organized and what their (the members of the NWG) expectations
were, and what ARPA's expectations were for the formation of the
group. Could anyone explain why no professional crew showed up?

[...deletion of DEL:Decode-Encode Lang. and NIL:Network Interchange Lang...]

>   In February of 1969 we met for the first time with BBN.  I don't
>   think any of us were prepared for that meeting.  The BBN folks, led
>   by Frank Heart, Bob Kahn, Severo Ornstein and Will Crowther, found
>   themselves talking to a crew of graduate students they hadn't
>   anticipated.  And we found ourselves talking to people whose first
>   concern was how to get bits to flow quickly and reliably but hadn't
>   -- of course -- spent any time considering the thirty or forty layers
>   of protocol above the link level.  And while BBN didn't take over the
>   protocol design process, we kept expecting that an official protocol
>   design team would announce itself.

Again - the question of what each groups (NWG, BBN) goals and
expectations are very fuzzy. Is there any way to stab into this
darkness to get a better understanding of how things were
operated and created to do all this? 

>   A month later, after a particularly delightful meeting in Utah, it
>   became clear to us that we had better start writing down our
>   discussions.  

Does anyone know which meeting this refers to and why it was
"particularly delightful"? It is important to note that as a
result of this meeting RFCs were developed, but the delight must
have the cause that made the creation of RFCs necessary.

[Continued in next message]
-- 
 | Michael Hauben    CC '95    |  E-mail me for sample copies of       |
 | hauben@cs.columbia.edu      |  The Amateur Computerist Newsletter   |
 | hauben@columbia.edu         | & read the alt.amateur-comp newsgroup |


-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 1993 18:05:54 -0500
From:      hauben@news.cs.columbia.edu (Michael Hauben)
To:        alt.culture.internet,comp.protocols.tcp-ip,comp.misc,alt.amateur-comp
Subject:   RFC1000 - Questions about the origins of ARPANET Protocols 2/2

			[ Part 2 of 2]


>   We had accumulated a few notes on the design of DEL and
>   other matters, and we decided to put them together in a set of notes.
>   I remember having great fear that we would offend whomever the
>   official protocol designers were, and I spent a sleepless night
>   composing humble words for our notes.  The basic ground rules were
>   that anyone could say anything and that nothing was official.  And to
>   emphasize the point, I labeled the notes "Request for Comments."  I
>   never dreamed these notes would distributed through the very medium
>   we were discussing in these notes.  Talk about Sorcerer's Apprentice!

The democratizing trend of the Networks seem to have had an
initiation in the creation of these notes where "anyone could say
anything and that nothing was official." This kind of historical
gem is what makes much of this history extremely fascinating.
But, is there also a technical necessity that initiated such
openness? 

	[...Material deleted...]

>  We also knew that we needed a more fundamental point of
>  view for building a larger array of protocols.  Unfortunately,

What does this mean?

>   operating systems of that era tended to view themselves as the center
>   of the universe; symmetric cooperation did not fit into the concepts
>   currently available within these operating systems.  And time was

This was a trend which those who wanted to combine/network
computers had to battle against - row against.

	[...Material deleted...]

>   At UCLA we scrambled to build a host-IMP interface.  SDS, the builder
>   of the Sigma 7, wanted many months and many dollars to do the job.
>   Mike Wingfield, another grad student at UCLA, stepped in and offered
>   to get interface built in six weeks for a few thousand dollars.  He
>   had a gorgeous, fully instrumented interface working in five and one
>   half weeks.  I was in charge of the software, and we were naturally

Interesting that grad student/s were able to offer a better job
than a commercial company.

	[...Material deleted...]

>   BBN fixed their timing trouble, air shipped the IMP, and it arrived
>   on our loading dock on Saturday, August 30.  They arrived with the
>   IMP, wheeled it into our computer room, plugged it in and the
>   software restarted from where it had been when the plug was pulled in
>   Cambridge.  Still Saturday, August 30.  Panic time at UCLA.
 
>   The second IMP was delivered to SRI at the beginning of October, and
>   ARPA's interest was intense.  Larry Roberts and Barry Wessler came by
>   for a visit on November 21, and we actually managed to demonstrate a
>   Telnet-like connection to SRI.
 
>   With the pressure to get something working and the general confusion
>   as to how to achieve the high generality we all aspired to, we punted
>   and defined the first set of protocols to include only Telnet and FTP
>   functions.  In particular, only asymmetric, user-server relationships
>   were supported.  

The first set of protocols defined.

>   In December 1969, we met with Larry Roberts in Utah,
>   and suffered our first direct experience with "redirection".  Larry
>   made it abundantly clear that our first step was not big enough, and
>   we went back to the drawing board.  Over the next few months we
>   designed a symmetric host-host protocol, and we defined an abstract
>   implementation of the protocol known as the Network Control Program.
>   ("NCP" later came to be used as the name for the protocol, but it
>   originally meant the program within the operating system that managed
>   connections.  The protocol itself was known blandly only as the
>   host-host protocol.)  Along with the basic host-host protocol, we
>   also envisioned a hierarchy of protocols, with Telnet, FTP and some
>   splinter protocols as the first examples.  If we had only consulted
>   the ancient mystics, we would have seen immediately that seven layers
>   were required.

Interesting that Larry Roberts stepped in and made it clearer
what was expected or necessary in the protocols. How did this
compare with previous meetings with various people other than the
immediate members of the NWG?

>   The initial experiment had been declared an immediate success and the
>   network continued to grow.  More and more people started coming to
>   meetings, and the Network Working Group began to take shape.  Working
>   Group meetings started to have 50 and 100 people in attendance
>   instead of the half dozen we had had in 1968 and early 1969.  We held
>   one meeting in conjunction with the Spring Joint Computer Conference
>   in Atlantic City in 1971.  In October 1971 we all convened at MIT for
>   a major protocol "fly-off".  Representatives from each site were on
>   hand, and everyone tried to log in to everyone else's site.  With the
>   exception of one site that was completely down, the matrix was almost
>   completely filled in, and we had reached a major milestone in
>   connectivity.

Was anyone present at this event? It sounded like an exciting
meeting to be a part of!

	[...Material deleted...]

>   Where will it end?  The network has the exceeded all estimates of its
>   growth.  It has been transformed, extended, cloned, renamed and
>   reimplemented.  I doubt if there is a single computer still on the
>   network that was on it in 1971.  But the RFCs march on.  Maybe I'll
>   write a few words for RFC 10,000.

The growth of the Net starting from the combination of the
ARPANET and eventually other networks around the world into a
Global Computer/Data Communications network is extremely exciting
and important. I intend to try and figure out the role that
TCP/IP has played in making such expansion possible - and if the
development of its predecesors and TCP/IPs (the suite's)  itself
has paved a way for what has happened at all.

Thank you for your time,
-Michael Hauben

-- 
 | Michael Hauben    CC '95    |  E-mail me for sample copies of       |
 | hauben@cs.columbia.edu      |  The Amateur Computerist Newsletter   |
 | hauben@columbia.edu         | & read the alt.amateur-comp newsgroup |


-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20 Nov 1993 17:51:59 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: Unreachable host ?

In article <2cgia3$iie@ucunix.san.uc.edu> daoad@ucunix.san.uc.edu (Andrew) writes:
>Hi,
>Please help!  I CAN NOT telnet or FTP to a remote host.
>The software we are using is DEC TCP/IP V2.0 runs under 
>VAX/VMS V5.5. I don't understand why I can loop (ping) to 
>this host but can not telnet to it.
>
>The message bellow I get when I try to loop to this host.
>------------------------------------------
>$ ucx loop elvis
>"icp --> icmp_type(3) != ICMP_ECHOREPLY (0)
>%UCX-I-LOOPACT, ELVIS is alive "
>-------------------------------------------
>
>But when I try to telnet to this node, I get the message bellow.
>
>---------------
>$ telnet elvis
>Trying...192.35.46.22
>%UCX-E-TELNET_CONECT, Failed to connect to remote host
>-SYSTEM-F-UNREACHABLE, remote node is not currently reachable."
>-----------------------------------------------------------------------

This kind of behavior is often seen when there are firewall filters
installed in a router in front of the target host.  Many sites
disallow connections for interactive protocols (e.g. telnet, rlogin)
to most or all hosts inside their networks.

Art


-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 93 17:22:28 PST
From:      mlyle@hotcity.COM (Michael Lyle)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP over T1 in Bay Area.

If I wished to hook up my Sun Sparcstation to the Internet via TCP-IP T1, how
much would a provider cost in the San Francisco Bay Area? The line? What about
the costs for ISDN? A reply to this would be greatly appreciated. Thank you,

               Michael Lyle
--
Michael Lyle      | <Insert Nice Quote Here>
mlyle@hotcity.com | Hey, so what if it's a short sig?!

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 93 11:04:37 GMT
From:      phone@cairo.anu.edu.au (matthew green)
To:        comp.protocols.tcp-ip
Subject:   emulating socketpair() on interactive 3.0



hi,

i'm wondering if anyone has code to emulate socketpair() under
intercraptive unix 3.0.

thanks,
.mrg.

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21 Nov 1993 11:42:32 +0000
From:      mark@kram.org (Mark Turner)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: WORKING version of KA9Q with PPP support STILL in it.

In article <davidh.753635107@azurite> davidh@azurite.use.com (David Holland) writes:
> 
> Can anyone tell me where to find a working version of KA9Q?

Our version (Demon Internet) still has PPP, has a much improved
dialer, and some quenching code which should help you.

ftp.demon.co.uk:/pub/ibmpc/DIS/ka9q212.* (or something very like that)

Regards,

Mark.
-- 
/\/\ark Turner                       Demon Systems / Demon Internet
Home: mt@kram.org (PGP key available)        42 Hendon Lane, London
Office: mark@demon.net (+44 81 3490063)             N3 1TT, England
*** IP level dialup Internet connectivity for a tenner a month! ***

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 1993 00:43 MST
From:      gavron@spades.aces.com (Ehud Gavron)
To:        comp.protocols.tcp-ip
Subject:   Re: Upgrade from 14.4 SLIP to 56K - question

In article <margueriCGvL8C.MwD@netcom.com>, margueri@netcom.com (Dave Correia) writes...
# 
# 
#I am looking into upgrading the connection to our Internet provider
#(netcom) from dedicated 14.4kb SLIP to 56k digital. 
#Right now telnet performance across this SLIP link is pretty poor, 
#with sometimes a 3-5 second intercharacter delay. (This is telnet
#to netcom across the SLIP link; direct dialin to either side is snappy.)
# 
#So my question is: How do I estimate the performance improvement 
#gained upgrading from 14.4kb SLIP to 56K digital? 
# 
#Currently in use: Telebit 3000 modem, portmaster, SLIP.
#Proposed: CSU/DSU, 56k Digital line, router.
#Simple math would indicate a 4x improvement -- How do I factor
#in analog vs digital, SLIP vs (??), etc?
# 

Average latency 56bytes SLIP 14.4K: 240-280ms
			DDS  56K:    60ms

#Any help or advice would be greatly appreciated.

I sell 56K connectivity in Tucson, and let me tell you, it's
significantly better... and for only 3x the cost of 14.4K,
I don't know why everyone doesn't do it...


Ehud

--
Ehud Gavron        (EG76)     
gavron@aces.com

For info on aces connections send mail to  INFO@ACES.COM 
with the subject line SLIP.

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21 Nov 1993 19:09:53 GMT
From:      rap@syscen.com (Ross Patterson)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   "large security gap in the Internet"

The following is an excerpt from EDUPAGE, a periodic newsletter from Educom.
Each issue contains a bunch of one-paragraph summaries of recent articles,
etc. of interest to higher-education networking folks.  This past week's
issue includes a reference to a "large security gap in the Internet",
courtesy of the Chronicle of Higher Education.  I doubt any such "large"
problem existed, with the possible exception of the usual sendmail exposures,
but does anyone have better information?

In short, "What gives?"

Ross Patterson
Sterling Software, Inc.
VM Software Division

----- Forwarded message begins here -----
From: EDUPAGE Newsletter  <edupage@IVORY.EDUCOM.EDU>
Thu, 18 Nov 1993 11:04:58 -0500
To:           Multiple recipients of list EDUPAGE <EDUPAGE@BITNIC.EDUCOM.EDU>
Subject: E-D-U-P-A-G-E 11/18/93 (fwd)

EDUPAGE. This is Edupage, a twice-weekly summary of news items on
information technology. It is provided as a service by EDUCOM -- a
consortium of leading colleges and universities seeking to transform
education through the use of information technology.

...

HOLE IN THE NET.  Network experts have repaired a large security gap in the
Internet, ending several weeks of tension during which system
administrators feared that malicious computer users might be able to shut
down the entire network. (Chronicle of Higher Education 11/17/93 A26)

...

EDUPAGE. For free subscription to Edupage, our electronic news service,
send e-mail to listserv@bitnic.educom.edu, containing the following text:
SUB EDUPAGE yourfirstname yourlastname. To unsubscribe, send e-mail
containing the text: UNSUB EDUPAGE. To send comments about Edupage, send
mail to comments@educom.edu. Back issues of Edupage are available by WAIS,
Gopher, and anonymous ftp from educom.edu.

************************************************************************
EDUCOM  --  Transforming Education Through Information Technology
************************************************************************
------ Forwarded message ends here ------

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21 Nov 1993 20:42:00 GMT
From:      Graham Toal <gtoal@gtoal.com>
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: "large security gap in the Internet"

In article <CGuvwH.5q4@syscen.com> rap@syscen.com (Ross Patterson) writes:
:The following is an excerpt from EDUPAGE, a periodic newsletter from Educom.
:Each issue contains a bunch of one-paragraph summaries of recent articles,
:etc. of interest to higher-education networking folks.  This past week's
:issue includes a reference to a "large security gap in the Internet",
:courtesy of the Chronicle of Higher Education.  I doubt any such "large"
:problem existed, with the possible exception of the usual sendmail exposures,
:but does anyone have better information?
:
:In short, "What gives?"

It's an *extremely* badly reported piece about the sendmail holes that
almost every unix installation has.  And it certainly *hasn't* been fixed;
yes, a fixed version of sendmail exists, but it's up to the admins of
every single site on the net to upgrade their programs, and it just
ain't going to happen how we have so many weekend drivers on the net.

G
(Here's the CERT announcement for those who missed it; also you should
read comp.security.{misc,unix} for postings by various admins pointing
out shortcomings in the CERT advice and how to improve it)

>From demon!pipex!uunet!nntp.club.cc.cmu.edu!news.sei.cmu.edu!cert.org!cert Fri Nov  5 16:22:35 GMT 1993
Article: 4171 of comp.security.misc
Xref: demon alt.security:4295 comp.security.misc:4171 comp.unix.admin:7182 comp.mail.sendmail:3085
Newsgroups: alt.security,comp.security.misc,comp.unix.admin,comp.mail.sendmail
Path: demon!pipex!uunet!nntp.club.cc.cmu.edu!news.sei.cmu.edu!cert.org!cert
From: cert@cert.org (CERT Coordination Center)
Subject: CERT Advisory - Sendmail Vulnerability
Message-ID: <1993Nov4.222156.12805@sei.cmu.edu>
Followup-To: cert@cert.org
Keywords: CA-93:16.sendmail.vulnerabilty
Sender: cert@cert.org
Reply-To: cert@cert.org
Organization: CERT Coordination Center
Date: Thu, 4 Nov 1993 22:21:56 EST
Lines: 272
Status: RO


=============================================================================
CA-93:16                         CERT Advisory
                               November 4, 1993
                             Sendmail Vulnerability
-----------------------------------------------------------------------------
The CERT Coordination Center is working on eliminating a vulnerability in 
sendmail(8). This vulnerability potentially affects all systems running 
sendmail. 

CERT is working with the vendor community to address this vulnerability.  At 
this time, there are no known patches available for any vendor implementation 
that fully address this vulnerability.  Until there is complete vendor 
information, CERT recommends that all implementations of sendmail be 
considered susceptible.

This advisory supersedes the sendmail portion of the CERT advisory (CA-93:15) 
of October 21, 1993.

CERT will continue to work with the vendors and will alert the community
when patches become available.

Included with this advisory is an appendix describing tips that can be used 
by system administrators who are concerned about the possible exploitation 
of this vulnerability at their site.

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

I.   Description

     A vulnerability exists in most versions of sendmail that allows
     unauthorized remote or local users to execute programs as any system
     user other than root.

     This vulnerability affects the final destination sendmail host
     and can be exploited through an intermediate mail machine.  Therefore,
     all sendmail recipient machines within a domain are potentially 
     vulnerable.


II.  Impact
     
     Anyone (remote or local) can execute programs on the affected hosts
     as any userid other than root.


III. Approaches

     CERT suggests three possible approaches to this problem.  Although
     these approaches address all known aspects of this vulnerability,
     they are suggested only until vendor patches for this sendmail
     vulnerability are available.

     Familiarity with sendmail and its installation and configuration,
     is recommended before implementing these modifications.
  
     In order to protect your entire site it is necessary to apply the selected
     approach to *ALL* systems running sendmail at the site, and not just 
     the mail hub.

     A.  Approach 1

         This approach involves modifying the sendmail configuration
         to restrict the sendmail program mailer facility.
 
         To restrict sendmail's program mailer facility, obtain
         and install the sendmail restricted shell program (smrsh 1.2) 
         by Eric Allman (the original author of sendmail), following the 
         directions included with the program. 
  
         1.  Where to obtain the program
  
             Copies of this program may be obtained via anonymous FTP from
             info.cert.org, in the /pub/tools/smrsh directory, or via 
             anonymous FTP from ftp.uu.net in the /pub/security/smrsh
             directory.

             Checksum information:

                               BSD Sum
             30114 5 README
             25757 2 smrsh.8
             46786 5 smrsh.c

                             System V Sum
             56478 10 README
             42281 4 smrsh.8
             65517 9 smrsh.c

                             MD5 Checksum
             MD5 (README) = fc4cf266288511099e44b664806a5594
             MD5 (smrsh.8) = 35aeefba9714f251a3610c7b1714e355
             MD5 (smrsh.c) = d4822ce7c273fc8b93c68e39ec67739c


         2.  Impacts of this approach 
  
             While this approach allows a site to specify which programs
             can be run by sendmail (e.g. vacation(1)), attempts to invoke 
             programs that are not included in the allowed set, or attempts
             using shell meta-characters (see smrsh program listing for a 
             complete set of disallowed characters), will fail, resulting in 
             log output to the syslog(3) facility.  Programs that are specified 
             in a site's /etc/aliases file should be considered for inclusion 
             in the allowable program list.
  
             Since .forward files allow user-specified programs to be 
             run by sendmail, a survey of the contents of the system's 
             .forward files may be required to prevent failure to deliver
             user mail.
  
             *** WARNING ***************************************************
             * It is very important that sites *NOT* include interpreter   * 
             * programs (e.g. /bin/sh, /bin/csh, /bin/perl, /bin/uudecode, *
             * /bin/sed, ...) in the list of allowed programs.             *
             ***************************************************************

     B.  Approach 2

         Like approach 1, this approach involves modifying the sendmail
         configuration.  However, this approach completely disables the 
         sendmail program mailer facility.  This is a drastic, but quick 
         action that can be taken while a site installs one of the
         other suggestions.  Before implementing this approach, save a copy
         of the current sendmail configuration file.

         To implement this approach edit the sendmail.cf file:
 
         change from:
         Mprog,  P=/bin/sh,      F=slFDM,        S=10,   R=20,   A=sh -c $u

         to:
         Mprog, P=/bin/false,    F=,     S=10,   R=20,   A=

         Any changes to the sendmail.cf file will require that the 
         sendmail process be restarted to ensure that the new configuration
         is used. See item 3 in Appendix A for more details.

         1.  Impacts of this approach

             Attempts to invoke programs through sendmail will not
             be successful.

     C.  Approach 3

         To the best of our knowledge, Eric Allman's public domain 
         implementation of sendmail, sendmail 8.6.4, does not appear to
         be susceptible to this vulnerability.  A working solution would 
         then be to replace a site's sendmail, with sendmail 8.6.4.

         1.  Where to obtain the program

             Copies of this version of sendmail may be obtained via
             anonymous FTP from ftp.cs.berkeley.edu in the 
             /ucb/sendmail directory.

             Checksum information:

                                BSD Sum 
             sendmail.8.6.4.base.tar.Z:      07718 428
             sendmail.8.6.4.cf.tar.Z:        28004 179
             sendmail.8.6.4.misc.tar.Z:      57299 102
             sendmail.8.6.4.xdoc.tar.Z:      33954 251

                             System V Sum
             64609 856 sendmail.8.6.4.base.tar.Z
             42112 357 sendmail.8.6.4.cf.tar.Z
             8101 203 sendmail.8.6.4.misc.tar.Z
             50037 502 sendmail.8.6.4.xdoc.tar.Z

                             MD5 Checksum
             MD5 (sendmail.8.6.4.base.tar.Z) = 59727f2f99b0e47a74d804f7ff654621
             MD5 (sendmail.8.6.4.cf.tar.Z) = cb7ab7751fb8b45167758e9485878f6f
             MD5 (sendmail.8.6.4.misc.tar.Z) = 8eaa6fbe9e9226667f719af0c1bde755
             MD5 (sendmail.8.6.4.xdoc.tar.Z) = a9da24e504832f21a3069dc2151870e6


         2.  Impacts of this workaround

             Depending upon the currently installed sendmail program, 
             switching to a different sendmail may require significant 
             effort for the system administrator to become familiar with 
             the new program.  The site's sendmail configuration file 
             may require considerable modification in order to provide 
             existing functionality. In some cases, the site's sendmail 
             configuration file may be incompatible with the sendmail 8.6.4 
             configuration file.


---------------------------------------------------------------------------
The CERT Coordination Center wishes to thank the members of the following
response teams for their assistance in analyzing and testing both the 
problem and the solutions: SERT, ASSIST, CIAC, and DFN-CERT.  CERT would
especially like to thank Eric Allman, Matt Blaze, Andy Sherman, Gene Spafford,
Tim Seaver, and many others who have provided technical assistance with 
this effort.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in Forum of Incident
Response and Security Teams (FIRST).

Internet E-mail: cert@cert.org
Telephone: 412-268-7090 (24-hour hotline)
           CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4),
           and are on call for emergencies during other hours.

CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available via anonymous FTP
from info.cert.org.

 

Appendix A

This appendix describes tips that can be used by system administrators
who are concerned about the possible exploitation of this vulnerability at 
their site.


There are two actions that can be taken by system administrators to try
to detect the exploitation of this vulnerability at their sites. 

  - Examine all bounced mail to look for unusual occurrences.
  - Examine syslog files for unusual occurrences of "|" characters

In order to do this, sendmail must be configured to direct bounced mail to 
the postmaster (or other designated person who will examine the bounced mail). 
Sendmail must also be configured to provide adequate logging.  

1)  To direct bounced mail to the postmaster, place the following entry in 
    the options part of the general configuration information section of 
    the sendmail.cf file. 

    # Cc my postmaster on error replies I generate
    OPpostmaster

2)  To set sendmail's logging level, place the following entry in the options 
    part of the general configuration information section of the sendmail.cf 
    file. Note that the logging level should be 9 or higher in order to provide
    adequate logging.
 
    # log level
    OL9

3)  Once changes have been made in the sendmail configuration file,
    it will be necessary to kill all existing sendmail processes,
    refreeze the configuration file (if needed - see the note below), 
    and restart the sendmail program.

    Here is an example from SunOS 4.1.2:

    As root:

    # /usr/bin/ps -aux | /usr/bin/grep sendmail
    root 130  0.0  0.0  168    0 ?  IW   Oct  2  0:10 /usr/lib/sendmail -bd -q
    # /bin/kill -9 130                (kill the current sendmail process)
    # /usr/lib/sendmail -bz           (create the configuration freeze file)
    # /usr/lib/sendmail -bd -q30m     (run the sendmail daemon)


**Note: Some sites do not use frozen configuration files and some do. If
  your site is using frozen configuration files, there will be a file
  named sendmail.fc in the same directory as the sendmail configuration
  file (sendmail.cf). 

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Nov 1993 04:16:59 GMT
From:      margueri@netcom.com (Dave Correia)
To:        comp.protocols.tcp-ip
Subject:   Upgrade from 14.4 SLIP to 56K - question



I am looking into upgrading the connection to our Internet provider
(netcom) from dedicated 14.4kb SLIP to 56k digital. 
Right now telnet performance across this SLIP link is pretty poor, 
with sometimes a 3-5 second intercharacter delay. (This is telnet
to netcom across the SLIP link; direct dialin to either side is snappy.)

So my question is: How do I estimate the performance improvement 
gained upgrading from 14.4kb SLIP to 56K digital? 

Currently in use: Telebit 3000 modem, portmaster, SLIP.
Proposed: CSU/DSU, 56k Digital line, router.
Simple math would indicate a 4x improvement -- How do I factor
in analog vs digital, SLIP vs (??), etc?

Any help or advice would be greatly appreciated.


-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 1993 05:37:29 GMT
From:      NC6967@CONRAD.APPSTATE.EDU (Nathan Clark)
To:        comp.protocols.tcp-ip
Subject:   MS-DOS Telnet in?

I'm looking to set up an MSDOS based BBS on the internet.  I'm using a 486 with 
an E2000 Ethernet card.  I'm wondering what sort of software I need to allow 
users to telnet in and run the BBS.  I'm directly connected to our campus 
network.  We guess our problem is getting BBS software to recognize incoming 
calls on the Ethernet card.  Are there any BBS packages suited to this?

Thank you,

NC6967@conrad.appstate.edu


-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 93 05:55:30 GMT
From:      libes@cme.nist.gov (Don Libes)
To:        comp.client-server,comp.protocols.tcp-ip
Subject:   Re: Help! Non-interactive file transfer

In article <lp0bd1m@sgi.sgi.com> rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:
>g552536@kirk.lasc.lockheed.com writes:
 
>| I am interested in non-interactive file transfer...
>| wondering if there is a standard for non-interactive file transfer
>| or a library interface to third party ftp packages...
>| My goal is file transfer initiated automaticaly from a controlling
>| remote program....
 
>The easiest thing is probably just to get the source for "ftp" and hack...

It's easier just to use the Expect library which comes with Expect.
It lets you automate ftp and many other programs.  It comes with:

- popen that works in two directions
- smart read in which you can describe what you're interested in via
	glob patterns, regexp patterns, or a timeout period.

>I wish I could point you to a free source somewhere, but as I said,

And it's in the public domain.

Don Libes
libes@nist.gov

To get Expect, email "send pub/expect/alpha.tar.Z" to
library@cme.nist.gov or anonymous ftp same from ftp.cme.nist.gov.

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Nov 1993 08:37:00 GMT
From:      GERTHD@MVS.sas.com (Herbert Kinzler)
To:        comp.protocols.tcp-ip
Subject:   Info about TCP-IP performance

 
Hi,
I would like to get some information about performance
of TCP-IP connections between MVS hosts and PC's under
Microsoft Windows.
Please post information to email address GERHEK@MVS.SAS.COM
Regards, 
Herbert
--
Herbert Kinzler
Technical Support
SAS Institute GmbH       P. O. Box 10 53 07, D-69043 Heidelberg, Germany
gerhek@mvs.sas.com       Tel: +49 6221 4150  Fax: +49 6221 415101

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 1993 10:54:42 GMT
From:      krell@bonsai.fernuni-hagen.de (Christoph Krell)
To:        comp.protocols.tcp-ip
Subject:   WANTED: FAQ

I have heard of a FAQ relating to this discussion group.

Can anyone tell me where I cah get it ?

Christoph Krell
FernUniversitaet Hagen
AB Kommunikationssysteme  


-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Nov 1993 14:51:55 GMT
From:      sater@cs.vu.nl (Hans van Staveren)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip,comp.dcom.lans.fddi
Subject:   Sun TCP lockup with FDDI

We have encountered a problem with Sun TCP over FDDI. The FDDI boards
are from Interphase, the 4611 SBus card. We are running with an increased
tcp_sendspace and tcp_recvspace. Both 32K and 24K have been tested.

The symptom is that doing a large remote dump(VIII) over FDDI the
sender(dump)'s buffer is full, the receiver(rmt)'s buffer is empty,
and the tcp's at both side are sending each other packets with mismatching
sequence numbers and no data gets through anymore.

The MTU of the FDDI boards is set to 4352, as normal. When doing exactly
the same dump over the parallel ethernet everyting works like a charm
with the same tcp_{send,recv}space. NFS over UDP on the same FDDI ring
works perfectly.

It definitely does not look like a FDDIdriver problem, but more like
a generic TCP problem that happens to surface because of the larger
FDDI MTU.

Does this sound familiar? Is there a patch?

	Hans van Staveren
	Vrije Universiteit
	Amsterdam, Holland

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Nov 1993 17:45:00 GMT
From:      kudzu@netcom.com (Michael Sierchio)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: "large security gap in the Internet"

In article <august-221193074523@august.cerfnet.com> 
    august@cerfnet.com (Richard B. August) writes:

>The name VIRUS connotes something that is ALIVE rather than what a computer
>"virus" really is.  The average lay person has absolutely NO CLUE as to
>what a "computer virus" is or might be.
>

Nobody's definition of a virus says it's alive -- viruses contain DNA
(or RNA) and require a living host -- they have some, but not all
of the necessary characteristics for life.
>
>Remember who it was who was last in-charge of the security program for
>UNIX.  Many people on the net might remember him ROBERT MORRIS, JR.

Not Robert Tappan Morris, his son -- "...of what you know, speak."
-- 
A man sometimes devotes his life to a desire which he is not sure will ever be
fulfilled.  Those who laugh at this folly are, after all, no more than mere
spectators of life.
                                                   - Ryunosuke Akutagawa

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Nov 1993 18:32:31 GMT
From:      mturc@berlioz.nsc.com (Moe Turcotte)
To:        comp.protocols.tcp-ip
Subject:   Re: Fragmentation & Reassembly

In article <CGru39.Br8@cup.hp.com> mintz@cup.hp.com (Ken Mintz) writes:
>Moe Turcotte (mturc@berlioz.nsc.com) writes:
>> Our monitoring of random internet traffic has failed to produce a single
>> fragmented packet. Even though we are sending FTP traffic accross an X.25
>> link.
>
>  That's because TCP (which FTP uses) reduces its packet size to avoid
>  IP fragmentation.
>
>  UDP (which NFS uses) does not do that.  If you set the wsize and rsize
>  for NFS about the MTU, you will see lots of fragmentation.
>
>> Will a host that does not do reassembly fail miserably on the internet, or
>> will it fail to talk to some small percentage of hosts?
>
>  Generally, it will fail miserably.  Even though a TCP will try to 
>  avoid IP fragmentation, it might not have the right picture of the
>  "connection" MTU.
>
>  Most TCPs only know the MTU for the directly-connected network.  When
>  the packet is transmitted through many gateways, fragmentation becomes
>  more likely.
>
>  The receiving host must be able to reassemble the fragments.
>
>-- Ken Mintz

The application is SNMP only. Is reassembly still necessary?

mrt


-- 
 Maurice R. Turcotte            Staff Software Engineer
 mturc@atlanta.nsc.com          National Semiconductor 
 Ph:  (404) 903-1886            500 Pinnacle Court, Suite 525 
 Fax: (404) 903-1827            Norcross, GA 30071 

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 1993 20:26:51 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP is *really* your friend

In article <CGpJ94.4wA@aston.ac.uk>,
Mark Evans <evansmp@mb48059.aston.ac.uk> wrote:
>It just means that there is only one central place where mistakes can
>be made. Thus hopefully it will be easier if fault finding is needed.

In my experience it really does help.  It reduces the number of
configuration errors, and it makes it easier to find mistakes like
duplicate IP address assignments.

      Stephen

-- 
Stephen Trier  KB8PWA       "The light at the end of the tunnel
Work: trier@ins.cwru.edu     may be an oncoming dragon"
Home: sct@po.cwru.edu                          - Unknown

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 1993 22:15:51 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Socket Read Error 54

In article <1993Nov15.183103.4936@progress.com> chandler@chatham.progress.com (Peter Chandler) writes:
>#define ECONNRESET      54              /* Connection reset by peer */
>
>Can anyone provide additional information on this error?
>The cause?  Any type on recover/retries to complete the read?

It means that the other side has aborted the connection.  It could also
indicate that the other system crashed before you sent your last packet,
and has now rebooted; the reset is a response to a retransmission of the
packet from the old connection.

In either case, there's no way to recover.  The connection you were using
is gone, so there's nothing to read.  You could try to reconnect to the
server and start over.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 1993 22:25:17 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Can UDP with with only one way link between 2 machines?

In article <GTHAKER.93Nov16120504@trantor.atl.ge.com> gthaker@atl.ge.com (Gautam H. Thaker) writes:
>We wish to connect two computer that are several thousand miles 
>apart via a oneway satellite connection. We wish to transmit data
>from machine A->B via UDP datagrams. We can't send any bytes back
>from B to A. We can live with unreliability etc. 
>
>Please excuse this novice questions. can IP/UDP work under
>these conditions?

Yes, UDP can work this way.  Every UDP datagram is independent, so there's
no built-in need for a response at the UDP layer.  Any query/response
behavior must be defined at the application level.  Protocols like RIP and
NTP can be used in one-way networks, for instance (you can't use all the
features of the protocols, since they include query operations, but they
have usable subsets where a master simply transmits to slaves).

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Nov 93 23:44:54 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   RE: TCI/IP vs OSI comparison book

In Article <id.0SH41.AIH@nmti.com>
ihsan@nmti.com (jaleel ihsan) writes:

>There is book favourably comparing TCP/IP against ISO protocols (some
>people have accused the author of being opinionated !).  Could some one
>please provide me with information regarding this book.

You may be looking for "The Open Book" by Dr. Marshall T. Rose. Dr. Rose is
very opinionated, but he clearly marks the parts of the book that are linked to
his opinions. He refers to these as "soapbox" sections.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov		(510) 422-6955

Disclaimer: Being a know-it-all isn't easy. It's especially tough when you
don't know that much. But I'll keep trying. (Both)

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Nov 1993 23:46:17 GMT
From:      rsi@netcom.com (Rajappa Iyer)
To:        comp.protocols.tcp-ip
Subject:   Re: TCI/IP vs OSI comparison book

In <id.0SH41.AIH@nmti.com> ihsan@nmti.com (jaleel ihsan) writes:

>There is book favourably comparing TCP/IP against ISO protocols (some
>people have accused the author of being opinionated !).  Could some one
>please provide me with information regarding this book.

I'd bet high on it being:

Marshall T. Rose: "The Open Book. (A Practical Perspective on OSI)"
Prentice Hall, NJ 1989
ISBN 0-13-643016-3
-- 
Rajappa Iyer <rsi@netcom.com> La Jolla, CA. (619) 457-7509
	They also surf who only stand on waves.

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Nov 1993 00:12:17 GMT
From:      A.L.Radtke@bradford.ac.uk (Drew Radtke)
To:        comp.protocols.tcp-ip
Subject:   PC FTP client that does it all automatically

Hi all. I'm looking for an FTP client for a PC connected to unix
using TCP-IP which, once it has had various parameters loaded
into some peferences file, can just pull a load of files from the
unix system to the PC hard disk.

I want it to do this at a certain time when the PC is unattended;
I can obviously write a little routine which runs a DOS batch
file which will run the FTP program; I've never seen an FTP
client which you could program to work unattended though. There
must be one!?

Thanks for any help!
-- 
Drew Radtke - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Nov 1993 01:13:23 GMT
From:      rwpratt@novell.com (Robert Pratt)
To:        comp.protocols.tcp-ip
Subject:   Re: TCI/IP vs OSI comparison book

In article <rsiCGx3D5.7Go@netcom.com> rsi@netcom.com (Rajappa Iyer) writes:
>In <id.0SH41.AIH@nmti.com> ihsan@nmti.com (jaleel ihsan) writes:
>
>>There is book favourably comparing TCP/IP against ISO protocols (some
>>people have accused the author of being opinionated !).  Could some one
>>please provide me with information regarding this book.
>
>I'd bet high on it being:
>
>Marshall T. Rose: "The Open Book. (A Practical Perspective on OSI)"
>Prentice Hall, NJ 1989
>ISBN 0-13-643016-3
>-- 
>Rajappa Iyer <rsi@netcom.com> La Jolla, CA. (619) 457-7509
>	They also surf who only stand on waves.

  Another possibility is "The Elements of Networking Style" by M.A. Padlipsky.
I agree that Rose's book is most likely what the original poster had in mind,
but Padlipsky's book also fits the description to a T.  Much easier
reading than The Open Book, and not the same technical level, but
a great deal of fun.
  (God, I feel like a geek for calling a technical essay collection fun!)

Bob
Bob Pratt                               | voice     : (408) 473-8274
Novell, Inc.                            | Fax       : (408) 435-1706
2180 Fortune Drive, San Jose, Ca. 95131 | Internet  : rpratt@Novell.com
Disclaimer:  I do not speak for Novell in any way, shape, or form.
"Cuius testiculos habes, habeas cardia et cerebellum."
        -- (Terry Pratchett, Small Gods)

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 93 09:28:35 MDT
From:      jed@skyler.arc.ab.ca (Jed Sutherland)
To:        comp.protocols.tcp-ip
Subject:   TLI

Could anyone out there tell me how to get ahold of the Transport Layer
Interface (TLI) specification? Thanks in advance.
 

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 1993 03:51:37 GMT
From:      jweiss@casbah.acns.nwu.edu (Jerry Weiss)
To:        comp.protocols.tcp-ip
Subject:   Reliable Sockets

Could someone tell me what Reliable Sockets are, or point me to
a book or reference.

TIA


-- 
Jerry S. Weiss
j-weiss@nwu.edu
Dept. Medicine, Northwestern Univ. Medical School, Chicago, Illinois
%SYSTEM-S-PHALOKTARG,  Phasers Locked on Target, Ready to Fire

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Nov 1993 05:28:49 GMT
From:      mty@ntuix.ntu.ac.sg (Yap Ma Tit)
To:        comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   TCP/IP over ATM

What parameters of TCP are tunable?
e.g. sliding window size (how?)

We have got an ATM switch, but we can
only get 14 Mbps out of the raw bandwidth
of 100 Mbps!

Thanks

Yap



-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Nov 1993 05:40:30 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans.ethernet
Subject:   pktd11/pktd11a/pktd11b.zip - Crynwr v11.x packet drivers

I have uploaded to the SimTel Software Repository, available by anonymous
ftp from the primary mirror site OAK.Oakland.Edu (141.210.10.117) and its
mirrors:

pub/msdos/pktdrvr/
pktd11.zip      Crynwr v11.x packet drivers executables & docs
pktd11a.zip     Crynwr v11.x packet drivers source, part 1of2
pktd11b.zip     Crynwr v11.x packet drivers source, part 2of2

The packet drivers are for PC's running MS-DOS.  They hide the
differences between Ethernet cards, and allow multiple protocols to
have simultaneous access to the same card.  Benefits of the Crynwr
Packet Drivers over competing drivers:

  o One stop shopping.  Collection includes drivers for most popular cards.
  o Small memory footprint.
  o Supported by many commercial and freely-copyable packages.
  o Source for all drivers is always available.
  o Support is available for a fee.
  o Programming specification is included.
  o Sample source code is included.

The Crynwr Packet Driver Collection contains the same software as the
former Clarkson Packet Driver Collection.  Crynwr Software owns the
copyright.  The permissions on the copyright remain the same.  Clarkson
is out of the packet driver business.

Summary of changes in the 11.x release:

        New drivers: Aquila, Kodiak, Eagle NE2100 (&NE1500), Exos 205T
                Thomas-Conrad TC5045, Parallel port to Parallel port,
                Ottawa PI, Vaxmate, Racal-Datacomm es3210, 3Com
                EtherLink III, SMC (formerly Western Digital)/IBM
                Ethernet/A, Zenith Z-Note, Cabletron DNI Exxxx and Mylex.
        New utility: pktwatch.
        New switches added (-p to disable promiscuous mode, -u to
                uninstall, -i to select class 11 if available).
        Intel Netware driver (PDIPX) is now included.
        Bug fixes in all drivers, including the key/mouse lossage for 8390-
                using drivers (ne1/2000, smc_wd, hppclan, 3c503).
        Parameters changed: 3c503, 3c505, 3c507, winpkt

Uploaded by the author.

The 11.x packet driver release obsoletes the following files:
3c509a.zip, at1500.zip, at1700.zip, drivers.zip, drivers1.zip,
drivers2.zip, drivers3.zip, exp16104.zip, and znote.zip.

- -
-russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support.
11 Grant St.      | 315-268-1925 (-9201 FAX)       | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Nov 1993 08:37:32
From:      loss@husky.bloomu.edu (Doug Loss)
To:        comp.protocols.tcp-ip
Subject:   Re: PC FTP client that does it all automatically

In article <1993Nov23.001217.7477@bradford.ac.uk> A.L.Radtke@bradford.ac.uk (Drew Radtke) writes:
>From: A.L.Radtke@bradford.ac.uk (Drew Radtke)
>Subject: PC FTP client that does it all automatically
>Date: Tue, 23 Nov 1993 00:12:17 GMT
 
>Hi all. I'm looking for an FTP client for a PC connected to unix
>using TCP-IP which, once it has had various parameters loaded
>into some peferences file, can just pull a load of files from the
>unix system to the PC hard disk.
 
>I want it to do this at a certain time when the PC is unattended;
>I can obviously write a little routine which runs a DOS batch
>file which will run the FTP program; I've never seen an FTP
>client which you could program to work unattended though. There
>must be one!?
 
>Thanks for any help!>-- >Drew Radtke - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - -

Drew, lots of FTP clients can do this.  I've done just what you're asking 
about with the FTP clients from NCSA Telnet and FTP Software's PC/TCP.  You 
just load your commands and responses to prompts in a text file, one 
command/response per line, and then redirect input to the FTP client from this 
text file rather than the keyboard.  If you'd like, e-mail me privately and 
I'll send you the command files we use here at Bloomsburg for a simple 
class-list download.


Doug Loss                        A crisis is when you can't say,
Data Network Coordinator         "Let's forget the whole thing."
Bloomsburg University
loss@husky.bloomu.edu
Voice (717) 389-4797

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Nov 1993 08:20:33 GMT
From:      ericd@gaudi.CSUFresno.EDU (Eric Douglas)
To:        comp.protocols.tcp-ip
Subject:   Location (online) of R.T. Morris paper


Does anyone know where I might find a copy of `A Weakness
in the 4.2BSD Unix TCP/IP Software', by R.T. Morris? Is there
a copy located online?

Any help/references greatly appreciated.

Thanks,
--eric

--
------------------------------------------------------------------------------
Eric W. Douglas                                  |  eric_douglas@csufresno.edu
California State University, Fresno              |                            
Computing, Communications, and Media Services    |             +1 209 278 3923

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Nov 1993 09:45:01 GMT
From:      geraldy@netcom.com (Gerald Yu)
To:        comp.protocols.tcp-ip
Subject:   Re: Fragmentation & Reassembly

If a packet arriving at the destination has a re-assembled length
greater than the destination network's MTU, then the packet will
be discarded, correct?  What other process is involved?  

Thanks.


Gerald

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 1993 10:12:17 GMT
From:      gb150@vax35.hrz.uni-siegen.de (Carsten Stolz)
To:        comp.os.linux.help,comp.protocols.tcp-ip,comp.sys.novell
Subject:   Linux and Novell Netware v.3.11

Hello,
I have some problems with my Linux and a Novell Netware Server v.3.11.
The Novell-Server is a IP GATEWAY with the following configuration:
    load 3c509 slot=6 frame=ethernet_II name=DOSIP
    load 3c509 slot=7 frame=ethernet_II name=HRZIP

    LOAD tcpip forward=yes
    BIND IP to DOSIP addr=141.99.24.180 netmask=255.255.252.0
    BIND IP to HRZIP addr=141.99.56.180 netmask=255.255.252.0

Version of TCPIP.NLM is 2.02j.
All work fine, but ...

My Linux is 141.99.24.181 with a 3C503. 

    1. Problem: ROUTE works very slow. ROUTE -n works ok.

    2. Problem: PING 141.99.56.180 is alive.
                PING 141.99.24.180 -nothing-

                IFCONFIG eth0 141.99.24.181 netmask=255.255.252.0 and
                ROUTED. 
                PING 141.99.24.101 is alive.
                ROUTE ADD 141.99.24.0 gw 141.99.24.181
                ROUTE ADD default gw 141.99.24.180

Thanks for your support,
Carsten.


Please post, do not REPLY-TO. My Mail System is down !!!
--
Carsten Stolz, Wittgensteiner Strasse 63, D-57072 Siegen
    Universitaet Siegen, FTS, D-57068 Siegen  Stolz@server.fts.uni-siegen.De
-------------------------------------------------------------------------------
Children are natural mimics who act like their parents despite every effort to
                        teach them good manners.

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Nov 93 15:45:13 EST
From:      macico@syr.edu (Michael A. Cico)
To:        comp.protocols.tcp-ip
Subject:   buffered pipe protocol (BPP) and sockets

Has anyone out there heard of a "buffered-pipe" protocol?  If so, I'm
trying to find any texts regarding this, in addition to a good text on
the socket communications (not necessarily Unix sockets, but the
concept in general).

Thanks,

Mike cico


--
****************************************************************************
* Mike Cico                                 |                               
* 867 Ackerman Ave.                         |    macico@mailbox.syr.edu     
* Syracuse, NY 13210           (315)471-2636|                               
****************************************************************************

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 1993 14:01:53 -0000
From:      barryf@iol.ie (Barry Flanagan)
To:        comp.protocols.tcp-ip
Subject:   Re: MS-DOS Telnet in?

Nathan Clark (NC6967@CONRAD.APPSTATE.EDU) wrote:
: I'm looking to set up an MSDOS based BBS on the internet.  I'm using a 486 with 
: an E2000 Ethernet card.  I'm wondering what sort of software I need to allow 
: users to telnet in and run the BBS.  I'm directly connected to our campus 
: network.  We guess our problem is getting BBS software to recognize incoming 
: calls on the Ethernet card.  Are there any BBS packages suited to this?


 We at Ireland On-Line have a PCBoard (DOS) BBS attached to the internet for
 telnet incoming using two different methods, both of which work well.

 Method 1: The BBS serial ports are attached to a Xylogics Annex3 terminal
 server using nullmodem cables. The ports on the server are given an IP
 address (bbs.iol.ie) and telnetting to here will bring up the BBS just like
 a standard dial-in connection. (Contact sales@xylogics.com for info and tell
 them I sent you!)

 Methos 2: We are beta testing BBSNet by Murkworks (contact
 bkc@murkworks.com) who have written a Netware NLM and a companion program
 which works with Willis Computing's COMMDRV FOSSIL Driver (this is standard
 issue with the PCBoard Multiport version). The NLM includes a telnetd which
 makes a connection to the first available PCB node. PCB, since it is
 talking to the COMMDRV as normal, does not know anything is different. The
 address for this one is 193.120.234.40 (no name on it yet).

 Which of these methods suits you is most likely down to what hardware you
 already have - if you have a terminal server already you might have all you
 need for method 1, and if you have a Netware server, then BBSNet would
 likely be a very good solution.

 Hope this helps.
-- 
Barry Flanagan - <barryf@iol.ie>
 ----
| Ireland On-Line, West Wing, Udaras Complex, Furbo, Galway,Ireland
| Tel/Fax : +353 91 92727 / 26 * BBS : +353 91 92722 (4 Lines)

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Nov 93 15:12:08 GMT
From:      db15@ukc.ac.uk (Damiano Bolla)
To:        comp.protocols.tcp-ip
Subject:   IPP Abstract. A possible evolution of the IP routing architecture

 I am currently working on network routing architectures and I would like
 the Network opinion on what I am doing.
 What follows is the abstract of the work I am doing.

 I have a postscript file that better describes what IPP is and I am posting
 it on the comp.sources.postscript newsgroup.
 There are also a toolkit that allows you to "test" the IPP flexibility
 and I am posting the source code on the comp.sources.misc newsgroup.
 If there is enough request I can post the postscript file in this group.

 I would greatly appreciate some feedback.

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


                             IPP Routing Architecture
                                  Damiano Bolla
                    University of Kent at Canterbury, England
                                  November 1993



            Abstract
            This paper  describes the  structure of  the  IPP routing
            architecture. IPP is an evolution of the IP protocol with
            the following characteristics.
            -  Network structure  is  an extension  of  a class  B  IP
               network with  Subnet 255.255.255.0.  The addresses  are
               aggregated in further Subnets  depending on the  length
               of the address.
            -  Address space  is  of  variable length  limited  to  15
               bytes. The  format of  the addresses  are  like IP  but
               extended. An example can be 147.162.2.78.45.44
            -  Routing tables are all direct  tables and all of  fixed
               size no matter how big the currently used address space
               is. The use of direct tables provides the base for high
               speed routing algorithms.
            -  The architecture  supports and  encourages the  use  of
               redundant routes and load balancing to a given  host or
               Subnet. This  allows  and encourages  the  creation  of
               extra links as the  load increases and provides  higher
               network reliability.
            -  Packet  size  overload  is  optimised  for  local  area
               networks and  only the  information that  is needed  to
               reach the desired destination is sent on the network.
            -  Broadcast is  supported with  IP style.  An example  of
               broadcast to a Subnet can be  147.162.2.3.255 that will
               send a broadcast  to Subnet  147.162.2.3. Multicast  is
               supported as an addressed broadcast.
            IPP aims to  keep all the  other qualities of  IP and the
            related IP functions  to manage  a link. What  changes is
            only the structure of  an address, the  routing table and
            routing functions.

Damiano

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Nov 1993 15:14:45 GMT
From:      rdiffe01@cad.gmeds.com (Randy Diffenderfer)
To:        comp.protocols.tcp-ip
Subject:   New version of traceroute anywhere?

Folks,

Is there a new version of traceroute out there anywhere?  The "canonical" 
version that I'm aware of is the one at ftp.uu.net, dated Jan 30, 1990 at 
path /networking/ip/trace/traceroute_pkg.tar.Z.

This one seems a bit dated, in that it seems to understand Suns only, and 
old ones at that! :-)

So, the question is, is there a more "modern" version out there good for
Sun Solaris 2.x, HP HP-UX 9.x, IBM AIX 3.2.x, and DEC Ultrix 4.x?

Thanks,
Randy Diffenderfer
rdiffe01@cad.gmeds.com

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Nov 1993 15:18:27 GMT
From:      leendert@cs.vu.nl (Leendert van Doorn)
To:        comp.protocols.tcp-ip
Subject:   tcpdump on SVR4; anyone?

Does anyone know of a tcpdump port for SVR4? I'm tempted to do it myself,
but if there's already one out there ...

	Leendert

-- 
Leendert van Doorn 			   		<leendert@cs.vu.nl>
Vrije Universiteit / Dept. of Math. & Comp. Sci.	+31 20 5484477
Amoeba project / De Boelelaan 1081A
1081 HV Amsterdam / The Netherlands

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Nov 1993 15:41:16 GMT
From:      baumgaer@informatik.uni-kl.de (Christof Baumgaertner (PA Buhler))
To:        comp.protocols.tcp-ip
Subject:   Packerdriver for DEC Etherworks3/Turbo wanted

Hello,
does anybody know if there is an packetdriver interface for the
DEC Etherworks3/Trubo Card? Please respond via e-mail. thanks!
Ciao, Christof


-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Nov 1993 17:55:18 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Fragmentation & Reassembly

In article <1993Nov22.183231.20615@berlioz.nsc.com> mturc@berlioz.nsc.com (Moe Turcotte) writes:
>
>The application is SNMP only. Is reassembly still necessary?

If you are going to the trouble to support IP/UDP/SNMP, why skimp on the
little bit of code in IP to do reassembly?  I've seen no end of products
that eventually end up being used well outside of the environments that
the builders ever expected.

Art


-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Nov 93 18:07:01 GMT
From:      db15@ukc.ac.uk (Damiano Bolla)
To:        comp.protocols.tcp-ip
Subject:   IPP postscript documentation change

The postscript documentation on IPP has been posted on comp.lang.postscript
for the following reason.

-----------------------------------------
Hi! This is Jonathan Monsarrat writing to you from Brown University.

I've gotten your post to comp.sources.postscript. As the moderator,
it's my job to decide whether to pass it on and how. If you
post to comp.lang.postscript and comp.sources.postscript at once,
I still get the post.

Your post is information, but comp.sources.postscript is for sources
postings only. You should really send your request to comp.lang.postscript.
----------------------------------------

Damiano


-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Nov 1993 18:30:33 GMT
From:      sharma@austin.ibm.com (Mohan Sharma           (8-8122))
To:        comp.protocols.tcp-ip
Subject:   The connect-connect syndrome - A bug or feature?


	I am trying to find out if the connect-connect syndrome is a
	bug or feature in TCP/IP! The following is a description of the
	connect-connect syndrome:
	
	The most common way of establishing connection between two sockets
	is by issuing a listen() on one and other issuing a connect() to
	the "listening" socket. TCP/IP allows another way to connect two
	sockets. If both sockets issue a connect() to each other, then 
	connection gets established! For example, socket A issues "connect"
	to socket B's address and the socket B issues "connect" to socket A's
	address. These two connect requests should reach the respective
	partners before they time-out, ( obviously).

	The TCP state transitions seem to permit such a connection. The connect
	request from A sends a SYN to B and waits for a SYN/ACK from B. 
	The connect request from B provides this SYN signal to A and A sends a 
	SYN/ACK to confirm connection. The story is the same on B.

	I don't know if this question has aleardy been discussed on this 
	newsgroup.  Has anyone tried this before? How does the TCP/IP "elite"
	community regard this syndrome - a bug in BSD or a feature?

Thanks.
mohan sharma
sharma@dss1.austin.ibm.com

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 93 19:13:25 GMT
From:      jxgst5+@pitt.edu (Josh Gilby)
To:        comp.protocols.tcp-ip
Subject:   need help connecting to internet with a vax

Hi there.  My company is looking to connect to the Internet using our
VAXCluster, but we have absolutely no idea where to begin looking for
information on the subject.  Can anyone supply any type of information
regarding this subject?  Anything you can provide would be great.  Please
respond via e-mail to gosling@m-net.ann-arbor.mi.us.  Thank you for your time.

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Nov 1993 19:50:21 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: The connect-connect syndrome - A bug or feature?

>	I am trying to find out if the connect-connect syndrome is a
>	bug or feature in TCP/IP!

It is a design feature, often called the "simultaneous open".  It
is specifically the transition from the SYN_SENT state to SYN_RCVD.
Unfortunately, not all vendors have verified that this works with
their implementation.  Most BSD implementations prior to 4.4BSD have
a bug handling this, and you end up with an infinite sequence of
SYN/ACKs going back and forth, and the connection is never established.
(I can dig out the 1-2 line fix, if anyone is really interested.  There
was a lot of discussion of this bug about 12 months ago in this group.)
But I've also verified that a simultaneous open does indeed work, between
4.4BSD and BSD/386 (with a patch).  An actual example appears in my
forthcoming book "TCP/IP Illustrated" (Addison-Wesley).
	
Realize that each end has to bind() a specific port to their end point
before calling connect(), which is something most clients don't do,
because if each end uses an ephemeral port, there's no way for the
other end to know what port to connect to!

Also realize that the two SYNs have to cross in the network, because
if one SYN arrives before the other end is in either the SYN_SENT or
LISTEN state, the incoming SYN will be rejected with an RST.  (It took
me a couple of tries across a slow link to get a simultaneous open to
really work.)

Has anyone out there really used this for a *real* application?

	Rich Stevens  (rstevens@noao.edu)

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Nov 1993 20:15:20 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: The connect-connect syndrome - A bug or feature?

In article <CGyJEy.333v@austin.ibm.com> sharma@dss1.austin.ibm.com writes:
>	I am trying to find out if the connect-connect syndrome is a
>	bug or feature in TCP/IP! The following is a description of the
>	connect-connect syndrome:
>...
>	I don't know if this question has aleardy been discussed on this 
>	newsgroup.  Has anyone tried this before? How does the TCP/IP "elite"
>	community regard this syndrome - a bug in BSD or a feature?

The ability of two TCP peers to simultaneously connect to each other
seems to be clearly intentional.  It's even discussed and diagrammed
on page 32 of RFC793.  I haven't been able to come up with any
practical application of this feature, but the spec requires that an
implementation of TCP handle it in a way that produces a single,
usable connection.

This has been discussed in relation to BSD before, mainly because some
BSD implementations couldn't do it.  (I don't remember the exact
symptoms, but I seem to recall the bug had some nasty side effects.)
There have been patches posted for the problem, but if I understand
you, you're looking at a system which has already been fixed.

One thing that's different about your post is that it's the first time
I've seen the simultaneous connection issue expressed in the general
case.  Normally it comes up in the special case of a single socket
connecting to itself. This is the trivial way to reproduce a
simultaneous connect since no synchonization between sockets is
required.  In this special case, the resulting loopback connection
itself is entire useless except for its amusement factor.

						don provan
						donp@novell.com

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 1993 20:46:26 GMT
From:      perry@bpdns.brooks.af.mil (David Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: MS-DOS Telnet in?

In article kbu@lester.appstate.edu, NC6967@CONRAD.APPSTATE.EDU (Nathan Clark) writes:
> I'm looking to set up an MSDOS based BBS on the internet.  I'm using a 486 with 
> an E2000 Ethernet card.  I'm wondering what sort of software I need to allow 
> users to telnet in and run the BBS.  I'm directly connected to our campus 
> network.  We guess our problem is getting BBS software to recognize incoming 
> calls on the Ethernet card.  Are there any BBS packages suited to this?
> 
> Thank you,
> 
> NC6967@conrad.appstate.edu
> 

Here are a few quick ideas:

(1)  Beame & Whiteside's BW-TCP now provides a Telnet server for PC's which
     allow several simultaneous telnet logins (I can't remember how many,
     about 8 or 10).  The applications run during the telnet session must
     be DOS text based - so if they can kick off the BBS software upon logging
     in that would be one way.  Performance of the telnet server, during our
     evaluation of the product seemed to be a little slow, but we did not 
     fully test it.

(2)  One thing we did to provide telnet access to a BBS was to setup a
      TCP/IP terminal server (3Com) and setup ports on the server for telnet
      capability (also using a rotary feature which will allow several ports
      to share the same IP address and while one port is busy, the server
      would rotate to the next available port).  We connected these ports on 
      the 3Com server to the serial ports on the PC so that the BBS software
      (Mustang Software's WildCAT! BBS) responded as if it were a modem.  The
       PC is a 486 with lots of RAM (16MB) using Quarterdeck's DesqView for 
       multitasking each BBS session.  This is working nicely.


David Perry
Computer Sciences Corp.
Brooks AFB, TX



---

David W. Perry
Computer Sciences Corp.  
Brooks AFB, TX



-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Nov 1993 21:24:03 GMT
From:      ACU00JTF@unccvm.uncc.edu
To:        comp.protocols.tcp-ip
Subject:   Why does HPLJ 4si eject blank page?

Why does the HPLJ 4si eject a blank page everytime a document is printed?
Can anyone tell me how to make this stop? - Thanks
 
JF
 

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 1993 22:00:01 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Fragmentation & Reassembly

In article <geraldyCGxv32.9LC@netcom.com> geraldy@netcom.com (Gerald Yu) writes:
    If a packet arriving at the destination has a re-assembled length
    greater than the destination network's MTU, then the packet will
    be discarded, correct?  What other process is involved?  
    
Incorrect.  If the station reassembling the fragments finds that the
resulting packet is too long for its buffers, then it will be discarded.
Note that this has NOTHING to do with MTU.

Tony


-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Nov 1993 00:21:18 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: New version of traceroute anywhere?

Randy Diffenderfer (rdiffe01@cad.gmeds.com) writes:
> Is there a new version of traceroute out there anywhere?  The "canonical" 
> version that I'm aware of is the one at ftp.uu.net, dated Jan 30, 1990 at 
> path /networking/ip/trace/traceroute_pkg.tar.Z.

  As a corollary, how does one determine where to find the "canonical"
  version?

  archie reported more sites than I can count (much less remember).  I was
  going to grab them all and try to determine which versions were duplicates,
  but I never got around to it.  I finally took lilac.berkeley.edu, but I no
  longer remember why.

-- Ken Mintz

PS:  Randy, when you say the package was dated 1/30/90, is that the tar
package timestamp or the source whatstring?  lilac's timestamp is 2/91, but
the whatstring is 89/02/28.  I ass-u-me the timestamp is useless; that
simply says when the package was copied onto the system.  But I don't know
if the whatstring is useful either, because I don't know how people maintain
that.

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 1993 01:33:08 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: New version of traceroute anywhere?

In article <rdiffe01.843.754067685@cad.gmeds.com> rdiffe01@cad.gmeds.com (Randy Diffenderfer) writes:
>So, the question is, is there a more "modern" version out there good for
>Sun Solaris 2.x, HP HP-UX 9.x, IBM AIX 3.2.x, and DEC Ultrix 4.x?

I'm pretty sure that Ultrix 4.x ships a reasonably useful version of
traceroute.  Probably in one of the "optional subsets."  Ditto for
DEC OSF/1.

-Jeff

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 93 06:45:33 EST
From:      gavron@spades.aces.com (Ehud Gavron)
To:        comp.protocols.tcp-ip
Subject:   Re: Upgrade from 14.4 SLIP to 56K - question

oar
3 00:43 MST
Organization: ACES Research Inc.
Lines: 36
Distribution: world
Message-ID: <22NOV199300435022@spades.aces.com>
References: <margueriCGvL8C.MwD@netcom.com>
Reply-To: gavron@ACES.COM
NNTP-Posting-Host: alpha.sunquest.com
News-Software: VAX/VMS VNEWS 1.41    UAlboticle <margueriCGvL8C.MwD@netcom.com>, margueri@netcom.com (Dave Correia) writes...
# 
# 
#I am looking into upgrading the connection to our Internet provider
#(netcom) from dedicated 14.4kb SLIP to 56k digital. 
#Right now telnet performance across this SLIP link is pretty poor, 
#with sometimes a 3-5 second inter#to netcom across the SLIP link; direct dialin to either side is snappy.)
# 
#So my question is: How do I estimate the performance improvement 
#gained upgrading from 14.4kb SLIP to 56K digital? 
# 
#Currently in use: Telebit 3000 modem, port#Proposed: CSU/DSU, 56k Digital line, router.
#Simple math would indicate a 4x improvement -- How do I factor
#in analog vs digital, SLIP vs (??), etc?
# 

Average latency 56bytes SLIP 14.4K: 240-280ms
			DDS  56K:    60ms

#Any help or advice would be greatly appreciated.

I sell 56K connectivity in Tucson, and let me tell you, it's
significantly better... and for only 3x the cost of 14.4K,
I don't ksici hy everyone doesn't do it...


Ehud

--
Ehud Gavron        (EG76)     
gavron@aces.com

For info on aces connections send mail to  INFO@ACES.COM 
with the subject line SLIP.

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 1993 02:29:15 GMT
From:      mike@atc.sp.paramax.com (Michael W. Grenier)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Subject:   NetBios services on UNIX

Does anyone know of a file server that would run under UNIX
(or source for anything else) that conforms to RFC 1001 and
RFC 1002 (NetBIOS Services on TCP/IP). I'd like to get
my Windows NT box hooked up to the UNIX platforms and
since NFS client support for NT is difficult to find, I thought 
that maybe NETBIOS services for UNIX might be easier.

   -MIke Grenier    mike@atc.sp.paramax.com
    612--456-7869  Unisys Govt. Systems

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Nov 1993 03:16:17 GMT
From:      S903608@mailserv.cuhk.hk
To:        comp.protocols.tcp-ip
Subject:   INFORMATION ABOUT PC/TCP PROGRAMMING (REQUEST)


Hello eveybody,

	Do anybody know where to get information on the programming over
the FTP's PC/TCP interface? All types are welcome, details on function
calls or higher level APIs are especially appreciated. Please send me
in whatever format by email to 

		s903608@137.189.6.26

THANX A LOT!!!

Rudolf Ngan.

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Nov 93 10:08:10 EST
From:      SURU@TWNMOE10.Edu.TW
To:        comp.protocols.tcp-ip
Subject:   documents on CIDR or supernetting

Hi!
 
    Anybody please direct me to some documents on CIDR (Cross Inter-
Domain Routing) or the machanism used by supernetting? Thanx.
 
--Leo
 
 
 
 

-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Nov 93 06:23:42 GMT
From:      detlev@dbha.toppoint.de (Detlev Habicht)
To:        comp.protocols.tcp-ip
Subject:   Where can i get an ethernet address?

Hi,

i need the name and/or the email address for the organization or company
where i can ethernet addresses (it is no mistake, i need ethernet address!).

Thanx, Detlev


-- 
Detlev Habicht
_______________/\  _____________________________________________________
                 \/
 OFFICE: D-30167 Hannover +49 511 7624992 habicht@imes.uni-hannover.de
         Institut fuer Mikroelektronische Systeme, Universitaet Hannover
 HOME:   D-30419 Hannover +49 511 2712029 detlev@toppoint.de

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 93 08:23:11 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: TCP/IP over ATM

In article <1993Nov23.052849.24502@ntuix.ntu.ac.sg> mty@ntuix.ntu.ac.sg (Yap Ma Tit) writes:
>What parameters of TCP are tunable?
>e.g. sliding window size (how?)
>
>We have got an ATM switch, but we can
>only get 14 Mbps out of the raw bandwidth
>of 100 Mbps!

I only got about 18 Mb/s out of an ATM card on a Sparc II with an
appropriately configured machine and benchmark, so that isn't
necessarily out of line.  

However, so you can tune to your hearts' content, I suggest use of a
program I wrote to make management of this and other network options
much easier, including a man page that tries to explain the more
important options (like TCP max window sizes).  It will automatically
print out the more interesting variables on most machines and provide
an easy means of changing the values.  The parameters are explained in
the man page.  It's called 'netconfig,' and it can be retrieved by
anonymous FTP from 

ucsd.edu:pub/csl/netconfig

							Jon

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Nov 1993 12:46:53 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI

> Could anyone out there tell me how to get ahold of the Transport Layer
> Interface (TLI) specification? Thanks in advance.

TLI is a programming interface.  It's "spec" is basically the man pages
from AT&T, which you can get in the AT&T book set that (I think) Prentice
Hall publishes.  Vendors that ship some flavor of SVR4 also supply the
TLI man pages (Solaris 2.x, Unixware, etc.).

TPI (transport provider interface) is the particular way that SVR4 happens
to implement TLI.  (You shouldn't need this unless you're developing
something like TLI.)  It's spec is available using anonymous ftp from
ftp.ui.org in the pub/osi directory.

XTI is X/Open's slight modification to TLI and you can get the XTI specs
from X/Open (415-323-7992).  XTI is the basis for the TLI portion of the
POSIX 1003.12 networking interface standard that's being developed.

Finally, if you want a book that describes TLI complete with examples
(as compared to just man pages) there are at least 4 books that describe
TLI: "UNIX Network Programming" by W. R. Stevens (P-H), "UNIX System V
Network Programming" by S. Rago (A-W), "Networking Applications with UNIX
System V Release V" by M. Padavano (P-H), and "Internetworking with TCP/IP,
Volume III (TLI Version)" by D. Comer and D. L. Stevens (P-H).

	Rich Stevens  (rstevens@noao.edu)

-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Nov 1993 13:48:15 GMT
From:      websterc@decuk.uvo.dec.com (Colin Webster)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: connecting DECwanrouter 90 to a cisco router


In article <2cl2rf$4qc@vanbc.wimsey.com>, skl@Connectivity.com (Samuel Lam) writes:
|>Xref: uvo.dec.com comp.dcom.sys.cisco:7884 comp.protocols.tcp-ip:29173
|>Path: uvo.dec.com!e2big.mko.dec.com!nntpd.lkg.dec.com!crl.dec.com!crl.dec.com!caen!spool.mu.edu!howland.reston.ans.net!math.ohio-state.edu!cyber2.cyberstore.ca!vanbc.wimsey.com!vanbc.wimsey.com!not-for-mail
|>From: skl@Connectivity.com (Samuel Lam)
|>Newsgroups: comp.dcom.sys.cisco,comp.protocols.tcp-ip
|>Subject: Re: connecting DECwanrouter 90 to a cisco router
|>Date: 20 Nov 1993 04:33:51 -0800
|>Organization: Connectivity Technology Inc., Vancouver, B.C., Canada
|>Lines: 17
|>Sender: skl@vanbc.wimsey.com
|>Message-ID: <2cl2rf$4qc@vanbc.wimsey.com>
|>References: <1993Nov18.143611.8862@sobeco.com>
|>Reply-To: skl@Connectivity.com (Samuel Lam)
|>NNTP-Posting-Host: vanbc.wimsey.com
|>
|>In article <1993Nov18.143611.8862@sobeco.com>, stacy@sobeco.com
|> (Stacy L. Millions) wrote:
|>>Does any one know if the DECwanrouters support PPP (or is there any
|>>other way to connect them to a cisco)?
|>
|>The software in the DECwanrouter 90 is basically Cisco software with
|>DEC's enhancements, so you should be able to get it to talk to a real
|>Cisco over a WAN link using the usual way you get two Cisco's to talk
|>to each other over a WAN link.
|>

	You  have to be carefull here, the DECwanrouter 90 does *not*
	support PPP.
	The DECbrouter 90 is the one based on cisco code
	
	Which one do you have ?

	Colin

|>...Sam
|>-- 
|><skl@Connectivity.com> -- Connectivity Technology Inc.
|>
|>"NetNews on CD's" product information: <NewsCD@CDPublishing.com>
|>			   or {ftp,gopher,www}.CDPublishing.com
|>
|>

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Nov 1993 14:41:57 GMT
From:      molin@kalkkaro.cc.lut.fi (Kim Molin)
To:        comp.protocols.tcp-ip
Subject:   TCP options for video

Hi !

I'm looking for some options for TCP that could leave off the checksum
calculation. Are there any standards (RFC's) available concerning my problem ?

-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 1993 15:00:03 GMT
From:      ove@yoyo.neu.sgi.com (Ove Hansen)
To:        comp.sys.intel,comp.sys.ibm.pc,comp.protocols.tcpip
Subject:   PC/TCP and Compaq NetFlex: desprately seeking packet or board driver

Help! I have a Compaq ProSignia with a 32-bit NetFlex Controller, and 
want to be able to use PC/TCP 2.2. I've looked "everywhere" for a packet
driver and even asked Compaq (who didn't want to know and referred
me to the supplier), the supplier (who isn't fit to run a bath let alone
system support - getting DOS for the Compaq took three weeks and plenty
of faxes and adrenaline although it was ordered with the machine) and 
the vendor of PC/TCP (who hasn't come back to me yet.) Does anyone know
of a packet driver which can be used with my network card, and where I
can buy or ftp it from?

Thanks in advance,
-- 
Ove Hansen - Network Administrator                 e-mail: ove@neu.sgi.com
Silicon Graphics Manufacturing S.A. (Switzerland)  Phone : (41-38) 433 535
Chemin des Rochettes 2, CH-2016 Cortaillod         Fax   : (41-38) 433 900

-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Nov 1993 16:14:09 GMT
From:      RINDFUSS-S@medea.wz-berlin.de (Peter Rindfuss)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Info on TCP retransmission timout

Does anybody know of a text or book or RFC that describes different strategies 
for programming the TCP retransmission timeout ?

-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Nov 93 16:41:59 GMT
From:      db15@ukc.ac.uk (Damiano Bolla)
To:        comp.protocols.tcp-ip
Subject:   IPP documentation and source code available as anonymous ftp

The IPP source code and documentation are available as anonymous ftp
from the following host:

eagle.ukc.ac.uk

in the following directory.

/pub/db15/v1

I apologize for the delay in setting up the files for anonymous FTP.

Damiano

-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Nov 1993 17:09:46 GMT
From:      laurence@laurence.mvision.com (Laurence Crutcher)
To:        comp.protocols.tcp-ip
Subject:   IP multicast


I've seen a number of questions regarding IP multicast capabilities
on hosts and routers, but no replies.

I would like to know from computer and network vendors when/if they
plan to support IP multicast together with IGMP etc.

I note, for example, that netstat on a Sun running Solaris 2.2 shows
an entry for the reserved multicast address, but I can't find any
documentation that indicates how/if true IP-level multicast is supported.

Replies from vendors and other users would be appreciated. I'll post
a summary later.

Thanks

Laurence

---------------------------------------------------------------
Laurence Crutcher                    phone: (212) 227-1610
Market Vision Corp.                  e-mail: laurence@mvision.com
40 Rector Street
New York, N.Y 10006
---------------------------------------------------------------

-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 1993 03:52:01 -0600
From:      ucacjon@ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over ATM

1. earlier cards do cell reassembly in s/w so 14Mbps aint at all surprising - your also

wasting a lot of cpu! (but not actually 'wastying' bandwidth - )

2. later DMA cards that have an AAL5 layer interface (e.g. Fore SBA 200) claim ~90Mbps

which is not bad, though i'd bne interested how many VCIs they can support (e.g. if i wanted
 to run a sequent transaction server on an ATM net with 10,000 clients at a time, and a 1.1
 mapping of tcp to ip dest to VCI, would they still get good performance: i think not.

however, putting the TCP.ip.vci maplet into the board takes ~128 bytes per connection
 for TCP, prob similar for the AAL5 reassemlby descriptors, so around
 256*10k, or 2Mbytes of descriptor memory would suffice - compared with the 2k cost of an ATM
 interface, this would be cheap to provide...but would entanlge the tcp with the board (unless done in main/shared memory...which is also reasonable but then runs into bus
 contention for descriptor access (lance-like:-(

but err, why run tcp/ip/all5? well, coz you wanna go on talking to the rest of the world who 
can't afford to move to atm yet...


-- 
jon crowcroft (hmmm...)

-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Nov 93 18:08:58 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   RE: Where can i get an ethernet address?

In Article <1993Nov24.062342.4580@dbha.toppoint.de>
detlev@dbha.toppoint.de (Detlev Habicht) writes:

>i need the name and/or the email address for the organization or company
>where i can ethernet addresses (it is no mistake, i need ethernet address!).

From the IEEE OUI document:

If your firm manufactures or plans to manufacture products using ISO/IEC
8802 standards, you should apply to IEEE for your firm's OUI.  The Institute of
Electrical and Electronics Engineers, Inc. has been designated by the ISO
Council to act as the registration authority for the implementation of
International Standards in the ISO/IEC 8802 series.  This is the one world-
wide source of registered OUIs.   For further details contact:
     IEEE Registration Authority
     IEEE Standards Department
     445 Hoes Lane, P.O. Box 1331
     Piscataway NJ   08844-1331
     phone:  (908)562-3813
     Fax:    (909)562-1571
     Email:  i.ringel@ieee.org

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov		(510) 422-6955

Disclaimer: Being a know-it-all isn't easy. It's especially tough when you
don't know that much. But I'll keep trying. (Both)

-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Nov 1993 18:12:09 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Fragmentation & Reassembly

In article <geraldyCGxv32.9LC@netcom.com> geraldy@netcom.com (Gerald Yu) writes:
>If a packet arriving at the destination has a re-assembled length
>greater than the destination network's MTU, then the packet will
>be discarded, correct?  What other process is involved?  

??? No, maximum IP message size has little to do with network MTUs.
Any IP station is supposed to be able to reassemble an IP datagram
of at least 576 bytes.  Larger IP packets may be sent by agreement of
the endpoints.  In TCP this is negotiated with the Max Segment Size
option.  For UDP it is usually defined apriori (for protocols like
NFS).  Suns routinely send 8K IP packets containing NFS traffic over
1500 byte MTU Ethernets.  A lot of effort has gone into avoiding
fragmentation, but once fragmented, the receiving party is responsible
for putting the packets back together.  Most systems can handle IP
datagrams up to 8K and IP supports datagrams up th 64K.

Art


-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Nov 1993 18:12:13 GMT
From:      dejesus@avalon.chinalake.navy.mil (Francisco X DeJesus)
To:        comp.dcom.lans.fddi,comp.protocols.tcp-ip,comp.sys.sun.admin,comp.sys.hp
Subject:   Changing MTU size... how?

(Please forgive the horrendous crosspost)

I have a situation where I have a large number of NFS servers and
clients on both FDDI and ethernet. Large amounts of data go from the
FDDI side to the ethernet side, and the router apparently isn't up
to the task of breaking up that many packets.

No, we can't change the network topology right now, nor can we replace
the router. In the near future, we hope to have everything on FDDI, so
this will hopefully not be a problem. Until then, however, we need to do
something to be able to make good use the systems...

I keep hearing that the thing to do is to change the packet size (MTU)
on the FDDI machines to 1500, which will eliminate the need for the
router to fragment them. Great! My question is, how???

The documentation we received with our FDDI cards is almost nonexistant.
I've read all the man pages and FAQs I thought might have such information
but haven't found it. If there is an appropriate "FM" to "RT", a pointer
to it would be appreciated.

Specs: Sun Sparc 10's running 4.1.3 w/ Sun FDDI card (bf driver), and
an HP 750 running 8.x with HP's FDDI card. I need instructions on how to
change the MTU on these specific systems... let me know if more details
are necessary.

Please replay by email. I'll summarize to anyone who's interested. Thanks
very much in advance...
-- 
  _____ _  _   Francisco X DeJesus -/ S A I C /- dejesus@c3ot.saic.com   -{----
 | ___/< \/ >  -------------------------------------------------------   /
 | __|  >  <   [disclaimer: opinions are mine, typos and errors yours]   \/> _
 |_|   <_/\_>  "Hack the hardware, not the Constitution." -B. Sterling   |#\/`

-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Nov 1993 19:44:15 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        comp.protocols.tcp-ip
Subject:   Moving laptops between _two_ distinct subnets...

I have been asked to provide some idea on how to solve a vexing problem,
and none of the options that I have come up with seems very nice, and
some may not even work. Since I expect this to become a rather common
problem, perhaps other people want to discuss it.

The problem is simple: there are two networks, connected by a direct
link; say that each is a single Ethernet and is class C. Each of them
has (one or more) servers and a number of desktops depending on those
servers. Let's say they are the N and M networks, and the gateway on
each is N.g and M.g and they are connected, and the servers are N.s and
M.s. Clients on either networks use both networks' servers, but each
client has a primary server for things like filestorage and mailstorage.

There are also a number of laptops on each network, and each laptop is
normally homed on one of the networks; but since the two networks are
not geographically close, people want to be able to move a laptop from
one network to another network, and continue working using the server on
the original network to continue accessing their main filestore and
mailstore on the other network's server, without reconfiguring their
machine.

Obviously assigning each laptop an address on their original subnet will
not work: if the address is M.l, and the laptop is then attached to N,
packets it sends to its M.s server will be routed by N.g to M.g and will
reach it, but replies will not be routed back, because an address of the
form M.x is supposed to be on the M wire, not on the N wire.

Basically the problem is that each laptop should be an independently
routable entity, not one of many addresses on a network that is routed
as a whole.

The possible alternatives are:

every time a laptop is hooked to M or N, some "local" IP address and DNS
name are statically assigned to it.

  Bootp could be run, and the bootp servers on both networks could have
  a list of all the ethernet numbers of all laptops, with different IP
  addrs on each network, but this requires duplicating configuration
  data, and is not nice; this is what they are trying to use right now,
  but are not happy.

every time a laptop is hooked to M or N, some "local" IP address and DNS
name are dynamically assigned to it.

  This _avoids_ the independently routable requirement, but this is
  considered very unpleasant to manage. Some authentication, for
  example, is done using the IP address of a client. Also dynamic IP
  address and DNS name assignment sw are not available that easily.

assign a separate class C network to _each laptop_.

  This seems rather extravagant...

assign a 4-wide subnet of a class C network to each laptop.

  this is often done for SLIP links, but I not sure that subnetting
  would be handled right by the gateways between M and N. Other than
  that it is not that different from giving each machine a different
  address.

reserve a third class C network, say L, for laptops, assign all laptop
addresses from it, and then insert individual routes to addresses of the
form L.x

  This is perhaps what I think is the neatest idea. Each laptop has a
  fixed address, and adding the routes could be in principle automated;
  M.g and N.g would have to gateway between M and L on one wire and N
  and L on the other wire too. Trouble is, I am not sure it could be
  made to work, given that L would in fact not be a net, or even a
  subnet, at all.

Before any experimentation starts on the variously whacky alternatives,
please comment on them, and suggest any others you can think of.

Thanks!

-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 1993 21:13:19 GMT
From:      jbrady@deepriver.East.Sun.COM (John Brady - SunNetworks Consultant)
To:        comp.protocols.tcp-ip
Subject:   Re: Moving laptops between _two_ distinct subn

In article 93Nov24194415@frontb.aber.ac.uk, pcg@aber.ac.uk (Piercarlo Grandi) writes:

[deleted some stuff]

>The possible alternatives are:
>
>every time a laptop is hooked to M or N, some "local" IP address and DNS
>name are statically assigned to it.
>
>
>every time a laptop is hooked to M or N, some "local" IP address and DNS
>name are dynamically assigned to it.
>
>
>assign a separate class C network to _each laptop_.
>
>
>assign a 4-wide subnet of a class C network to each laptop.
>
>
>reserve a third class C network, say L, for laptops, assign all laptop
>addresses from it, and then insert individual routes to addresses of the
>form L.x
>


As a variation on your last option, I would add bridging traffic destined
for logical network L between physical networks M and N.  As long as your
notebooks can dynamically chose a router (from RIP udates or similar) no
config changes would be needed when a notebook moves from M to N or vice
versa.  This would be an adequate solution if the number and activity of
notebooks is relatively small.

John Brady
Network Management Consultant
SunNetworks, A Sun Microsystems, Inc. Business
(703) 204-4859
john.brady@East.Sun.Com


-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Nov 1993 03:07:13 GMT
From:      marquis@netcom.com (Roger Marquis)
To:        comp.protocols.tcp-ip
Subject:   Re: Help! Non-interactive file transfer

g552536@kirk.lasc.lockheed.com wrote:
>I am interested in non-interactive file transfer of large amounts
>of data. I've begun reading rfc's for BFTP, TFTP, & SFTP and was 
>wondering if there is a standard for non-interactive file transfer
>or a library interface to third party ftp packages as mentioned
>in rfc1068.

If both source and destination hosts are running Unix the you might try
using uucp.  Uucp will work over a network and has some nice security
advantages over ftp or rcp.

Roger Marquis

-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 93 08:16:27 GMT
From:      jraja@snakemail.hut.fi (Jarno Tapio Rajahalme)
To:        comp.protocols.tcp-ip
Subject:   Re: The connect-connect syndrome - A bug or feature?

In article <1993Nov23.195021.15274@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:

>their implementation.  Most BSD implementations prior to 4.4BSD have
>a bug handling this, and you end up with an infinite sequence of

Now that you mentioned the 4.4: Where is the 4.4BSD available? Does
its TCP/IP stack differ from the BSD net2 release? Has this 4.4BSD
stack anything to do with the Van Jacobson TCP/IP stack? Any pointers
for more info on 4.4BSD and Van Jacobson's new TCP/IP stacks?

>	Rich Stevens  (rstevens@noao.edu)

Thanks,

	Jarno
-- 
-----------------------------------------------------------------------------
| Address: Jarno Rajahalme            | EMail:                              |
|          Servin Maijan tie 12 H 111 |   Jarno.Rajahalme@hut.fi            |
|          02150  ESPOO, FINLAND      | tel: +358 0 468 2891                |
-----------------------------------------------------------------------------



-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Nov 93 15:21:03 EST
From:      alhajery@cat.syr.edu (Eyas S. Al-Hajery)
To:        comp.protocols.tcp-ip
Subject:   Application-TCP IPC.




Consider the following scenario :
  
 An application process (ON Unix) wants to send a message to a remote application (at a remote site), the app. process will first make a system call to create a 
socket, after the socket is being created it will use it to write the message. 
There will be context switching, in which the appl. process will be blocked and
the communication process (in this case the TCP) will be invoked to do the
message transfer. There are two things I want to consider in this scenario :

1. The time needed to make a system call on Unix (e.g. create a socket and write to the created socket) !!.

2. The time needed to do a context switching (e.g. between the application process and the commnuication process) !!.

If anyone has any information about these two inquires (or refer me to a reference
that can help in this regard), I'd appreciate the help.  

Pls., reply to (alhajery@cat.syr.edu).

Thanks.

   - Eyas


  

-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 1993 10:28:04 GMT
From:      mik@heike.informatik.uni-dortmund.de (Michael Kienle)
To:        comp.protocols.tcp-ip
Subject:   PD Network Monitor/Analyzer wanted

Hi netlanders,

I'm looking for a network-monitoring/analyzing PD-tool (running on SPARC or PC).
Especially a protocol analyzer for upper layers (YP,NFS,...) would be very helpful.

Anyone out there, who can give me some hints...

Thanx in advance,

mik.

============================================================================
Michael Kienle                 e-mail:mik@aladin.informatik.uni-dortmund.de
Computer Science Department , IRB     
University of Dortmund,            voice : +49 231 755 2422   
44221 Dortmund, Germany               fax: +49 231 755 2386
============================================================================

-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Nov 1993 10:58:13 GMT
From:      ignatios@theory.cs.uni-bonn.de (Ignatios Souvatzis)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: WORKING version of KA9Q with PPP support STILL in it.

read the damned faq and get the damned jnos from wg7j.ece.orst.edu or the
precompiled binary from idefix.cs.uni-bonn.de, and tell me if idefix is down so I
can restart the net.

Regards,
-- 
	Ignatios Souvatzis
	ignatios@cs.uni-bonn.de souva@astro.uni-bonn.de
Cute quote: "You should also consider that the ST comes fully equipped with a 
             text adventure. It's called ST Basic." Amylaar@meolyon.hanse.de

-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Nov 1993 11:18:58 GMT
From:      geraldy@netcom.com (Gerald Yu)
To:        comp.protocols.tcp-ip
Subject:   Re: Fragmentation & Reassembly

I see.  MTU is different from the complete packet's size.

So how does a source host know what maximum packet size is supported
at the destination host?  Is 64K supported at all IP hosts?  Or, does
it resort to send-and-pray when a packet's size is up to some "large"
size?  And what would that size be, 8K, 16K, 32K?

Thanks all who solved the confusion for me by follow-up posts and
e-mails!! 


Gerald


art@acc.com (Art Berggreen) writes:
>In article <geraldyCGxv32.9LC@netcom.com> geraldy@netcom.com (Gerald Yu) writes:
>>If a packet arriving at the destination has a re-assembled length
>>greater than the destination network's MTU, then the packet will
>>be discarded, correct?  What other process is involved?  
 
>??? No, maximum IP message size has little to do with network MTUs.
>Any IP station is supposed to be able to reassemble an IP datagram
>of at least 576 bytes.  Larger IP packets may be sent by agreement of
>the endpoints.  In TCP this is negotiated with the Max Segment Size
>option.  For UDP it is usually defined apriori (for protocols like
>NFS).  Suns routinely send 8K IP packets containing NFS traffic over
>1500 byte MTU Ethernets.  A lot of effort has gone into avoiding
>fragmentation, but once fragmented, the receiving party is responsible
>for putting the packets back together.  Most systems can handle IP
>datagrams up to 8K and IP supports datagrams up th 64K.
 
>Art
 

-----------[000457][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Nov 1993 12:29:10 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: PPP on SATELLITE link

In article <1993Nov23.151545.11381@news.dkrz.de> smakedan@awi-bremerhaven.de (Siegfried Makedanz) writes:
   Is PPP an appropriate protocol for satellite data-links?  I would
   like to know how PPP handles the time delays and how the packet
   size (or else) can be adjusted to cope the problems of
   long-distance calls.

The PPP running on your link gateways lets you specify packet sizes as
needed, and defaults to 1500.  You'll usually pick smaller MTUs for
better interactive responsiveness in the midst of batch transfer
traffic, though interactive traffic will be pretty bad over a
satellite whatever you do.  But PPP just manages the link, and it
knows nothing of end-to-end delays.  The session endpoints' TCP
implementations will be more critical to the overall performance of
the link, particularly throughput.  See RFC 1323 for a discussion.

I'll crosspost this to comp.protocols.tcp-ip because there's probably
more satellite TCP/IP experience there, and because that's the layer
that really matters.

   We have a mobile research vessel and a all-year station in
   Antarctica that are only reachable via satellite. The idea is to
   connect these facilities transparently on a dial-up basis to the
   institute at Bremerhaven, Germany.

Talk to the folks at Woods Hole about their experiences with shipboard
PPP over satellites, and talk to the folks at the Dante/Erebus project
about their experiences with PPP over satellites to Antarctica.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221-2856      +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Nov 1993 13:50:18 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: The connect-connect syndrome - A bug or feature?

> Now that you mentioned the 4.4: Where is the 4.4BSD available? Does
> its TCP/IP stack differ from the BSD net2 release? Has this 4.4BSD
> stack anything to do with the Van Jacobson TCP/IP stack? Any pointers
> for more info on 4.4BSD and Van Jacobson's new TCP/IP stacks?

My understanding is that 4.4 is available but you need the normal USL
license to get it.  I think CSRG would like to make a 4.4BSD-lite
distribution available (I've also heard this referred to as Net/3)
but I doubt you'll see anything until the lawsuit is settled.

The 4.4 code that I've seen at UCB includes multicasting and all the
LFN TCP mods (timestamp option, window scale option, and PAWS).  It's
all the standard mbuf-based code that we've all come to love, it's not
the new-Jacobson code that is a complete rewite of the TCP/IP stack
(without mbufs).  I know of nothing describing Jacobson's work other
than a posting of Van's made by Craig Partridge to this group in September,
where Van described how normal TCP receive packet processing in his system
is about 30 machine instructions.

	Rich Stevens  (rstevens@noao.edu)

-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 1993 14:17:22 GMT
From:      jerry@uni-paderborn.de (Gerald Siek)
To:        comp.protocols.tcp-ip,comp.sys.mac.system,comp.sys.mac.programmer
Subject:   Can a Mac serve as TCP router?

Hello Wizards!

I have a Macintosh with 2 Ethernet cards.   Is it possible to use this
machine as a TCP-IP router between the two network it connects?   I assume
that I will need some routing software in addition to MacTCP.

Any hints?   Thanks in advance for your help!

Regards,
	Jerry
--
  Gerald Siek  -  jerry@uni-paderborn.de  -  University of Paderborn, Germany

-----------[000460][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Nov 1993 14:51:53 GMT
From:      leighd@syma.sussex.ac.uk (Leigh Dodd)
To:        comp.protocols.tcp-ip
Subject:   Bootp PROBLEM

[ Article crossposted from comp.sys.sun.admin ]
[ Author was Leigh Dodd ]
[ Posted on Thu, 25 Nov 1993 14:49:52 GMT ]

Hi All
	I'm running bootp.2.2+FdC on a sun server and using a version of
Bootp for PC-NFS to set-up various PC's. The problem thet I have is that
the sun's bootp daemon is filling my /var/adm/messages up with all the
campus bootp requests. I only support the engineering pc-nfs PC's. 

	A sample messages follows :-

Nov 21 11:06:29 sengg27 bootpd[11354]: Ethernet address not found: 00007B103E13
Nov 21 12:05:03 sengg27 bootpd[11354]: Ethernet address not found: 0000A7000000
Nov 21 17:35:38 sengg27 bootpd[11354]: Ethernet address not found: 00007B103E13
Nov 21 19:23:52 sengg27 bootpd[11354]: Ethernet address not found: 00007B103E13
Nov 21 20:33:18 sengg27 bootpd[11354]: Ethernet address not found: 00007B103E13
Nov 21 20:44:40 sengg27 bootpd[11354]: Ethernet address not found: 00007B103E13
Nov 22 07:57:41 sengg27 bootpd[11354]: Ethernet address not found: 00007B104240
Nov 22 08:03:12 sengg27 bootpd[11354]: Ethernet address not found: 00007B042C29
Nov 22 08:13:44 sengg27 bootpd[11354]: Ethernet address not found: 00007B100F28
Nov 22 08:53:40 sengg27 bootpd[11354]: Ethernet address not found: 00001B3DB21F
Nov 22 09:01:51 sengg27 bootpd[11354]: Ethernet address not found: 0000A710FF6D

	How can I stop bootpd from logging all the not found addresses ?.

I've tried to turn off -DSYSLOG from the makefile but bootpd.c won't compile.

Any help ?.

Thanks in advance.

Leigh

--
*******************************************************************************
* Leigh Dodd (Sun System Administrator)  |      Three Steps to Heaven         *
* University of Sussex                   | 1). C.B.T. ----- Passed            *
* Brighton, England.                     | 2). Part 2 ----- Passed            * 
* INTERNET: leighd@eaps.susx.ac.uk       | 3). Gota GPz550 and Riding To HELL *
*******************************************************************************

--
*******************************************************************************
* Leigh Dodd (Sun System Administrator)  |      Three Steps to Heaven         *
* University of Sussex                   | 1). C.B.T. ----- Passed            *
* Brighton, England.                     | 2). Part 2 ----- Passed            * 
* INTERNET: leighd@eaps.susx.ac.uk       | 3). Gota GPz550 and Riding To HELL *
*******************************************************************************

-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Nov 1993 16:16:17 GMT
From:      rbowles@zis.ziff.com (Bob Bowles, Ziff Information Services, 393-3237)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   RE: connecting DECwanrouter 90 to a cisco router

>|>In article <1993Nov18.143611.8862@sobeco.com>, stacy@sobeco.com
>|> (Stacy L. Millions) wrote:
>|>>Does any one know if the DECwanrouters support PPP (or is there any
>|>>other way to connect them to a cisco)?
>|>
>|>The software in the DECwanrouter 90 is basically Cisco software with
>|>DEC's enhancements, so you should be able to get it to talk to a real
>|>Cisco over a WAN link using the usual way you get two Cisco's to talk
>|>to each other over a WAN link.
>|>

As stated in previous replies, DECwanrouter 90 and DECbrouter 90 are different
animals.  The latter uses cisco code and should interoperate fully with
other cisco routers.

The DECwanrouter 90 and DECwanrouter 250 are similar and do not support PPP
to the best of my knowledge.  However, if all you need is IP, use X.25/LAPB
as your datalink and you may configure X25DAs circuits (RFC877) between
the DECwanrouter90 and your cisco.

(Note that I've never tried this combination, but I've had no trouble making
X25DA circuits between cisco and DECnis routers which interoperate over X.25
with WR90/250s.)

Bob Bowles
Ziff Information Services
rbowles@zis.ziff.com

-----------[000462][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Nov 1993 20:03:20 GMT
From:      smart@actrix.gen.nz (Quentin Smart)
To:        comp.protocols.tcp-ip
Subject:   PPP and PC-Route?

Is there a variant of PC-Route that supports PPP?

If there isn't, is it possible to pare down NETBSD to the bare minimum and
run that as a "router".
Will the PPP for BSD support header compression?

TIA
Quentin
(smart@actrix.gen.nz)

-----------[000463][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Nov 1993 20:10:39 GMT
From:      m.h.behringer@dante.org.uk (Michael Behringer)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP RFC Needed

In article <2cj522INNbrp@ssdc.SSDC.Sterling.COM>,
nalley@ssdc.SSDC.Sterling.COM (Nancy Alley) wrote:

> 
> Can anyone tell me where to find the FTP RFC?  I need it for an FTP port.
> Thanks.

ftp.ripe.net

-- 
Michael H. Behringer --- M.H.Behringer@DANTE.org.uk

-----------[000464][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Nov 1993 20:13:30 GMT
From:      gls@cirrus.com (Gary L. Schaps)
To:        comp.protocols.tcp-ip
Subject:   Re: PD Network Monitor/Analyzer wanted

In <2d21bk$1hp@fbi-news.informatik.uni-dortmund.de> mik@heike.informatik.uni-dortmund.de (Michael Kienle) writes:

>Hi netlanders,
 
>============================================================================
tcpview is a gui front-end to tcpdump.  Both run on SPARC systems.
-gls
-- 
Gary L. Schaps <gls@cirrus.com>

-----------[000465][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Nov 1993 22:07:18 GMT
From:      sonicsys@netcom.com (Sonic Systems)
To:        comp.protocols.tcp-ip
Subject:   IP fragmentation and SNMP


Does anyone know if SNMP/UDP requires support of IP fragmentation
and reassembly?  More specifically, I'm designing an ethernet-based embedded
system which has an SNMP agent, and I want to know if any of
the popular SNMP manager packages use large packets (greater than MTU) 
which cause fragmentation.  For instance, do they ever 
send enough GetRequests in one packet to cause fragmentation?
In general, it seems that IP requires fragmentation/reassembly in order to
be complete, but of the few SNMP managers I've looked at, none
send fragmented packets.
If possible, I'd like to avoid implementing fragmentation/reassembly,
and would like to know if anyone has experiences with this.

Thanks,
Sudhakar Ravi
Sonic Systems
sonicsys@netcom.com

-----------[000466][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Nov 1993 23:19:44 GMT
From:      ag995@Freenet.carleton.ca (Marwan Forzley)
To:        comp.protocols.tcp-ip
Subject:   NONBLOCKING SOCKETS And TIMEOUTS


I have Two questions.
1- How do you make a socket nonblocking?. If the socket is nonblocking
   then does that mean accept and recv will be nonblocking too?
   Would I be able to do the following?
   - nonblocking accept
   - change socket to block
   - blocking receive.

2- How do you implement  timeouts in TCP/IP?
I would appreciate if somebody can help me on that
thanks
-- 
*** Computer Internetworking ends the problem of geographical ***
*** distance between people and establishes a close well      ***
*** developed human to human communication.                   ***
*** Marwan Forzley, u589977@csi.uottawa.ca, 1-613-726-0727    ***

-----------[000467][next][prev][last][first]----------------------------------------------------
Date:      26 Nov 93 01:54:43 GMT
From:      pug@cs.curtin.edu.au (Greg Barron)
To:        comp.protocols.tcp-ip
Subject:   Re: PD Network Monitor/Analyzer wanted

mik@heike.informatik.uni-dortmund.de (Michael Kienle) writes:

>Hi netlanders,
 
>I'm looking for a network-monitoring/analyzing PD-tool (running on SPARC or PC).
>Especially a protocol analyzer for upper layers (YP,NFS,...) would be very helpful.
 
>Anyone out there, who can give me some hints...

Aren't you lucky!

I've just finished upgrading something that decodes NFS, NIS(YP), mount,
portmapper and a few others,

It is an X11 application available for sparcs (running SunOS -- Solaris port
still to follow) and DEC-Ultrix.

As far as I am aware it is the only PD nfs decoder there is (For workstations
anyway)

Here is the readme which says where to get it. Please tell me ehat you think
of it.

------

Packetman: packet analyser				      26th October 1993
--------------------------				      -----------------

Packetman is a retrospective Ethernet packet analyser. This tool allows
the capture and analysis of an Ethernet packet trace.

Installation and use:

    o At present only binaries are available and you must be root to execute.

    o An /etc/ethers file (or "ypcat ethers") is highly recommended as this
    information is used to identify each active device.  If you do not have an
    ethers(3) file you may create one yourself or use a program like
    getethers(8) to generate a list of hostnames/addresses.

    o Also recommended are two files which are used for username/uid and
    groupname/gid translations, which take place in RPC and NFS decoding.

    If these files do not exist then packetman will attempt matches dynamically
    using getpwuid and getgrgid. Note that this may be substantially slower
    and also less accurate. The files are derivatives of ./passwd and
    ./groups and can be created with the following command:

    ypcat passwd|cut -d: -f1,3|sed s/:/\ /g|sort -n +1 > filename
    (or cat /etc/passwd)

    and

    ypcat group|cut -d: -f1,3|sed s/:/\ /g|sort -n +1 > filename
    (or cat /etc/group)

    The names of these files are set in the .ad file are currently set to
    ./passwd and ./group.

Changes since previous version:
-------------------------------

    o Improvements have been made to the X interface to make packetman easier
    to use. These improvements include:

	- Repositioning of several widgets to make it easier to use.

	- Events are now processed whilst a capture is in progress - this
	allows the user to stop a capture at anytime.

	- The counter now works properly.

	- In the capture dialog, clicking on START with no number will
	default to capturing the maximum amount of packets (currently 10000).

    o Packetman now load/saves files in sniffer format. The code for this
    was taken from TCPVIEW, so if it works properly there, then it works
    properly here (and it seems to).

    o Several more protocols have been added, these corresponding to the
    ones used most frequently here at Curtin:

	- NFS (version 2)
	- NIS (version 2)
	- Mount (version 1)
	- Yppasswd (version 1)
	- Portmapper (version 2)
	- ICMP

    Both the call and reply messages in the RPC protocols are decoded. The
    reply messages being matched to the calls by the message ids. The RPC
    header information is also fully decoded. All four auth types (none, unix
    short and DES) are recognised, though only unix authentication is split
    into its constituent parts (as it is all we use here I had nothing to
    test short or DES on).

    o Host filtering is now provided, though at the present time it is not
    too elegant.

    o The decoding of protocols with large packet sizes such as NFS has
    meant that the snap length for nit is set at 0 (infinity). Unfortunately
    this results in dropped packets when using SunOS. The Ultrix packet
    filter has no problems, however.

Known Bugs:
-----------

    o There must be heaps so try your best to bring it down. I would
    expect some RPC protocols to fail, as I can only test the decoding
    of the procedures in a protocol that I have seen.

Future Directions:
------------------

    o More protocols must be added as well as the other versions of the RPC
    protocols already implemented. For example NFS version 3.

    o The major update needed is that of the filtering. Improved Host filtering
    as well as a nice X interface to selecting and displaying the current
    filters is definately on the cards. Unfortunatley my report is due and so
    all coding has stopped. After it is written I'll do by best to get this
    going.

    o Many of the interesting packets are fragged, so it may be a good idea
    to assemble fragged packets.

    o Change the load/save dialogs to proper file selection widgets.

    o Anything else you can suggest.

Please send any comments/suggestions/bug reports to:

    netman@cs.curtin.edu.au

--
Greg
           Greg Barron, pug@cs.curtin.edu.au, School of Computing
          Curtin University of Technology, Perth, Western Australia

"The ZZR-1100 remains the big, fast, versatile bike for the rider with a 
regular pillion passenger or the desire to humiliate just about every
other road user who attempted to match its straight line acceleration" - REVS

-----------[000468][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Nov 93 07:25:13 GMT
From:      detlev@dbha.toppoint.de (Detlev Habicht)
To:        comp.protocols.tcp-ip
Subject:   Are there any problems between 3COM 503 and Compaq Deskpro/M?

Hi,

i am working with a Compaq Deskpro/M, PC-NFS 5.0b, 3COM 503 ethernet card
and Compaq Windows 3.1.

Every time, when i use Telnet (telnetw) under Windows, close the telnet
window, exit windows, start windows again, try to open a telnewt window 
and make a connection, it doesn`t work.

Sometimes windows crashs and i see the DOS prompt or i see a message like
"no more sessions available". I remember about problems with 3COM and
Compaq.

All other things are working!

So, is there a problem between 3COM 503, Compaq hardware and Windows with
PC-NFS???

Detlev




-- 
Detlev Habicht
_______________/\  _____________________________________________________
                 \/
 OFFICE: D-30167 Hannover +49 511 7624992 habicht@imes.uni-hannover.de
         Institut fuer Mikroelektronische Systeme, Universitaet Hannover
 HOME:   D-30419 Hannover +49 511 2712029 detlev@toppoint.de

-----------[000469][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Nov 1993 08:21:50 GMT
From:      steven@unipalm.co.uk (Steven Vincent)
To:        comp.protocols.tcp-ip
Subject:   Re: Can't run PC/TCP with windows

lmd@cayman (Luis Delgado) writes:

>timmi@ftp.com (Kitchen Staff Supervisor) writes:
>: In article <CGA9y7.9Bq@inesc.pt> lmd@cayman (Luis Delgado) writes:
>: 
>: *Hello:
>: *
>: *I'm experiencing some performance problems with PCTCP 2.2 while running
>: *windows 3.1.
>: *
>: *When I run PCTCP (telnet for example) in DOS, over a SLIP connection, the
>: *performance is more than satisfactory, but when I run it in windows, it
>: *freezes (the telnet program- TN) as soon as I'm logged in at the remote node.
>: *
>: *So I think, this sould be a windows configuration problem.
>: 
>Hello, thanks for your reply, Timmi:
 
>I'm having problems with all PCTCP DOS apps, when being run within windows.
>If run from DOS, no problem occours.
>The problem is the following: the application just hang almost after logging
>in at the remote node. Some times it recover after a few minutes and then 
>hang again.
>If I use the PCTCP WIN apps no problem occours. Everithing goes smothly.
>The applications I tried that gave me problems are TN and FTP for DOS.

Things to check are.

1) You are loading the vpctcp.386 driver (prob obvious)
2) What priority do the DOS boxes have compared to everything else?
	(i.e. do they work fine if run "exclusive, full screen")
3) What does WINET say about the connections?
4) What happens if you run at lower speeds. (If the 14.4 speed is still to
   high for your machine for other reasons then reducing the attempted
   speed will result in more reliable transport and so more effective
   throughput).
5) Check the various buffers in use at different stages, (i.e large & small
   buffers for the Kernel, the MinimumCopySpace in System.ini, the MTU in
   use etc) are they running out or just wasting memory.
6  Reduce the MinTimeSlice and make sure that WinExclusive=0.

If these hints help you find the problem please let me know the solution.
>I thing this must be some conflict between DOS and WINDOWS, but can't figure
>what.

It probably is, it may also be a matter of loading, esp. in terms of the
number of IRQ's. The pseudo multitasking of DOS boxes does tend to affect
performance drastically. Try a high priority DOS box doing lots of disk
access (Cyclicly running TREE) and then see if the Win apps start to suffer
from the same problems, this should also "push the envelope" and indicate
that a slower speed is advisable.

>I tried your sugestion of puting, "card = vga" in "[pctcp screen]" group
>in pctcp.ini file, but whithout any success.


>Thanks for any further help.
 
>Best Regards,
>Luis Delgado, lmd@inesc.pt, cis:10024,3520
>INESC-CCAE, Lisbon, Portugal

-----------[000470][next][prev][last][first]----------------------------------------------------
Date:      26 Nov 93 08:52:31 GMT
From:      jraja@snakemail.hut.fi (Jarno Tapio Rajahalme)
To:        comp.protocols.tcp-ip
Subject:   Re: The connect-connect syndrome - A bug or feature?

In article <1993Nov25.135018.27742@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:

>> Now that you mentioned the 4.4: Where is the 4.4BSD available? Does
>> its TCP/IP stack differ from the BSD net2 release? Has this 4.4BSD
>> stack anything to do with the Van Jacobson TCP/IP stack? Any pointers
>> for more info on 4.4BSD and Van Jacobson's new TCP/IP stacks?
 
>My understanding is that 4.4 is available but you need the normal USL
>license to get it.  I think CSRG would like to make a 4.4BSD-lite
>distribution available (I've also heard this referred to as Net/3)
>but I doubt you'll see anything until the lawsuit is settled.

Sorry this ignorant question, but what lawsuit you are referring to?

>The 4.4 code that I've seen at UCB includes multicasting and all the
>LFN TCP mods (timestamp option, window scale option, and PAWS).  It's
>all the standard mbuf-based code that we've all come to love, it's not

Would it be possible to get diffs from net/2 to those files which are
pure BSD ones? All I'm interested in about the 4.4 is the
modifications/enhancements to the net/2 TCP/IP stack (netinet), socket
interface (some files in kern) and interface code (not the drivers) in
net directory.

Or where would these mods be available separately?

>the new-Jacobson code that is a complete rewite of the TCP/IP stack
>(without mbufs).  I know of nothing describing Jacobson's work other
>than a posting of Van's made by Craig Partridge to this group in September,
>where Van described how normal TCP receive packet processing in his system
>is about 30 machine instructions.

Ok. Any idea what Mr. Jacobson is going to do with his stack?

>	Rich Stevens  (rstevens@noao.edu)

	Jarno
--
-----------------------------------------------------------------------------
| Address: Jarno Rajahalme            | EMail:                              |
|          Servin Maijan tie 12 H 111 |   Jarno.Rajahalme@hut.fi            |
|          02150  ESPOO, FINLAND      | tel: +358 0 468 2891                |
-----------------------------------------------------------------------------

-----------[000471][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Nov 1993 10:38:59
From:      gerrit@bedrock.ls.swin.edu.au (Gerrit Thomson)
To:        comp.dcom.lans.ethernet,comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip,alt.winsock
Subject:   Multi-cast apps for multi-media on winsock ???

Hi all,
     I am looking for informaton regarding Multi-casting application for the 
pc clone class of computer but I am open to suugestions regarding the best 
alternative.
    I was looking at the load message on my packet driver 8003pkdr.com and it 
shows a multi-cast parameter. It seems to be able to accept multi-cast 
connections.
    I am presently using winsock  and various applications in windows.
Q:  Is multi-cast available to the clone platform, are there any apps that 
take advantage ?
Q:  Is Multi-cast available under winsock v1.1?
Q:  Will Multi-cast become available to the clone platform ?
Q: Is the SUN platform the best start for Multi-cast apps ?
Q: How does one program for Multi-cast ?
Q: Would Multi-cast be good for other apps than video-conferencing ?

With the answers to these and many more questions I would like to try to put 
together an affordable video-conferencing system using clone pc's. Other 
aspects of my investigation include fast compression algorithms for frame 
grabbed video and high speed networking.
     There was an articel a while ago in "DDJ" about speeding up the 
networking of pc's with better IPX programming. Has anyone tried the programms 
supplied in this article? Does it make a difference ?

     Thanks in advance for any info. Email to me will result in a summary 
sheet and hopefully in the long run a viable application or two. ( Note : 
these should be low cost as I work for a University !! )
      Cheers,
         Gerrit Thomson,
         Computer Systems Officer,
         Learning Services,
         Swinburne University
         Melbourne, Australia,



-----------[000472][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Nov 93 09:36:54 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Moving laptops between _two_ distinct subnets...

In article <PCG.93Nov24194415@frontb.aber.ac.uk>
   pcg@aber.ac.uk (Piercarlo Grandi) writes:
PcG> I have been asked to provide some idea on how to solve a vexing problem,
PcG> and none of the options that I have come up with seems very nice, and
PcG> some may not even work. Since I expect this to become a rather common
PcG> problem, perhaps other people want to discuss it.

This is generally referred to as the Mobile Host problem, and has been
the subject of the MOBILEIP IETF working group for a couple of years.
(In the Routing Area of IETF.) Since I have not participated actively in
that group, the following is just a very brief introduction.

The working group is chaired by
	Steve Deering of Xerox PARC <dering@parc.xerox.com) and
	Greg Minshall of Novell <minshall@wc.novell.com>.
The mailing list is <mobile-ip-request@parc.xerox.com>.
An archive is at parcftp.xerox.com:~/pub/mobile-ip/mail-archive.

PcG> The problem is simple: there are two networks, connected by a direct
PcG> link; say that each is a single Ethernet and is class C. Each of them
PcG> has (one or more) servers and a number of desktops depending on those
PcG> servers. Let's say they are the N and M networks, and the gateway on
PcG> each is N.g and M.g and they are connected, and the servers are N.s and
PcG> M.s. Clients on either networks use both networks' servers, but each
PcG> client has a primary server for things like filestorage and mailstorage.
PcG> 
PcG> There are also a number of laptops on each network, and each laptop is
PcG> normally homed on one of the networks; but since the two networks are
PcG> not geographically close, people want to be able to move a laptop from
PcG> one network to another network, and continue working using the server on
PcG> the original network to continue accessing their main filestore and
PcG> mailstore on the other network's server, without reconfiguring their
PcG> machine.

Very briefly, the basis for the model that is being standardized seems
to be based on the same principles as the roaming feature of the North
American AMPS cellular mobile telephone network.
-- 
/ Lars Poulsen			Internet E-mail: lars@CMC.COM
  CMC Network Products		Phone: (011-) +45-31 49 81 08
  Hvidovre Strandvej 72 B	Telefax:      +45-31 49 83 08
  DK-2650 Hvidovre, DENMARK	Internets: designed and built while you wait

-----------[000473][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Nov 1993 09:39:22 GMT
From:      mark@tid.es (Mark Gemmell)
To:        comp.protocols.tcp-ip
Subject:   old chestnuts #532: Router vs Workstation


Yep, another old chestnut to mull over one more time...

For connections between LAN and WAN (X.25) is it "better" to use
dedicated routers, spare workstations with X.25 cards, or
soemthing else?

In our case we want multiple points of entry from the WAN to
protect against failures, and we also want to optomise
bandwidth use by sharing the traffic amongst all the
X.25 lines.

At first routers seem the obvious solution, but considering the
low (64kb/s) bandwidth of the X.25 lines any machine can do the job.
Also, we can use the well known "gated" daemon to organise the
routing instead of getting to know the router's O/S in detail.

ALl the X.25 lines are grouped on the same X.25 address so incoming
traffic will appear on any line that is up.

Well, I look forward to some opinions and will summarise as soon
as I have 10 replies or in one week's time failing that.

You can reply here or mail mark@tid.es if you prefer.

Take it easy and get Christmas shopping!

				...Mark Gemmell...
				Excellent Dudes Ltd.


-----------[000474][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Nov 1993 11:28:16 GMT
From:      zhrge@zh014.ubs.ubs.ch (Angelo Ruggiero)
To:        comp.protocols.tcp-ip
Subject:   ICMP Router Discovery Messages Daemon

Hi,

Does anyone have source for a "ICMP Router Discovery Messages" RFC1256
daemon for UNIX. Solaris 2.x comes with one but I would like to use
it on Solaris 1.x as well.

thanks
-- 
Angelo Ruggiero 
Union Bank of Switzerland
Email:	Angelo.Ruggiero@zh014.ubs.ubs.ch
X.400:	/S=Ruggiero/G=Angelo/OU=zh014/O=ubs/PRMD=ubs/ADMD=arcom/C=CH

-----------[000475][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Nov 1993 12:29:32 GMT
From:      greulich@math-stat.unibe.ch (Andreas Greulich)
To:        comp.protocols.tcp-ip
Subject:   SLIP server software on Sun?

Hello all!
I'm aware this might be a stupid and not a new question. I wonder
if there exists a software (if possible PD) that emulates a slip
server (NOT client) on a sun that is already attached to the
internet and has a modem attached. Ideal would be if users
could log in on ascii base to the sun using the modem, and then
start the emulation program on teh sun and start their local slip client
software (eg on a PC). I know there exist modems with this
feature built in. But I look for a software solution that implements
it on the sun (and serves as a router to the internet the sun is attached
to). If there's a FAQ about it, it would also be of help.
Thanks in advance!
	A.Greulich (greulich@math-stat.unibe.ch)


-----------[000476][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Nov 1993 09:10:23 IST
From:      Hank Nussbacher <HANK@vm.biu.ac.il>
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: PPP on SATELLITE link

In article <1993Nov23.151545.11381@news.dkrz.de> smakedan@awi-bremerhaven.de
(Siegfried Makedanz) writes:
>   Is PPP an appropriate protocol for satellite data-links?  I would
>   like to know how PPP handles the time delays and how the packet
>   size (or else) can be adjusted to cope the problems of
>   long-distance calls.

We run a 128kb satellite line from Israel to the USA and ever since we
converted to PPP (from HDLC) we have had problems with automatic
line restarts with cisco routers.  Previously with HDLC, if the telco
or PTT took the line for testing or resync, as soon as they returned
the line the line would start working.  Now with PPP, the line has to
be usually manually restarted with shutdown/no shutdown.  We have seen
no difference in performance or reliability of the line with PPP as opposed
to HDLC.

Hank Nussbacher
Israel

-----------[000477][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Nov 1993 14:41:01 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP Router Discovery Messages Daemon

> Does anyone have source for a "ICMP Router Discovery Messages" RFC1256
> daemon for UNIX. Solaris 2.x comes with one but I would like to use
> it on Solaris 1.x as well.

Anonymous ftp to gregorio.stanford.edu and fetch the file
gw-discovery/nordmark-rdisc.tar.  (I haven't tried it, but
it looks like what you want, although I think it requires
multicasting, so you might need to add to Stanford multicasting
code to 4.1.3.  Or consider modifying it to use broadcasting.)

	Rich Stevens  (rstevens@noao.edu)

-----------[000478][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Nov 1993 15:38:30 GMT
From:      wat@ewi.ch (Thomas Wacker)
To:        comp.protocols.tcp-ip
Subject:   Re: ping: socket: permission denied

Jim Burnes (jburnes@csisun.uucp) wrote:

: I've never seen this error before.  I'm running SCO Unix with their
: TCP/IP package.  Telnet and ftp seem to run fine, but 'ping', 'rlogin',
: 'rcmd' (rsh) and rcp all respond with the same....
 
: (program name): socket: permission denied

At least on our Sparc 1 (SunOS 4.1) ping must run setuid root! ls -l
gives:

-rwsr-xr-x  1 root        16446 Feb  8  1990 /usr/etc/ping
-rwsr-xr-x  1 root        24576 Feb  8  1990 /usr/ucb/rlogin

Don't know anything about SCO UNIX, maybe I'm completely wrong.

			Thomas

-----------[000479][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Nov 1993 17:09:42 GMT
From:      zisiadis@cyprus.csd.uch.gr (Zisiadis dimitris 296)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP sources

 Hello TCP/IP wizards.
 I want to control the data connections that go through
one serial line that connects our domain with the rest of the 
TCP/IP world.
 So, i am thinking to add an extra hop on the route of the 
connections, just before the last router to the outside world,
that will perform the desirable flow control to the applications
originating from our domain.
 (i want to do this because i don't want the link to be congested
by some(predefined) users of our domain).
 I am thinking to monitor the link, find out which connections
congest the link and change the window size used for these connections
by capturing the acknowledgements and changing the advertized window 
size from the receiver.     
 I am doing this since icmp's source quench message does not solve 
the problem, since it is not implemented by most of the applications.

 What i am looking for is source code of the TCP/IP stack (UNIX).
 Also, i would like to know if there is any documentation available
on the TCP/IP software implementation in UNIX. 
 Any other suggestion/reference would be appreciated.

Please reply to    zisiadis@ics.forth.gr   

Thanks in advance
 Dimitris Zissiadis



n
p


-----------[000480][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 1993 03:17:03 -0500
From:      jacek@epas.utoronto.ca (Jacek Gwizdka)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Xappeal 1.4 and SLIP

I just installed X Appeal v1.4 trial on my standalone PC.
I wanted to use SLIP8250 driver and connect to the UNIX host over
modem.
After starting XAPPEAL.EXE I got blank screen and a blinking cursor.
What am I missing here?

Jacek


-- 
-- Jacek Gwizdka           | "Imagination is more important than knowledge"
-- jacek@epas.utoronto.ca  |                                A. Einstein


-----------[000481][next][prev][last][first]----------------------------------------------------
Date:      26 Nov 1993 20:13:01 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: IP fragmentation and SNMP

In article <sonicsysCH2Is7.Bv@netcom.com> sonicsys@netcom.com (Sonic Systems) writes:
>If possible, I'd like to avoid implementing fragmentation/reassembly,
>and would like to know if anyone has experiences with this.

Only routers are required to implement fragmentation, and only if they have
interfaces with different MTU's.  No system is required to fragment packets
that it is generating locally; however, this requires the application layer
to deal with the issue itself.  I don't thnk SNMP has any specific handling
of this; there are probably suggestions that SNMP-based applications not
send large queries.  But it isn't really under the control of the
application; suppose you query for a two string-valued variables, and each
one of them is 800 bytes long (so each could have been set in a single
Ethernet packet) -- this will require a 1600-byte response, which requires
fragmentation on Ethernet.

All implementations are required to support reassembly.  For instance, if
your device and the SNMP manager are on networks with MTU 1500, and a
1000-byte query gets routed through an MTU 600 network, it will be
fragmented by the gateway, and the device must be able to reassemble it.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000482][next][prev][last][first]----------------------------------------------------
Date:      26 Nov 1993 22:41:17 GMT
From:      ggt@fbmtds03.tu-graz.ac.at (Gerhard Thallinger)
To:        comp.protocols.tcp-ip
Subject:   IP Adress from device name

Hello,
   I am connecting to a remote computer via telnet. On the remote
computer the shell is running over a pseudo terminal device (like
ttyp01). How can I determine the IP adress of my local system given the
device name ?

A code fragment is highly appreciated. 

Thanks in advance

Gerhard G. Thallinger                        ggt@fbmtds03.tu-graz.ac.at 


-----------[000483][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Nov 1993 23:09:46 +0000
From:      akirkby@pentala.demon.co.uk ("Andrew P.Kirkby")
To:        comp.protocols.tcp-ip
Subject:   Class C addresses

Hi!

Sorry if this has been asked before but here goes :-

I need to setup a network of approximately 400 nodes and use IP addressing. I
cannot get a class B address, only multiple Class C addresses. What would be the
consequences of having devices, for example with addresses 192.9.200.x &
192.9.208.n on the same lan - i.e connected by a ethernet switching engine
Obviously I would need to use a router to talk betwean the nets but it is the
reaction of the devices to seeing other net addresses on the same LAN that i am
concerned about.

Cheers

Andy
-- 
Andrew P.Kirkby
akirkby@pentala.demon.co.uk

-----------[000484][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Nov 1993 00:54:44 GMT
From:      becker@super.org (Donald J. Becker)
To:        comp.protocols.tcp-ip
Subject:   Re: Fragmentation & Reassembly

In article <1993Nov20.040407.22053@unlv.edu>,
Frank Lofaro <ftlofaro@unlv.edu> wrote:
>In article <1993Nov19.210750.4586@berlioz.nsc.com> mturc@berlioz.nsc.com (Moe Turcotte) writes:
>>
>>RFC 1122 (Host Requirements) says that the Internet model requires hosts
>>to support reassembly.
>>
>>Our monitoring of random internet traffic has failed to produce a single
>>fragmented packet. Even though we are sending FTP traffic accross an X.25
>>link.
>>
>>Will a host that does not do reassembly fail miserably on the internet, or
>>will it fail to talk to some small percentage of hosts?
 
>You seem to be lucky, not having to worry about fragmentation.
>
>Many people in the Linux community have had a lot of problem with internet 
>access (both Ethernet and Serial Line Internet Protocol (SLIP)) because 
>reassembly was not available for quite a while.
>
>In other words, you might get away without fragmentation/reassembly support, 
>but it can be a real bitch if you can't!

Are you speaking from hearsay reports or real experience?  I've been running
Linux machines on the Internet for almost a year, and I can count the number
of connections that failed because of the lack IP fragment reassembly on one
hand (normal, human, 4 fingers+thumb. Hmmm, even if yellow, Simsonesque, and 3
fingers). 

The two cases where it's a problem are low-speed (and thus low MTU) SLIP
connections, and trying to use 8K NFS transactions.  You can solve the latter
by always using 1K NFS wsize/rsize parameters, at the cost of a lot bitching
about astonishingly bad NFS write performance to Suns.

If fragment reassembly had been needed for a workable system, you can be sure
one of the people working on Linux would have implemented it long before now.
I did start on an implementation of an RFC815-like reassembler, but moved on to
more pressing matters.  That's not to say we have forgotten the nominal
requirement to be able to do IP reassembly -- the next version (pl14) of the Linux
kernel will have a simpler packet-list based reassembler, but that's driven
mostly by the SLIP users.

-- 

Donald Becker					       becker@super.org
IDA Supercomputing Research Center
17100 Science Drive, Bowie MD 20715			   301-805-7482

-----------[000485][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Nov 1993 02:11:53 GMT
From:      atkinson@itd.itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Canonical KA9Q ftp site ?

I'm looking for the canonical ftp site for the KA9Q TCP/IP package
for DOS.  I'm not looking for the various and sundry derivatives
of KA9Q (e.g. KA9Q for Linux), only the regular KA9Q sources for
DOS.

If you think this isn't of general interest, please email me
rather than following up...

Thanks,

  Ran
  atkinson@itd.nrl.navy.mil

-----------[000486][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Nov 1993 07:55:31 GMT
From:      medik@cbnewsf.cb.att.com (david.i.kapalko)
To:        comp.protocols.tcp-ip
Subject:   Better bootp

I'm looking for a better bootp; one that will dynamically assign ip addresses
from a pool of addresses.  I seem to remember something about DHCP (dynamic
host configuration protocol).  Does anyone know if such a beast exists? and 
where I might find out more about it?
Thanks,
	Dave Kapalko
	medik@attme.att.com

-----------[000487][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 1993 13:43:38 GMT
From:      droms@regulus.cs.bucknell.edu (Ralph E. Droms)
To:        comp.protocols.tcp-ip
Subject:   Re: Better bootp

In article <CH54oK.J5L@cbfsb.cb.att.com> medik@cbnewsf.cb.att.com (david.i.kapalko) writes:

   I'm looking for a better bootp; one that will dynamically assign ip addresses
   from a pool of addresses.  I seem to remember something about DHCP (dynamic
   host configuration protocol).  Does anyone know if such a beast exists? and 
   where I might find out more about it?

DHCP has been defined as an Internet "Proposed Standard".  The
specifications can be found in RFC1541, RFC1533 and RFC1534 (ask me
about the numbering scheme!).  There are several commercial
implementations and one (possibly) freely available implementation
currently undergoing interoperability testing.  I maintain a mailing
list host-conf@sol.cs.bucknell.edu (subscribe with a message to
host-conf-request) and there is an archive of list traffic available
for anonymous FTP in sol.cs.bucknell.edu:/dhcwg.

--
- Ralph Droms                 Co-Director, Computer Services
  droms@bucknell.edu          Associate Professor of Computer Science
  (717) 524-1801              Bucknell University
  (717) 524-3760 (fax)        Lewisburg, PA 17837

-----------[000488][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Nov 93 15:59:25 -0100
From:      dblas@genos.frmug.fr.net (Dominique Blas)
To:        comp.protocols.tcp-ip
Subject:   Re: Canonical KA9Q ftp site ?

In <CH4oru.At0@ra.nrl.navy.mil> atkinson@itd.itd.nrl.navy.mil (Ran Atkinson) writes:
>I'm looking for the canonical ftp site for the KA9Q TCP/IP package
>for DOS.  I'm not looking for the various and sundry derivatives
>of KA9Q (e.g. KA9Q for Linux), only the regular KA9Q sources for
>DOS.
 
>If you think this isn't of general interest, please email me
>rather than following up...

Try ftp://ftp.demon.co.uk/pub/ibmpc/DIS

db

-- 
Dominique Blas				dblas@genos.frmug.fr.net

-----------[000489][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Nov 1993 14:43:44 GMT
From:      ag257@Freenet.carleton.ca (Ross Macgillivray)
To:        comp.protocols.tcp-ip
Subject:   Interfacing Beame&WhiteSide for Windows to OS/2 - SLIP


I'm trying to connect a Windows Client Machine to an OS/2 Server
Machine via a SLIP connection.   The Windows machine is running
Beame&Whiteside TCP/IP and NFS for Windows and the OS/2 machine
is running OS/2 TCP/IP v2.0.

I can get the B&W machine to dial out and the OS/2 does answer the
call and after that nothing connects.  The B&W machine can PING
itself, but it can't PING anything else.

Are there any trace utilities in the B&W package?  I can't seem
to find any.

If anyone else has tried to set up this configuration or has
any suggestions they would be most welcome.

Ross MacGillivray
email:  rossmac@aol.com

-----------[000490][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 93 20:59:49
From:      frank@manua.gsfc.nasa.gov (Frank Chen)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Xappeal 1.4 and SLIP

I also installed Xappeal 1.4 with SLIP packet driver. The program ran and
got to the xdm server but then immediate failed with segmentation fault.
The second try showed something about no space on enviromment. So I increase
the environment space. And the third try gave me exact the same segmentation
fault.

Following is the info in SYSLOG file of the xdm server(I try 2 different
machines) and the segmentation fault message from PC(in file ERRORS).
My PC is 386DX/40 with 4MB and clone paradise SVGA board.

-------- SYSLOG of host manua -------------------------------------------------
Nov 27 16:57:28 manua xdm[22832]: fatal IO error 120 (Connection reset by peer)
-------- SYSLOG of host calval ------------------------------------------------
Nov 27 16:53:57 calval xdm[27812]: Hung in XOpenDisplay(slip01.gsfc.nasa.gov:0), aborting
Nov 27 16:53:57 calval xdm[27812]: server open failed for slip01.gsfc.nasa.gov:0, giving up
Nov 27 17:02:27 calval xdm[252]: Unknown session exit: retcode 0, termsig 11, from process 27813
--------- ERRORS of PC slip01 -------------------------------------------------
Segmentation violation in pointer 0x00000028 at 40:4f44
Page fault at eip=4f44
------------------------------------------------------------------------------

-Frank Chen
--
===============================================================================
| Chih-Hung Chen (Frank)                    | email: frank@manua.gsfc.nasa.gov|
| General Sciences Corp.(SAIC)              | fax  : (301) 286-3221           |
| Software Development - SeaWiFS Data System| voice: (301) 286-9531           |
| System/Network         SeaWiFS Project    |                                 |
| NASA/Goddard Space Flight Center          |                                 |
| Code 970.2                                |                                 |
| Greenbelt, Maryland 20771                 |                                 |
===============================================================================

-----------[000491][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 1993 20:00:31 +0100
From:      agulbra@nvg.unit.no (Arnt Gulbrandsen)
To:        comp.protocols.tcp-ip
Subject:   DNS - what RRs must the server return?

I've noticed that when I do a nameserver query, I get some extra
info which the server thinks I might need, e.g. when I ask for a
CNAME or MX I also get the corresponding A record(s).  Is this
behaviour part of the DNS protocol (and widely implemented) or is it
just that the name servers around here try to be helpful?

To put it another way, when I want to resolve an MX record to IP
numbers, do I need code to do an extra query in case the MX query
doesn't return the A's in the AR field?

--Arnt

-----------[000492][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 93 22:04:43 GMT
From:      fisque@eden.rutgers.edu (Stanislaf Phisque)
To:        comp.protocols.tcp-ip
Subject:   configuring MacPPP and MacTCP for login to RUNet...

need help configuring MacPPP and MacTCP for remote login into RUNet Unix accounts... 
basically want to be able to establish network access, for such things as Xwindows, NCSA telnet, IRC, etc...  i know this can be slavishly slow, but it's more for the exploratory nature, and in preparation for the acquisition of a 14.4 modem which will make things bearable..

-thanx in advance

-stan

-----------[000493][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Nov 1993 02:35:33 GMT
From:      chrisl@jove.acs.unt.edu (Lambright Christian P)
To:        comp.protocols.tcp-ip
Subject:   How to get TCP/IP 'BOOTP' info?

Is there a simple way to get my local system to show me the info that is
transfered around by using simply 'BOOTP'. Meaning.. my tcp/ip address,
the subnetmask, my network gateway's IP address, primary and secondary name-
server's address, network's broadcast address, along with my domain name?
I have a comm program that requires this info (I think BOOTP may not be 
doing it's job) and I can't figure out how to get it if I can't get to the
sysop. Another system I've seen seems to echo this info to the screen but
I can't seem to get this one to. Any help will be appreciated.

-----------[000494][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 1993 05:37:52 GMT
From:      wpeng@cs.sunysb.edu (Wenjie Peng)
To:        comp.protocols.tcp-ip
Subject:   when arp can not resolve an address?

Hello,

I am working on a project using  386FreeBSD. This question is related to how
arp works.  

When an IP packet is sent, its address need to be translated to ethernet address.
( assume we are connectted by ethernet). Usually it need to call the arpresolve()
to get the address. But when the arp can not resolve the address soon, it just 
return zero. What bothers me is what happen then, since the packet mbuf chain
is took over by arp. If arp get the answer from the dst port later. Will it do
anything to the mbuf. Or it only update the arp table?

Forgive me if this question is naive. 

Wenjie 




-----------[000495][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Nov 1993 20:54:57 CST
From:      Bob Brown <BBROWN@HARPERVM.BITNET>
To:        comp.protocols.tcp-ip
Subject:   need freeware/shareware telnet w/stack for our school

We are just migrating to the unix environment at our college, and we will
need to set up our labs of msdos machines to be able to telnet into our
unix hosts...  we cant afford to buy a full tcp/ip package for them..

Most of them have cabletron cards, some have western-digital or SMC cards..

We dont have a protocol stack on these pcs...so we need something that
includes the stack and telnet (ftp=nice but not necessary yet)..

We have the NCSA TELNET for MAC which does the job great on macs..

the msdos version doesn't seem to support our ethernet cards though..

Thanks for the help...please send responses via email..

-boB
----------------------------------------------------------------------
BBROWN@HARPERVM.BITNET     ####  ####    Bob Brown
Harper Community College   ##  ##  ##    Systems Programmer
Palatine IL USA            ####  ####    Saved by grace
(708) 925-6832 - Voice   (708) 925-8060 - Fax

-----------[000496][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Nov 1993 17:03:24 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: PPP on SATELLITE link

In article <93330.091023HANK@vm.biu.ac.il> Hank Nussbacher <HANK@vm.biu.ac.il> writes:
>
>We run a 128kb satellite line from Israel to the USA and ever since we
>converted to PPP (from HDLC) we have had problems with automatic
>line restarts with cisco routers.  Previously with HDLC, if the telco
>or PTT took the line for testing or resync, as soon as they returned
>the line the line would start working.  Now with PPP, the line has to
>be usually manually restarted with shutdown/no shutdown.  ...

That's a bug, shortcoming or mis-configuration of your PPP implementation
or installation.  Talk to Cisco.

There is nothing in the PPP protocol that prevents its use on leased lines.
On the contrary, much of the excessive (from my dial-up perspective)
complexity of PPP is to support leased lines.


Vernon Schryver    vjs@rhyolite.com

-----------[000497][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 1993 00:45:04 GMT
From:      dima@wariat.org (Dimitry A. Sazonov)
To:        comp.protocols.tcp-ip,comp.os.386bsd.questions
Subject:   bpf(4) examples, Where?

Hello world,

I build FreeBSD kernel with bpf (Berkeley Packet Filter), and
what should I do next to play with bpf? man bpf(4) says that 
somebody should connect interfaces, load filter 'programs' using ioctl, and so on..
Where I can find examples of such programs? Is any other documentation
available except the manual? 

--
Best Regards, 
Dmitry      

-----------[000498][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 1993 09:15:11 -0500
From:      aem@symbiosis.ahp.com (a.e.mossberg)
To:        comp.protocols.tcp-ip
Subject:   Re: WHOIS (INTERNIC REGISTRATION)

perlman@zeno.fit.edu (Marshal H. Perlman) writes:

>If a system (?) or company is listed in the INTERNIC list, does that
>mean it is on the Internet as we are (i.e. TCP/IP or similar) or 
>something totally different?


No. All it means is that they have an ip network assignment from NIC. It
does not mean they have an operational network, are connected to
Internet, or have any given service (e.g. SMTP)


>ABC TV Network Group (NET-ABCTVNETWORK)
>   433 Hackensack Avenue
>   Hackensack, NJ 07601
 
>   Coordinator:
>      Nemecek, Stephen  (SN4)  [No mailbox]
>      (201) 646-7410
 
>This shows ABC is linked to the net some how, but being there is not
>an internet mail address (as we know it <G>) does that mean that is
>used for internet ABC traffic with "ABC PROTOCOL"? 


No, it doesn't mean that they are connected to Internet. It means that
Stephen Nemecek applied for and received a Class B network address from
NIC on behalf of ABC TV. Whether or not they have any proprietary
protocols flowing is best answered by a call to Stephen Nemecek.


aem

-- 
andrew mossberg * symbiosis corporation * miami florida * 305-597-4110
fax: (305) 597-4002 * MD5OfPublicKey: 15784D117CC103912AEC427A3A99BA83

-----------[000499][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 93 00:56:21 GMT
From:      vandys@cisco.com (Andrew Valencia)
To:        comp.protocols.tcp-ip,comp.os.386bsd.questions
Subject:   Re: bpf(4) examples, Where?

In <2dbgmg$27f@gazpacho.wariat.org> dima@wariat.org (Dimitry A. Sazonov) writes:

>I build FreeBSD kernel with bpf (Berkeley Packet Filter), and
>what should I do next to play with bpf?

I think tcpdump uses BPF.  Have a look at its source.  My FreeBSD system
isn't powered on right now, but it'll be over in /usr/src/*/tcpdump, most
likely.

					Andy

-----------[000500][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 93 01:18:59 GMT
From:      fisque@eden.rutgers.edu (Stanislaf Phisque)
To:        comp.protocols.tcp-ip
Subject:   PPP and Solaris..  (want to do remove Mac X session)

having trouble getting PPP to connect with my host server at Rutgers..
i keep getting a 'Link Dead' error and the documentation on the host is sparse, as well as the docs with MacPPP.  Any help from those who have had trouble in the past with something of this sort as well..

-stan

-----------[000501][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 93 01:42:16 GMT
From:      pug@cs.curtin.edu.au (Greg Barron)
To:        comp.protocols.tcp-ip
Subject:   Re: PD Network Monitor/Analyzer wanted

pug@cs.curtin.edu.au (Greg Barron) writes:

>mik@heike.informatik.uni-dortmund.de (Michael Kienle) writes:
 
>>Hi netlanders,


>Packetman: packet analyser				      26th October 1993
>--------------------------				      -----------------
 
>Packetman is a retrospective Ethernet packet analyser. This tool allows
>the capture and analysis of an Ethernet packet trace.

[stuff deleted]

For those of you that wanted to know, the ftp address is

ftp.cs.curtin.edu.au in pub/netman/[dec-mips|sun4c]

And yes, I am a moron not not putting that in there in the first place.
--
Greg
           Greg Barron, pug@cs.curtin.edu.au, School of Computing
          Curtin University of Technology, Perth, Western Australia

"The ZZR-1100 remains the big, fast, versatile bike for the rider with a 
regular pillion passenger or the desire to humiliate just about every
other road user who attempted to match its straight line acceleration" - REVS

-----------[000502][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Nov 1993 01:49:15 GMT
From:      nirad@ceu.uq.oz.au (Nirad Sharma)
To:        comp.periphs.printers,comp.protocols.tcp-ip
Subject:   printer server for ethernet - 4/5 parallel printers

Can anyone supply me with the names of products and their (Australian)
suppliers that attach to the ethernet,  understand unix lpd (over tcp/ip)
and can feed 4 (5 would be nice) parallel printers ?  I think that we
have outgrown our PC-based printer server.

Fax/phone #s and pricing would be appreciated.  Thanks,
--
Nirad Sharma  (nirad@ceu.uq.oz.au)			Phone : (+61 7) 365 7575
Continuing Education Unit				Fax :	(+61 7) 365 7099
The University of Queensland.  QLD  4072.  AUSTRALIA

-----------[000503][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 93 02:07:56 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP options for video

In article <CH03Hy.KGG@lut.fi> molin@kalkkaro.cc.lut.fi (Kim Molin) writes:
> I'm looking for some options for TCP that could leave off the checksum
> calculation. Are there any standards (RFC's) available concerning my problem ?

There is no standard for this (yet?).  However, there is a documented,
working method for doing this, which takes advantage of the Zweig and
Partridge alternate checksum option to negotiate use of a checksum
type of none atall (no checksum is done on that connection ever again).

We implemented software that would negotiate checksums off both for
the case you describe and for the case when packets are sent only over
a single LAN that supports a hardware CRC check.

Recently, using the same software in a preliminary port to OSF/1,
we have seen 215 Mb/s across the loopback interface on a 
DEC Alpha 3000/500.

Detailed info, an implementation for Ultrix, and an undebugged
port to BSD 4.4 alpha can be retrieved by anonymous FTP from

ucsd.edu:/pub/csl/fastnet

The alternate checksum number used has been registered with the
IANA.  I hope to make the OSF/1 port available soon.

						Jon

-----------[000504][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Nov 1993 04:00:46 GMT
From:      perlman@zeno.fit.edu (Marshal H. Perlman)
To:        comp.protocols.tcp-ip
Subject:   WHOIS (INTERNIC REGISTRATION)

[ Article crossposted from alt.internet.services ]
[ Author was Marshal H. Perlman ]
[ Posted on Mon, 29 Nov 1993 03:59:44 GMT ]

I have a question...

If a system (?) or company is listed in the INTERNIC list, does that
mean it is on the Internet as we are (i.e. TCP/IP or similar) or 
something totally different?

For example:

%whois ABC

ABC TV Network Group (NET-ABCTVNETWORK)	ABCTVNETWORK		    167.13.0.0

%whois NET-ABCTVNETWORK

ABC TV Network Group (NET-ABCTVNETWORK)
   433 Hackensack Avenue
   Hackensack, NJ 07601

   Netname: ABCTVNETWORK
   Netnumber: 167.13.0.0

   Coordinator:
      Nemecek, Stephen  (SN4)  [No mailbox]
      (201) 646-7410

   Record last updated on 14-Apr-93.

----

This shows ABC is linked to the net some how, but being there is not
an internet mail address (as we know it <G>) does that mean that is
used for internet ABC traffic with "ABC PROTOCOL"? 

Please send EMAIL if you know.
-- 
  |o| Marshal Perlman                       Internet: perlman@cs.fit.edu |o|
  |o| Academic and Research Computing Services (ARCS)        IRC: Squawk |o|
  |o| Florida Institute of Technology                Private Pilot, ASEL |o|
  |o| Pager: 407/455-4809          Member: AOPA/AAAE/Goodyear Blimp Club |o|
-- 
  |o| Marshal Perlman                       Internet: perlman@cs.fit.edu |o|
  |o| Academic and Research Computing Services (ARCS)        IRC: Squawk |o|
  |o| Florida Institute of Technology                Private Pilot, ASEL |o|
  |o| Pager: 407/455-4809          Member: AOPA/AAAE/Goodyear Blimp Club |o|

-----------[000505][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 1993 14:12 -0500
From:      holdrege@eisner.decus.org (Matt Holdrege)
To:        comp.protocols.tcp-ip
Subject:   Re: WHOIS (INTERNIC REGISTRATION)

In article <CH8J5A.H6p@zeno.fit.edu>, perlman@zeno.fit.edu (Marshal H. Perlman)
writes...

>If a system (?) or company is listed in the INTERNIC list, does that
>mean it is on the Internet as we are (i.e. TCP/IP or similar) or 
>something totally different?

Many companies register with the NIC long before they ever get on the net. The 
intention is that they will, someday, be on the Internet.

-matt@phs.com

-----------[000506][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Nov 1993 09:14:38
From:      stangel@lilly.com (Mike Stangel)
To:        comp.protocols.tcp-ip
Subject:   Re: Why does HPLJ 4si eject blank page?

ACU00JTF@unccvm.uncc.edu writes:

>Why does the HPLJ 4si eject a blank page everytime a document is printed?
>Can anyone tell me how to make this stop? - Thanks

This is not really the best newsgroup for this, but since it's here, I'll 
field the question...

If you're on a network, check the network printer driver (on the print server) 
for a "form feed" option; you probably want this OFF.  If the printer is 
connected directly to a PC, I'm not sure; I looked on my 4si menus for a Form 
Feed, but couldn't find it.  I'd suggest paging through the menus for it.

Mike
-----------------------------------------------------------
Mike Stangel            | "I can't kill the man I love!"
Eli Lilly and Company   | "Then kill the one you're with!"
stangel@lilly.com       |            -Crowe T. Robot, MST3k
-----------------------------------------------------------

-----------[000507][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 93 15:37:25 PST
From:      jaf@th.gov.bc.ca (Jeremy Fichtner)
To:        comp.protocols.tcp-ip
Subject:   Need DOS BOOTP server (FREE!?)

Greetings,

Does there exist a DOS BOOTP server that works with a 3c503 and can fit on a floopy?
I need to configure a slew of remote hubs for SNMP management and this seems a better
way than sending a tech with a laptop to configure the IP addressing individually!

Any thoughts, help etc would be warmly welcomed!

Regards,
---
_______________________________________________________________________________
Jeremy Fichtner				jaf@vict0225.th.gov.bc.ca
Systems & Network Analyst		ua889@freenet.victoria.bc.ca
Ministry of Transportion & Hwys		Victoria B.C. Canada
(...speaking for myself of course!)


-----------[000508][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Nov 1993 09:55:26
From:      fks@ftp.com  (Frances K. Selkirk)
To:        comp.protocols.tcp-ip
Subject:   Re: IP multicast

In article <LAURENCE.93Nov24120947@laurence.mvision.com> laurence@laurence.mvision.com (Laurence Crutcher) writes:

> I've seen a number of questions regarding IP multicast capabilities
> on hosts and routers, but no replies.
> 
> I would like to know from computer and network vendors when/if they
> plan to support IP multicast together with IGMP etc.


PC/TCP for DOS 2.3 (scheduled for release December 1) supports IP
multicast. 

--
Frances K. Selkirk		                                fks@ftp.com
FTP Software, Inc.       Technical Support            (800) 382-4FTP
---------------------------------------------------------------------
 Get our support newsletter from      | FTP support - support@ftp.com
 vax.ftp.com or our BBS (508-659-6240)| FTP sales   - sales@ftp.com


-----------[000509][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 1993 08:56:27 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: documents on CIDR or supernetting

In article <16C908E8A.SURU@TWNMOE10.Edu.TW> SURU@TWNMOE10.Edu.TW writes:
     
        Anybody please direct me to some documents on CIDR (Cross Inter-
    Domain Routing) or the machanism used by supernetting? Thanx.
     
Suggest you start with RFC 1519.

Tony
     
     



-----------[000510][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Nov 1993 09:14:42 GMT
From:      ucacjon@ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP options for video


another useful option would be to allow delivery of missequenced packets....

we wrote a note on a simple tcp extension to permit this a while back (basicaly, the TCP
operates almost exactly as normal, but acks significantly out
of order packets so the send  window advances with time - though you still need the sender
to notice loss and do backoff and so on (and adapt video coding compressio nrate
 accordingly)

its pretty easy (you need to pass up sequence numbers with read completions
 to receiver...
what it does permit is a more steady variation of  video - however, there are far
more sensible approaches to sending video on the internet (c.f. rem-conf@es.net and other
 lists), so we stopped doing such horrible violence to TCP (including multicast extensions
which are a nightmare!!)

-- 
jon crowcroft (hmmm...)

-----------[000511][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Nov 1993 12:40:04 GMT
From:      steven@unipalm.co.uk (Steven Vincent)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: "large security gap in the Internet"

kudzu@netcom.com (Michael Sierchio) writes:

>In article <august-221193074523@august.cerfnet.com> 
>    august@cerfnet.com (Richard B. August) writes:
 
>>The name VIRUS connotes something that is ALIVE rather than what a computer
>>"virus" really is.  The average lay person has absolutely NO CLUE as to
>>what a "computer virus" is or might be.
>>

The lay person has no idea what a virus is either.

>Nobody's definition of a virus says it's alive -- viruses contain DNA
>(or RNA) and require a living host -- they have some, but not all
>of the necessary characteristics for life.

A virus is defined in many Genetic's texts as a self replicating piece
of (DNA | RNA) code that replicates its self by the use of its hosts
machinery and protects its self by means of a protein coat.  

Apart from the bit about protein coat and the code being RNA or DNA I
think that this describes a computer virus quiet well. Virus is a far
more accurate term than Trojan. 

 Enough for comp.protocols.tcp-ip take it to comp.virus


-----------[000512][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 1993 12:16:01 +0200
From:      barrett@lucy.ee.und.ac.za (Alan Barrett)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,za.net.misc
Subject:   PC-Route RIP bugs bite with multiple paths between routers

[Careful with those followups!]

Here's an interesting synergy between two minor bugs in PC Route's
RIP implementation.  It also explains why routing to the 192.70.237.0
network has been weird recently.


First some background information about the two minor bugs:

If a RIP-speaking router has an internal route to a subnet of a
subnetted network, and announces that route over an interface which
is on a different network, then the announcement is supposed to be
adjusted to refer to a route to the entire subnetted network rather than
just to a single subnet.  For example, if a router R1 knows a route to
subnet N1.S1 of network N1, and announces that route over an interface
connected to a different network N2, then what is announced should be a
route to the entire network N1, not just to subnet N1.S1.  PC-Route does
this.

If a RIP-speaking router has a internal routes to several subnets of
a subnetted network, and announces the routes over an interface which
is on a different network, then the announcement is supposed to be
adjusted to refer to a single route to the entire subnetted network
rather than several routes to several subnets.  (Furthermore, I believe
that the appropriate routing metric to be announced for this combined
route should be derived from the routing metric internally associated
with the "closest" subnet.)  For example, if a router R1 knows a route
to subnets N1.S1 and N1.S2 of network N1, and announces those routes
over an interface connected to a different network N2, then what is
announced should be a single route to the entire network N1, and the
metric associated with this announcement should be derived from the
internal metric for whichever of N1.S1 or N1.S2 is "closer" to the
router R.  In this situation, PC Route announces several routes to
the entire network: a separate announcement for each internally known
subnet, with a metric derived from the internal metric for that subnet.
I have long known of this problem with PC Route, but considered it no
more than a minor nuisance, so had not bothered to fix it.

When a RIP-speaking router is attached to a subnetted network, it should
ignore incoming announcements of routes to the entire network.  Such
announcements might be received over an interface that is attached to a
network distinct from the subnetted network in question.  For example,
if a router R1 receives an announcement over an interface connected
to network N2 or a route to network N1, and the router R1 knows that
network N1 is subnetted, then it should ignore that announcement.  PC
Route instead treats the announcement as a route to subnet zero (an
illegal subnet) of the subnetted network.  I have long known of this
problem with PC Route, but considered it no more than a minor nuisance,
so had not bothered to fix it.


Now, a scenario where synergy between those minor nuisances becomes a
serious problem:

Suppose that router R1 has three interfaces, connected to subnet N1.S1
of network N1, to network N2, and to network N3.  Suppose that another
router R2 has two interfaces, connected to network N2 and to network
N3.  Initially, router R1 has an internal route with metric 0 to subnet
N1.S1.  Router R1 will broadcast announcements onto networks N2 and
N3, saying that it has a route of metric 1 to the entire network N1.
Router R2 will receive those broadcasts in some order.  Supposing R2
receives the broadcast from network N2 first, it will add an internal
route to network N1 with metric 1 via its interface on network N2, and
will ignore the subsequent announcement received over network N3.

Shortly thereafter, router R2 will broadcast routing announcements onto
networks N2 and N3.  The announcement sent by router R2 to network
N2 will not include a route to network N1 (because of split horizon
processing), but the announcement sent to network N3 will include
a route to network N1 with metric 2.  Router R1 will receive the
announcement over network N3 of a route to network N1, and should
really ignore it, but instead it treats it as a route to subnet N1.0.
Now, router R1 has an internal route to subnet N1.S1 with metric 0 (a
directly attached subnet), and a route to subnet N1.0 with metric 2
(learned from router R2 via network N3).  Later, when router R1 makes
another routing broadcast on network N2, it should merge these two
routes into a single announcement of a route to network N1 with metric
1, but instead it announces each separately, as a route to N1 with
metric 1 and another route to network N1 with metric 3.  When router R2
sees these announcements, it will update its internal routing tables to
show a metric of 3 instead of a metric of 1 for its route to network N1.

This process continues over time, with router R1's broadcasts to network
N2 always anouncing both a route to network N1 with metric 1 and another
route to network N1 with a metric that gradually counts to infinity (or
RIP metric 16).  When the second route's metric has reached infinity, it
is held there for a while before being discarded, and the entire process
begins again.  If any other routers are attached to networks N2 or N3
(in addition to routers R1 and R2), then they will also see the strange
routing to network N1.


How that applies to the recent routing problem with 192.70.237.0:

Let R1 be a router running PC Route and