The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Thu, 01 Oct 1992 02:38:27 GMT
From:      yozzo@watson.ibm.com (Ralph Yozzo)
To:        comp.protocols.tcp-ip
Subject:   ANSI emulation support using Telnet?

I'd like to telnet from a Unix host to a machine that only 
supports ANSI terminal commands.  What I mean by ANSI 
terminal commands is escape sequences to set the color and position and
other things.

Could someone please explain or point me to information that would
allow me to telnet to the host and get the correct interpretation of the
escape sequences?

-- 
Ralph Yozzo (yozzo@watson.ibm.com)  
From the beautiful and historic Mid-Hudson Valley area of NY state

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Oct 1992 02:55:55 GMT
From:      marka@syd.dms.CSIRO.AU (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP usage (test)

In article <1485@esl.ESL.COM> nam@bach.esl.com (Nam Nguyen) writes:
>Questions:
>
>  1.  Was I right when I installed SLIP on both machines.

	Yes.

>  2.  Do I have to "slip-attach" on both machines, or only one?

	Yes, both.

>  3.  How do I test either "ping" or "ftp" using this setup?

	Any IP based application can be used to test the link,
	ping is a good choice.

Have you verified the underlying physical circuit, i.e. add a getty to
one end and tip out? Did you use a null modem cable?

What is the output of "netstat -I", "netstat -r -n", and "ifconfig -a"?

Try running "netstat -I interface -i 5" and see if packets are being
queued on the output queue will pinging the remote host.

Are there any messages in /usr/adm/messages relating to slip-attach?

Mark.

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Oct 1992 08:48:47 GMT
From:      rob@icarus.inmos.co.uk (Robin Pickering)
To:        comp.protocols.tcp-ip
Subject:   Re: How to write TCP/IP specs in a procurement

shafer@CS.ColoState.EDU (spencer shafer) writes:
>
>  1. Does it make sense to reference the RFC's, i.e. does it do
>     anything?
>     2. What RFC's should I use?

The overiding standards for TCP/IP implementations are:

RFC1122  Braden, R.T.,ed.  Requirements for Internet hosts - communication 
         layers.  1989 October; 116 p. (Format: TXT=295992 bytes)
and
RFC1123  Braden, R.T.,ed.  Requirements for Internet hosts - application and
         support.  1989 October; 98 p. (Format: TXT=245503 bytes)
         
The former covering the operation of the TCP/IP stack itself and the latter
covering the operation of ``standard'' applications (FTP, MAIL, TELNET etc).

The standards contain two levels of specification for the operation of the 
protocol: MUST (MUST NOT) and SHOULD (SHOULD NOT). To be fully compliant
an implementation must obey all of these specifications. In certain
applications, because of their nature and the device
on which they are implemented, there may well be a good justification for not
implementing one or more of the SHOULD directives. In this case,
the implementation is said to be conditionally compliant.

All this is fully explained in the above documents.

--
   Rob.

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Thu, 01 Oct 1992 17:31:11
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: what does completion of write() really mean?

In article <BvEGM1.6Kq@watserv1.uwaterloo.ca> erick@demorgan.uwaterloo.ca (Erick Engelke) writes:

    In article <920928162413@cream.ftp.com> jbvb@ftp.com writes:
    >
    >... In PC/TCP for DOS, it means that all the data has been transmitted,
    >but not necessarily acknowleged by the receiving TCP.  
    
    So does that mean you satisfy Nagle by blocking on subsequent writes?

I should have said "...except for any partial segment which may be delayed
due to the Nagle algorithm".

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488


-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 92 14:04:19 GMT
From:      mc@math.math.mv.dupont.com (Matt Cunningham-Software Development)
To:        comp.protocols.tcp-ip
Subject:   SLIP interface - SUN routing


A problem I've recently encountered is when using SLIP (Serial Line Internet
Protocol) it appears that when the serial communication channel is initialized,
the route is propogated to all machines on the network by the route daemon on
my workstation (SUN 4).  Is there a way to have routed ignore specified routes
(possibly a flag to the 'socket()' call), I've tried every possibility I could
think of with no luck.  SUN tech support has provided no help to any facilities
they may have.  If anybody has found a way around this please help out.

                                                Matt Cunningham
                                                mc@mv.dupont.com

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Oct 92 14:30:55 GMT
From:      sheth@a.cs.okstate.edu (SHETH UMANG RAJNIK)
To:        comp.protocols.tcp-ip
Subject:   A list of Frquently Asked Questions

Could someone forward me a list of Frequently Asked Questions ( FAQs )
for this newsgroup? ALternatively--is there any ftp site from where
I can obtain FAQs?

Please send your response at my e-mail address ( sheth@a.cs.okstate.edu )

TIA,
Umang

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 92 15:46:37 GMT
From:      steve@dsnsun.ericsson.se (Steve Reynolds)
To:        comp.protocols.tcp-ip
Subject:   IPX tunneling via rfc1234

Can anyone help me with information on RFC1234 for tunneling of IPX traffic
through IP networks?

I have been asked to carry some IPX traffic over an IP net and this spec looks
too simple to be true!

Questions

Is anyone else implementing this?
Does it really work or are the constraints imposed by address mappings a
problem?

Thanks in advance 

Steve Reynolds
mail steve@dsnsun.ericsson.se

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 92 18:49:17 GMT
From:      bourkej@ul.ie
To:        comp.protocols.tcp-ip
Subject:   telnet with a script language ?

Howdy,

Has anyone got a UNIX telnet with a script language.

john


-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Oct 92 20:17:35 GMT
From:      mohanram@wsl.dec.com (Narayan Mohanram)
To:        comp.protocols.tcp-ip
Subject:   Re: what does completion of write() really mean?

In article <1992Oct1.150740.25886@adobe.com>, yost@adobe.com (David Yost) writes:
|> Which then points up a question I have:
|> 
|>    Why is there no call in the sockets interface to
|>    tell the kernel to push out queued data (with or
|>    without acks from the remote end)?  The fsync() call
|>    would be a reasonable choice, but it apparently
|>    doesn't do anything on a socket.
|> 
|>  --dave yost

The concept of sync (unix) does not really apply here. `sync' is for
forcing out buffered data that the operating system is deliberatly (sp?)
delaying to improve system performance. In the socket case, the data is
not being delayed by the os. it is being delayed by the protocol/network
bandwidth. the os does attempt to send out data without delaying (exect
for those implementing nagle..). without staring tcp/ip/osi wars, if the
os does not give a means of determining if the data got to the otherside,
the caller to write should put enough context in the data to determine this.

All you can tell with a select for write is to see if you can write more,
and not if all the data has drained. I don't know of a direct way (other than
hacks) to get the so_snd.sb_cc value from the kernel.

narayan
-- 
USnail: 909 W. Olive			***************************************
	Sunnyvale, CA 94086		* Life is a Reach                     *
Phone: 408-738-4165(H)/415-688-1559(W)	* 	Then you jibe		      *
Email: mohanram@pa.dec.com		***************************************

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Oct 1992 21:37:58 GMT
From:      kudzu@netcom.com (Michael Sierchio)
To:        comp.protocols.tcp-ip
Subject:   What's this entry in my /etc/services file?

I ran across this in /etc/services:

efs		520/tcp				# for LucasFilm

Any insights, anyone?
-- 
+--------------------------------------------------------------------------+
|  Michael Sierchio                          1563 Solano Avenue, Suite 123 |
|  kudzu@netcom.com                                Berkeley, CA 94707-2116 |
+--------------------------------------------------------------------------+

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 92 21:59:59 GMT
From:      wagner@bodie.cs.unc.edu (Michael Wagner)
To:        comp.protocols.tcp-ip
Subject:   RPC svc_getcaller()

I am working on an RPC based distributed graph server.
On the server side, in some of the procedures, the
server will need to be able to distinguish clients.
I found the call svc_getcaller((SVCXPRT *)).  I think
I've used this correctly:

struct sockaddr_in old_caller;

int
check_caller(CLIENT * cl)
{
        struct sockaddr_in *caller = svc_getcaller((SVCXPRT *) cl);
        if ((caller->sin_family == old_caller.sin_family) &&
            (caller->sin_port == old_caller.sin_port) &&
            (caller->sin_addr.s_addr == old_caller.sin_addr.s_addr)) {
                // cout << "callers are the same\n";
                return (1);
        } else {
                cout << "callers are different\n";
                old_caller = *caller;
        }
        return (0);
}

int            *
open_1(UUID_int * u, CLIENT * cl)
{
        int             comp = check_caller(cl);
}

But, when I have two clients talk to the server, in which their
calls should be intertwined, I keep getting a "callers are the same\n"
message.  I modified the check_caller() routine so that it 
printed out the family, port address, and s_addr of the caller,
and I always got the same number.  (and the s_addr is always
0.0.0.0).

Am I using this call incorrectly?

Mike


-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Oct 1992 00:09:58 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   fast cray tcp/ip

People were asking a few weeks ago for details on the fast cray implementation.
I had reason to dig up the article today -- it is in the January '91 issue
of ACM SIGCOMM Computer Communication Review.

Craig

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Oct 1992 02:10:57 GMT
From:      hsiung@csie.nctu.edu.tw (guest-user)
To:        comp.protocols.tcp-ip
Subject:   is there FAQ for this group

Hello there,
    Sorry that I didn't see any information regarding the FAQ for this
group since I am new to this group.
    Can any one out there tell me where to get one?
Thanks in advance.
hsiung@csie.nctu.edu.tw


-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 92 02:37:33 GMT
From:      tsukako@sdl.hitachi.co.jp (Masato Tsukakoshi)
To:        comp.protocols.tcp-ip
Subject:   Re: A list of Frquently Asked Questions

Sorry, this is not an answer.

In article <1992Oct1.143055.28914@a.cs.okstate.edu> sheth@a.cs.okstate.edu (SHETH UMANG RAJNIK) writes:
>Could someone forward me a list of Frequently Asked Questions ( FAQs )
>for this newsgroup? ALternatively--is there any ftp site from where
>I can obtain FAQs?

I also want to get this list (if it exist).

>Please send your response at my e-mail address ( sheth@a.cs.okstate.edu )

So, if you get some information about it, would you please post to this
newsgroup?

--
 Masato Tsukakoshi 
 Systems Development Laboratory, Hitachi, Ltd.
 e-mail:tsukako@sdl.hitachi.co.jp


-- 
--

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Oct 1992 03:32:03 GMT
From:      shlam@eng.ie.cuhk.hk (Alan S H Lam)
To:        comp.protocols.tcp-ip
Subject:   Can dialupip20 can talk with slip?


I am going to installed dialupip20 at DEC workstation.
I wonder if the dialupip20 can talk with the 386BSD
slip driver through modem?

If anyone know the answer, please send me a e-mail. 
I will very appreciate it.

Thanks.

--
Alan S. H. Lam
Department of Information Engineering, CUHK, Hong Kong
E-mail: shlam@eng.ie.cuhk.hk 
Tel: (852) 609 7975 Fax: (852) 603 5032

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Oct 1992 03:57:08 GMT
From:      yost@adobe.com (David Yost)
To:        comp.protocols.tcp-ip
Subject:   Re: what does completion of write() really mean?

In article <1992Oct1.201735.5096@PA.dec.com> mohanram@wsl.dec.com (Narayan Mohanram) writes:
>The concept of sync (unix) does not really apply here. `sync' is for
>forcing out buffered data that the operating system is deliberatly (sp?)
>delaying to improve system performance. In the socket case, the data is
>not being delayed by the os. it is being delayed by the protocol/network
>bandwidth. the os does attempt to send out data without delaying (exect
>for those implementing nagle..).

And what about "those implementing nagle" or whatever?
It is well known that buffering is useful for
performance in the case of small or irregular-sized
writes, at least as an option.  Thus when designing an
I/O API one should provide a push (a.k.a. flush or sync) call.

 --dave yost

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Fri, 02 Oct 1992 09:10:17 GMT
From:      paul@atlas.abccomp.oz.au (Paul Brooks)
To:        comp.protocols.tcp-ip
Subject:   Query: Possible bug in SunOS 4.1 Telnet server

While trying to fix some apparent problems with my Telnet code handling
Urgent Data, I think I have found a bug in the SunOS 4.1 Telnet server,
and I am hoping others can:
	a) Confirm that what I describe is real, and
	b) Give some indication about how widespread the problem is - 
	   what other BSD-based systems have the same code.

Basically, while some large output is coming back to the telnet client I
send the Telnet "Abort Output" command (actually IAC AO IAC DM as Urgent Data).
Sure enough the Sun comes back with Urgent Data, but when the urgent data
runs out (the urgent data point in the stream is reached) there is no Data Mark
(IAC DM). Now RFC 1123 (page 18) states:

"When it receives a Telnet AO command, a Server Telnet MUST send a Telnet
"Synch" sequence back to the user, to flush the output stream."

(where a "Synch" sequence is just IAC DM with the 'DM' octect marked as Urgent)

and the Telnet RFC (RFC 854) on page 9 states:
"If TCP indicates the end of Urgent data before the DM is found, TELNET should
continue the special handling of the data stream until the DM is found."

	Now the Sun never sends a DM, so my Telnet client sits patiently dumpingincoming data forever. No DM ever appears, either before, at or after the
Urgent data pointer.

	Suggestions, anyone?

-- 
Paul Brooks               |paul@abccomp.oz.au      |LIFE is a bowl of cherries:
TurboSoft Pty Ltd         |pwb@newt.phys.unsw.oz.au|  sweet at first, until you
248 Johnston St. Annandale|                        |  reach the pits.
Sydney Australia 2038     |ph: +61 2 552 3088      |  

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Oct 1992 09:19:16 GMT
From:      markus@edfd.uucp (Markus Gruenkorn (MAGIC))
To:        comp.protocols.ibm,comp.protocols.tcp-ip,comp.protocols.nfs,comp.unix.aix,comp.unix.large,bit.listserv.ibm-main,bit.listserv.ibm-net
Subject:   Re: IBM mainframe/Unix connectivity questions/issues

jcasey@netcom.com (John Casey) writes:

>Hello,
 
>This is my first posting on the internet.  I am an applications
>programmer working for a mainframe applications software company. 
>I have varied experience in the mainframe and unix environments; 
>but am no way considered an expert on either.  Our company is
>starting to look at the unix environment to enhance it's mainframe
>products.  I am on a fact finding mission to deal with the
>connectivity issues between a unix machine and a mainframe (VM/CMS,
>MVS/CICS,...).  I've read some of IBM's brochures on the RS6000 and
>their TCP/IP for the mainframe.  Well, I trust sales brochures just
>about as much as I trust any of the Presidential candidates.  I
>would like to get the scoop from you people, the experts, who have
>actually connected the two machines and are working in a mixed
>environment. 

May be I can help you in describing our environment!
We have a large mixed network based on ethernet !
We are using:
  - As400
  - IBM Mainframe (MVS)
  - different kinds of Unix workstations (Rs600, Sparc, Sgi,..)
  - PC's with OS2 and MS-DOS
  - Apple 
  The communication between all these computers is based on TCPIP
  We installed a TCP/IP Module on our AS400
  The MS-Dos PCD's are using NCSA'Telnet ore PCNFS's
  Our OS2 PC's are using IBM's TCP/IP
  The IBM Mainframe is equipped with a fibronics box for the
  TCP/IP communication.
  Now it is possible to do file transfer in the whole net (using
  TCP/IP)
  We also can do a remote login in nearly every system (excluded
  the MS-DOS' PC's)
  NFS is possible between all systems excluded MVS and AS400.
  We use a second protocol stack on our ethernet for communication
  with the AS400, because needed the functionality of TN5250.
  Therefore we use Communications Manager (OS2) and PC-Support
  (MS-DOS) .
  In my opinion all is working well!


-- 
------ < MAGIC > ------

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 92 10:58:34 GMT
From:      rcjoep@rwc.urc.tue.nl (Joep Brand)
To:        comp.protocols.tcp-ip,bit.listserv.3com-l,comp.dcom.lans.ethernet
Subject:   SUMMARY: NETBuilder II question


Hello,

I recently asked this forum whether it was possible or not to have a 
NETBuilder II forwarding BOOTP packets while IP routing is turned on. I
want to thank those who answered :
	"N. Arunkumar" <nak@NSD.3Com.COM>
	"Peter Mills" <peter@fs2.mcc.ac.uk>
	"Antonis Kyriazis" <antonis@intranet.gr>
	"Mark Reardon" <mwr@tridom.com>


rcjoep> Is it possible to forward BOOTP packets on a 3Com NETBuilder II, 
rcjoep> while IP routing is turned on. The NETBuilder is running software 
rcjoep> version BR5.0 ?
rcjoep> 
rcjoep> I'm using the NETBuilder II to route IP, IPX and DECnet, and to 
rcjoep> bridge other proprietary protocols like LAT and MOP.

The bottum line answer is that it's not possible in release BR5.0, but that
it will be included in release BR6.0, which will be out early next year.

Have a nice day,

-Joep
--
Joep Brand, Eindhoven University of Technology
Computing Center 1.64, +31 40 474394
P.O.Box 513, 5600 MB Eindhoven, The Netherlands

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Oct 1992 16:07:46 GMT
From:      carstede@muug.mb.ca (Eric Carsted)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP driver Vendors Wanted for SPARC and HP machines

In <1992Sep25.162447.21383@mixcom.com> mgic <mgic@mixcom.mixcom.com> writes:


>I've been asked to quickly find and recommend a UNIX machine
>on which to run many concurrent SLIP connections. The connections
>will not be through physical serial ports, but ptys (connected
>to X.25).

We are working on the same problem.

>The systems I am considering are SPARC and the new HP machines.
>(I don't yet know if they already come with a SLIP driver or,
>if so, if it can handle my needs.) The machine also requires
>an X.25 interface.
 
>Stuff deleted cause it goes without saying. (You never know which psudo
port you are connecting to so address allocation must be dynamic.)

We have on our list two possible solutions.

   a) X.25 line into a PAD with the serial lines from then PAD going into a
      terminal server that supports SLIP or PPP.

   b) Gandalf has an all purpose router/terminal server that currently
      supports SLIP for routing purposes.  It is not quite what we are 
      looking for but they are investigating modifying it for our needs.

      The person to talk to there is Evan Caves (evan@gandalf.com). He
      feels that they could put something together in a month.  If more
      people want this kind of product maybe it will raise its' priority.

      
>Recommendations on UNIX machines or SLIP vendors anyone?
To the best of my knowledge HP does not support this over X.25,  they are
investigating this right now.

Just one note, you will have to configue the X.25 connection to send a packet
after lets say 1/10 of a second time out because there is no return or send
char.

>Thank you for your help.

Your welcome;

Eric Carsted
Senior Systems Engineer
Systemhouse  (204) 945-3509
Winnepeg,Mb
carstede@muug.mb.ca

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Oct 1992 19:47:25 GMT
From:      rdk@cc.gatech.edu (Bobby Krupczak)
To:        comp.protocols.tcp-ip
Subject:   Free user-space TCP/IP implementations?

Hi!

I was wondering if anyone reading the list knew of a public domain TCP/IP
implementation that runs in user-space?  If so, would you email me a pointer to
the source?

I am working on a project where we are parallelizing protocol stacks to measure
performance speedup.  Anyway, we want to try to obtain some sort of comparison of
results.

Thanks in advance,

Bobby

-- 
rdk@cc.gatech.edu

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Sat, 03 Oct 1992 22:25:43 GMT
From:      Dean.Roth <Dean.Roth@mixcom.mixcom.com>
To:        comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   Anyone using ka9q for UNIX?


Is anyone using the UNIX ka9q TCP/IP software? If so, I'd like
to correspond with you in an attempt to solve some problems.
Thank you.

Dean

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Sat, 3 Oct 1992 23:40:28 GMT
From:      ji@cs.columbia.edu (John Ioannidis)
To:        comp.protocols.tcp-ip
Subject:   Re: How to do real broadcasting?

In article <1992Oct2.153338.27977@Informatik.TU-Muenchen.DE> bonk@Informatik.TU-Muenchen.DE (Thomas Bonk) writes:
>
>
>	Hi
>
>	We have some HP9000/720 Workstations that can comunicate together
>	via TCP/IP and Ethernet.  We are looking for a possibilty, that one
>	process from one workstation can broadcast a huge amount of data
>	to (a lot of) processes on other workstation. It is important for
>	us, that the data appears only once on the Ethernet!
>	We have heard that tools like pvm and express can do broadcasting
>	functionaly, but they simulate it on bases of 1:1 communications.
>

Check out the Coherent File Distribution Protocol, RFC-1235. A sample
implementation should be available on cs.columbia.edu.

/ji

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 939 7029 or 7038
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 1992 18:18:55 -0700
From:      tli@skat.usc.edu (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: netmask follies

In article <1992Oct4.215821.25844@phri.nyu.edu> roy@mchip00.med.nyu.edu (Roy Smith) writes:
    
    	Recently, a Sun-3 (running SunOS-3.5.2) got its netmask changed from
    255.255.0.0 to 255.255.255.0.  Naturally, it stopped being able to talk to
    any machines other than those with the same third octet worth of IP address.
    My question is, how would such a thing happen?  I'm presuming nobody walked
    up to the machine and did an ifconfig, but that something (presumably
    eminating from some misconfigured router?) came by on the network causing
    the machine to change it's netmask automatically.  Can anybody fill me in on
    what might have happened?
    
    	Fixing the problem simply involved doing an ifconfig back to the
    proper netmask, but I'm really curious as to what might have happened, and
    what I might do to prevent it from happening again.

The workstation received a broadcast ICMP Mask Reply.  Further action
depends on where the reply came from.

-- 
Tony Li - Escapee from the USC Computer Science Department          tli@usc.edu
		       The net is not what it seems.

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 92 21:58:21 GMT
From:      roy@mchip00.med.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   netmask follies


	Recently, a Sun-3 (running SunOS-3.5.2) got its netmask changed from
255.255.0.0 to 255.255.255.0.  Naturally, it stopped being able to talk to
any machines other than those with the same third octet worth of IP address.
My question is, how would such a thing happen?  I'm presuming nobody walked
up to the machine and did an ifconfig, but that something (presumably
eminating from some misconfigured router?) came by on the network causing
the machine to change it's netmask automatically.  Can anybody fill me in on
what might have happened?

	Fixing the problem simply involved doing an ifconfig back to the
proper netmask, but I'm really curious as to what might have happened, and
what I might do to prevent it from happening again.

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 1992 13:17:01 -0500
From:      dbrandt@cs.utexas.edu (David Brandt)
To:        comp.protocols.tcp-ip
Subject:   Looking for common problems in TCP implementations

I am looking for references to common problems with TCP
implementations.  I have read "An Analysis of TCP Processing
Overhead" and am looking for similar articles.

Thanks,
David Brandt
dbrandt@cs.utexas.edu


-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 92 13:37:07 GMT
From:      GJAMES@HUSKY1.STMARYS.CA (GJames)
To:        comp.protocols.tcp-ip
Subject:   Beholder/Gobbler/Specter--WHERE???

The tiltle says it all. Where can I find the programs via FTP?

Thanks

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Oct 1992 13:58:28 GMT
From:      fgs@kepler.unh.edu ( F r e D  S l a m A )
To:        comp.protocols.tcp-ip
Subject:   traceroute



	Hi,

	I have a question pertaining to constructing an ip header and
	prepening it to subsequent headers/data. I am aware of the 
	kernel patch required in order to prevent the kernal from 
	istelf prepending an IP header. That is, when using the 
	protocol IPPROTO_RAW. 

	My question is this:	Was the original intent of IPPROTO_RAW 
							to provide a mechanism to allow the
							programmer to manually construct the 
							outgoing packet without the intervention
							of the kernal to prepend a header? 
							When used to recieve data, it allows the
							target to see everything..
							When sending something using IPPROTO_RAW,
							it exhibits the same behavior as IPPROTO_IP
							(without the kernal patch)

	Having only recently subscribed to this newsgroup , I can only
	assume this topic has already been overly addressed. I apologize 
	for being redundant.

									-Thanks
											Fred
-- 
 ===============================================================================
 Frederick G. Slama at >>>>>>>>>>>>>| slama@ctron.com
 The University of New Hampshire <<<| fgs@kepler.unh.edu   F_SLAMA@unhh.unh.edu
 ===============================================================================

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 1992 23:47:39 -0500
From:      yau@cs.utexas.edu (David K.Y. Yau)
To:        comp.protocols.tcp-ip
Subject:   rlogin client

Hi,

I've compiled the rlogin client in Stevens' UNIX Network Programming.
When I tried to run it, I got `rcmd: socket: Permission denied'. On 
reading the book, the reason seems pretty obvious: rresvport, which is 
called inside rcmd, which is in turn called inside rlogin, checks for
superuser privileges before it returns a reserved port. Since I have
no problem doing an rlogin using the original rlogin program, which is
by the way /usr/ucb/rlogin, that means the original rlogin isn't 
compiled from the source in Stevens' book. So how is it different?
Can anyone give me a reply, preferably by email?

Thanks in advance,
David Yau (yau@cs.utexas.edu)


-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Mon, 05 Oct 1992 16:08:06 GMT
From:      merce@xenitec.on.ca (Jim Mercer)
To:        comp.protocols.tcp-ip,aus.wanted
Subject:   Re: AS400s and Suns together

In article <3283@peking.gdwb.oz.au> was@gdwb.oz.au (Warren Stokes) writes:
>IBM are telling us all about how great the TCP/IP suite is for the
>AS400.  We are sceptical.  The interconnectivity between our Sun
>network and this replacement machine is essential.
>
>Are there any sites our there which are doing this kind of thing with
>Unix boxes and AS400s?  Does anyone have any comment on the quality of
>the IBM AS400 TCP/IP suite?

we have an AS/400, several AT&T 3B2's and a CP SysVR4 box here, with a
bunch of PC's on novell, using NCSA/CUTCP telnet to access the unix boxes.

IBM's TCP on the 400 works.  it is a bit ugly, and some things are broken,
by as far as FTP is concerned it works pretty well.

telnet into the AS/400 requires tn3270 or tn5250 (the latter is hard to find).

telnet from the AS/400 into the unix boxes is line mode only.

(i'm told that the next release will address this and allow vt100 in/out)

the SMTP stuff into OfficeVision is hideous.  mail does go from A to B,
but the headers are totally munged, and watch out for extraneous control
characters (my favourite being messages ending in "  \000\n" which
busts every MUA we have on the unix side)

given all of that, there are API's that look kinda berkeleyesque for 
RPG and Pascal (and i believe C).

i would encourage others to pick it up and run with it.  if we can get some
kind of cooperative code sharing thing going, we might be able to show
some of the traditional IBM shops what networking is really about.

personally i think an AS/400 would make an excellent news server. 8^)
(they tend to have oodles of memory and disk space)



-- 
[ Jim Mercer   Reptilian Research  merce@iguana.reptiles.org  +1 519 893-6085 ]
[             I don't want to work for a company that has a CIO.              ]
[              Disclaimer! I don't need no stinking Disclaimer!               ]

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Mon, 05 Oct 1992 16:14:35 GMT
From:      Dean.Roth <Dean.Roth@mixcom.mixcom.com>
To:        comp.unix.sysv386,comp.protocols.tcp-ip,biz.sco.general
Subject:   ka9q for SCO UNIX 3.2?


Is a version of ka9q TCP/IP software available for SCO UNIX?

I have found several version of ka9q for "UNIX" and "UNIX SYS 5",
but they do not compile under SCO.

Thank you.

Dean

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 92 16:35:38 GMT
From:      mohanram@wsl.dec.com (Narayan Mohanram)
To:        comp.protocols.tcp-ip
Subject:   Re: what does completion of write() really mean?

In article <1992Oct2.035708.11326@adobe.com>, yost@adobe.com (David Yost) writes:
|> And what about "those implementing nagle" or whatever?
|> It is well known that buffering is useful for
|> performance in the case of small or irregular-sized
|> writes, at least as an option.  Thus when designing an
|> I/O API one should provide a push (a.k.a. flush or sync) call.
|> 
|>  --dave yost

I agree with this. The sematics of write (or send) should be associated with
data going out completely. Sockets do have an Non-Blocking write capability
for buffering data. Or one can invent yet another `network goto' ie. a
setsockopt SO_DRAINWAIT. This can provide you with the required semantics.

(Minor changes to sosend (), and sbdrop to wakeup anybody with this option).

narayan

-- 
USnail: 909 W. Olive			***************************************
	Sunnyvale, CA 94086		* Life is a Reach                     *
Phone: 408-738-4165(H)/415-688-1559(W)	* 	Then you jibe		      *
Email: mohanram@pa.dec.com		***************************************

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 92 16:54:57 GMT
From:      jbvb@vax.ftp.com (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: what does completion of write() really mean?

In article <1992Oct2.035708.11326@adobe.com> yost@adobe.com (David Yost) writes:

    It is well known that buffering is useful for
    performance in the case of small or irregular-sized
    writes, at least as an option.  Thus when designing an
    I/O API one should provide a push (a.k.a. flush or sync) call.
    
With Nagle's algorithm, TCP can almost always Do The Right Thing when
presented with a short write (e.g. either send it immediately or wait
until previously transmitted data is ACKed).  The only case where overriding
Nagle is reasonable is on the local net, where the application developer
(or better, the sysadmin) decides that smoother throughput is worth more
packets.  Overriding Nagle will seriously *reduce* both throughput and
smoothness on a WAN connection through one or more heavily-loaded routers.

Thus, in a perfect world, "Nagle-override-allowed = {local, net_list...}"
would be a configuration item...

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Oct 1992 16:57:59 GMT
From:      elogan@mistxt.oc.com (Ernie Logan)
To:        comp.protocols.tcp-ip,aus.wanted
Subject:   Re: AS400s and Suns together

merce@xenitec.on.ca (Jim Mercer) writes:
>In article <3283@peking.gdwb.oz.au> was@gdwb.oz.au (Warren Stokes) writes:
>>IBM are telling us all about how great the TCP/IP suite is for the
>>AS400.  We are sceptical.  The interconnectivity between our Sun
>>network and this replacement machine is essential.
>>Are there any sites our there which are doing this kind of thing with
>>Unix boxes and AS400s?  Does anyone have any comment on the quality of
>>the IBM AS400 TCP/IP suite?
 
>telnet into the AS/400 requires tn3270 or tn5250 (the latter is hard to find).

Well, Jim, I tend to agree with most of what you said, except that TN5250
is hard to come by. You only need to email info@oc.com, or call or write:

OpenConnect Systems
2711 LBJ Freeway
Dallas, TX 75234
+1 214 484-5200

TN5250 is available for most *IX, VMS, and DOS platforms, including
MS-Windows. Try it, you'll like it! :)

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Oct 92 17:45:41 GMT
From:      radha@yrloc.ipsa.reuter.COM (radha)
To:        comp.protocols.tcp-ip
Subject:   pc-tcp s/w


is there any public domain s/w equvalent to pc-tcp?

radha

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 92 18:00:39 GMT
From:      mc@math.math.mv.dupont.com (Matt Cunningham-Software Development)
To:        comp.protocols.tcp-ip,comp.protocols.snmp
Subject:   Broadcasting - SLIP (Serial Line Internet Protocol)

A problem has been encountered in using SLIP to be the protocol to communicate
between two TCP/IP hosts.  The problem observed seems to be that packets
addressed for broadcasting to a particular SLIP network (such as SNMP traps)
do not appear to be transmitted like other SLIP packets that have a full IP
address instead of the broadcast address.  Is this a limitation of SLIP?  Do the
packets have to have a particular hosts' IP address in the packet and not just
the broadcast address of the network?  Is there any documentation available on
SLIP and how it works (limitations, features) besides the RFC1055?

Any information would be helpful.

							Thanks
							Matt Cunningham
							Software Engineer
							EOP Group

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Oct 1992 18:34:05 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Printers.

Timothy Lange:
> I'm looking for a TCP/IP ready printer to connect via Ethernet.  I
> have seen lots of IPX and Appletalk ready printers but none for TCP/IP
> (lpd).  Has anyone seen such a machine?

HP has several printers that work over tcp/ip.  For LaserJets II, IID,
III, and IIID, you can get either the C2071S (for twisted-pair) or
C2071T (for Thin co-ax) cards for the printer.  The LaserJet IIISi, you
can get the C2059T card.

QMS also has a tcp/ip printer.

- Steve Kao

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 92 19:26:42 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: what does completion of write() really mean?

In article <921005125457@cream.ftp.com>, jbvb@vax.ftp.com (James B. VanBokkelen) writes:
>     
> With Nagle's algorithm, TCP can almost always Do The Right Thing when
> presented with a short write (e.g. either send it immediately or wait
> until previously transmitted data is ACKed).  The only case where overriding
> Nagle is reasonable is on the local net, where the application developer
> (or better, the sysadmin) decides that smoother throughput is worth more
> packets.  Overriding Nagle will seriously *reduce* both throughput and
> smoothness on a WAN connection through one or more heavily-loaded routers.


It's not just minor smoothing.  Some applications like to do

    for (;;) {
	write(small); write(small); read();
    }

The Nagle algorithm causes amazingly bad performance for such applications.

I think I've been told that common, standard X implementations like to
do such things.  And so common X over TCP (instead of various local
stuff) turns off the Nagle algorithm.

Never mind that combining the write()'s is the obvious thing to do.
The X guys say they have good reasons.


Vernon Schryver,  vjs@sgi.com

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Mon, 05 Oct 92 19:36:42 GMT
From:      rajiv@watson.ibm.com (Rajiv Ramaswami)
To:        comp.protocols.tcp-ip
Subject:   Source code for TCP available?

Could somebody out there please tell me how I can get
hold of the TCP source code release (I believe its part
of BSD) that includes Van Jacobsen's mods such as
header prediction and caching the last connection id?

Also would we need to obtain a license to do this?

thanks!

Rajiv

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 92 20:36:36 GMT
From:      gene@a.site.name (Gene Pidzarko)
To:        comp.protocols.tcp-ip
Subject:   Re: A list of Frquently Asked Questions

In article <1992Oct2.023733.29152@hsdlgw92.sdl.hitachi.co.jp> tsukako@sdl.hitachi.co.jp (Masato Tsukakoshi) writes:
>From: tsukako@sdl.hitachi.co.jp (Masato Tsukakoshi)
>Subject: Re: A list of Frquently Asked Questions
>Date: 2 Oct 92 02:37:33 GMT
>Sorry, this is not an answer.
>
>In article <1992Oct1.143055.28914@a.cs.okstate.edu> sheth@a.cs.okstate.edu (SHETH UMANG RAJNIK) writes:
>>Could someone forward me a list of Frequently Asked Questions ( FAQs )
>>for this newsgroup? ALternatively--is there any ftp site from where
>>I can obtain FAQs?
>
>I also want to get this list (if it exist).
>
>>Please send your response at my e-mail address ( sheth@a.cs.okstate.edu )
>
>So, if you get some information about it, would you please post to this
>newsgroup?
>
>--
> Masato Tsukakoshi 
> Systems Development Laboratory, Hitachi, Ltd.
> e-mail:tsukako@sdl.hitachi.co.jp
>
>
>-- 
>--

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 92 22:12:21 GMT
From:      booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
To:        comp.protocols.tcp-ip
Subject:   Silly windows, PERSIST timers, and ACKs

Greetings,

I am seeing what I believe is Silly Window Syndrome in action, and I would
like to ask a couple of questions.  The behaviour I see is something like:

	Receiver advertising 16 KB window, sender filling it with single
	packet.  At some point, receiver advertises 5KB window, then follows
	immediately with window update of 13 KB	.  Sender delays for 5 
	seconds before sending, then fills offerred window.  Receiver acks
	and offers 16 KB window again, etc.

If I have read the TCP code correctly (I've looked at Ultrix 3.0 and UTS 2.1.3
which is running Lachman & Assoc TCP, I think), it appears that when a 
sender sees a window which is less than half the size of the largest window
it has ever seen, it delays.  The sender uses the PERSIST timer for this
delay.  It also appears to me that the minimum value of the PERSIST timeout
is 5 seconds, at least on these systems.

According to comments in tcp_timer.h and tcp_output.c, when a sender is
delaying as a result of silly window syndrome, it will only send a packet
if (1) the timer expires, or, (2) a window update is received.  In the 
above rather terse example, the receiver sends an ACK with a small window,
but immediately follows it up with an ACK which updates the window to a much
more reasonable size.  Yet, there is still a 5 second delay before the sender
finally gets the data off.

Is this sender behaving badly by not responding to the window update?  The
receiver, when offering the small window, always follows it up immediately
(usually < .5 msec on our LAN) with a window update.  Is this receiver
not behaving well?

For what it's worth, the sender is an Amdahl running UTS 2.1.3 (Lachman net)
and the receiver is a Cray X/MP running Unicos 6.something.

Any information would be greatly appreciated (including corrections to anything
I said above).

regards,
mb
-- 
Mark Boolootian		booloo@llnl.gov		+1 510 423 1948

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 92 22:16:04 GMT
From:      nick@kralizec.zeta.org.au (Nick Andrew)
To:        comp.protocols.tcp-ip,aus.wanted
Subject:   Re: AS400s and Suns together

merce@xenitec.on.ca (Jim Mercer) writes:

>personally i think an AS/400 would make an excellent news server. 8^)
>(they tend to have oodles of memory and disk space)

I'm going to try it later this year. Keep the news on an nfs-mounted
partition. I hope the AS/400 supports links!

Nick.
-- 
Kralizec Dialup Unix (Public Access)    Data: +61-2-837-1183, 14400 24hrs 8N1
Zeta Microcomputer Software             Data: +61-2-837-1868, 2400 24hrs 8N1
P.O. Box 177, Riverstone NSW 2765       Plan: To beat Gnuchess 4.1 !

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 92 22:35:14 GMT
From:      lchiu@animal.gcs.co.nz (Laurence Chiu)
To:        comp.protocols.tcp-ip
Subject:   Network Print under TCP/IP

This may be answered in the FAQ (if there is one) or trivially easy (I
am a neophyte in the area) so please bear with me.

We have an application which will run on a UNIX box. All users will
access the application via TCP/IP (on PC's) via ethernet (they will
also be connected to a Novell Netware 3.11 server for E-mail).
There will be no printers connected to the Unix box, rather we would
like printers to be either LAN attached or attached to LAN workstations.
Is it possible to print from Unix (or better from the application) to
a printer connected like this?
Would a network type printer like a HP Laserjet IISI work - i.e. if
it had TCP/IP connectivity?

Thanks for any assistance in this.


=========================================================================== 
 Laurence Chiu                      |
 Principal Consultant               |
 GCS Ltd, Wellington, New Zealand   |
 Tel: +64 4 801 0012                | Internet    : lchiu@animal.gcs.co.nz
 Fax: +64 4 801 0095                | Compuserve  : 71750,1527

 Disclaimer: I speak only for myself - usual caveats apply!
===========================================================================

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 1992 08:33:30 -0500
From:      MEENA@bkmain.east-london.ac.uk (Meena Aggarwal-Sood)
To:        comp.protocols.tcp-ip
Subject:   load balancer

I wish to investigate/develop a system "load balancer" which would
balance the usage of machine load (cpu and i/o) acroos a
network of Unix machines.


All info would be most welcome

Please reply to


meena@bkmain.pel.ac.uk


-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Oct 1992 02:20:59 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Silly windows, PERSIST timers, and ACKs

	I think your analysis is correct. The real problem is that the
Berkeley code uses a 5 second timer, when they should be using on the order
of the estimated round trip time (see section 4.2.2.17 of RFC 1122). I
pointed out the problem and fix to Keith Bostic a couple years ago, but haven't
checked to see if it made it into any subsequent releases.
	The BSD code assumes that the other side will send a gratuitous
window update when the situation has changed (as their implementation does),
but the TCP specification does not require it. Rather, the sender is required
to do the probing to make sure data keeps flowing. That forces 5 second delays
on connections between conforming, but arguably not optimal TCP's and BSD's
version (and derivatives).
	If you have kernel sources and would like to patch it, drop me a
line and I can send you diffs for 4.3 Tahoe sources. It may have been just
a matter of lowering TCPTV_PERSMIN, but I don't remember offhand...
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Oct 1992 02:42:21 GMT
From:      dsiebert@icaen.uiowa.edu (Doug Siebert)
To:        comp.unix.programmer,comp.protocols.tcp-ip
Subject:   How the #$%@$* does TCP urgent data work?


I wrote the following in an attempt to understand how TCP urgent data works.
To use it, it is first invoked with a single argument and backgrounded to
create the listening half of the socket connection, then re-invoked with no
arguments in the foreground.  Following the listing is the resulting output
with my comments/questions.  The was compiled and run on an HP 9000/750 running
HP-UX 8.07, but as far as I am aware this program should behave in the same
way on any Unix system, subject to the usual header file differences, of
course.


---cut here---
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <time.h>
#include <errno.h>
 
main(argc)
int     argc;
{
  int     n,
          s;
  struct sockaddr_in sa;
  int     on = 1;
  int     i;
  fd_set  rfd,
          efd;
  char    buf[30];
 
  s = socket(AF_INET, SOCK_STREAM, 0);
  if (s < 0)
  {
    perror("socket");
    exit(1);
  }
  sa.sin_family = AF_INET;
  sa.sin_addr.s_addr = 0x7f000001;
  sa.sin_port = 1111;
  if (argc == 2)
  {
    setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &on, sizeof on);
    bind(s, &sa, sizeof sa);
    listen(s, 1);
    n = accept(s, 0, 0);
    if (n < 0)
    {
      perror("accept");
      exit(1);
    }
    sleep(1);
    for (;;)
    {
      FD_ZERO(&rfd);
      FD_SET(n, &rfd);
      FD_ZERO(&efd);
      FD_SET(n, &efd);
      select(n + 1, &rfd, 0, &efd, 0);
      if (FD_ISSET(n, &efd))
      {
        ioctl(n, SIOCATMARK, &i);
        printf("atmark value = %d\n", i);
        for (;;)
        {
          i = recv(n, buf, 20, MSG_OOB);
          if (i <= 0)
          {
            if (i)
              perror("oobrecv");
            else
              printf("oob null read\n");
            break;
          }
          buf[i] = 0;
          printf("oob - got '%s'\n", buf);
        }
        ioctl(n, SIOCATMARK, &i);
        printf("atmark value = %d\n", i);
      }
      if (FD_ISSET(n, &rfd))
      {
        i = recv(n, buf, 20, 0);
        if (i <= 0)
        {
          if (i)
            perror("recv");
          else
            printf("null read...normal termination\n");
          exit(1);
        }
        buf[i] = 0;
        printf("got '%s'\n", buf);
      }
    }
  }
  else
  {
    connect(s, &sa, sizeof sa);
    send(s, "test1", 5, 0);
    send(s, "a", 1, MSG_OOB);
    send(s, "test2", 5, 0);
    send(s, "b", 1, MSG_OOB);
    send(s, "test3", 5, 0);
    send(s, "c", 1, MSG_OOB);
    send(s, "test4", 5, 0);
    sleep(2);
  }
}
---cut here ---


% ./example ignoredargument &

{ here I startup the listening/reading half in the background }

[1] 7712
% ./example

{ here I startup the connecting/writing half }

atmark value = 0
oob - got 'a'
oobrecv: Invalid argument
atmark value = 0

{ since the exception condition is checked first the 'a' is read before
  anything else, as OOB data is defined to work, apparently.  Any further
  attempts to receive OOB data get 'Invalid argument', which is the result
  expected for attempts to read OOB data when none is present.  The atmark
  value is 0 because I haven't read up to the mark yet.   So far no questions }

got 'test1'

{ I now receive the regular data, up to the mark only.  Q:  Is this the
  expected behavior, to only read up to the mark and no further?  There is
  obviously other data waiting to be read past the mark, because of the sleep
  which is executed after accepting the connection but before attempting the
  selecting and reading of data. }

atmark value = 1
oobrecv: Invalid argument
atmark value = 1

{ Here I am 'at the mark', but unable to receive further OOB data, even though
  at this point the two other bytes have most certainly been sent (again due
  to the sleep on the listening/reading side after accepting the connection)
  Q:  Why is this? }

got 'test2test3test4'

{ Now I read the rest of the data, over the places where the other urgent data
  was sent.  Q: Is this because there is only one mark, and once the mark is
  set it moves only when the previous urgent data has been read, and I had not
  read the first urgent data when the second and third bytes of urgent data
  arrived?  And why did select() indicate an exception condition was pending
  when I was unable to read any further urgent data?  Is this expected? }

null read...normal termination

{ I see this after a one second pause (due to the sleep on the end of sending
  half)  As expected, select signals for a read on the socket but read returns
  0 when it was closed by the remote side.  Q: what happened to my other two
  bytes of urgent data?  They have been lost!  Where did they go?  How do fix
  this program?  Or does it work as it should and it is my expectations which
  are in error? }

%
[1]   Exit 1               ./example ignoredargument



If anyone can help me understand why this acts as it does, or better yet, fix
it so it performs as "expected" (i.e. how *I* expected it to behave, where no
data, urgent or otherwise, is lost) please come to my rescue!  Thank you.

-- 
/-----------------------------------------------------------------------------\
| Doug Siebert                             | "I don't have to take this abuse |
| Internet:  dsiebert@isca.uiowa.edu       |  from you - I've got hundreds of |
| NeXTMail:  dsiebert@chop.isca.uiowa.edu  |  people waiting in line to abuse |
|     ICBM:  41d 39m 55s N, 91d 30m 43s W  |  me!"  Bill Murray, Ghostbusters |
\-----------------------------------------------------------------------------/

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 1992 09:52:21 -0400
From:      mjo@ef2007.efhd.ford.com (Mike O'Connor)
To:        comp.protocols.tcp-ip
Subject:   Re: rlogin client

In article
<MS-C.718349484.1103527590.mrc@Tomobiki-Cho.CAC.Washington.EDU> Mark
Crispin <mrc@Tomobiki-Cho.CAC.Washington.EDU> writes:

:     The system rlogin is setuid root, for the reasons you outlined.  The only
:way for you to build an rlogin program from its source is to have superuser
:access.

You can certainly BUILD an rlogin client without being the superuser.
It's the running of the client that causes problems.

						...Mike

-- 
 Michael J. O'Connor           |  Internet:  mjo@fmsrl7.srl.ford.com
 Ford Motor Company, OPEO      |  UUCP:      ...!{backbone}!fmsrl7!mjo
 20000 Rotunda, Bldg. 1-3001   |  Phone:     +1 (313) 248-1260
 Dearborn, MI  48121           |  Fax:       +1 (313) 323-6277

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Oct 1992 05:31:24 GMT
From:      Mark Crispin <mrc@Tomobiki-Cho.CAC.Washington.EDU>
To:        comp.protocols.tcp-ip, "David K.Y. Yau" <yau@cs.utexas.edu>
Subject:   re: rlogin client

David Yau -

     The system rlogin is setuid root, for the reasons you outlined.  The only
way for you to build an rlogin program from its source is to have superuser
access.

-- Mark --


-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 92 08:20:44 GMT
From:      etxmesa@eos.ericsson.se (Michael Salmon)
To:        comp.protocols.tcp-ip
Subject:   Re: Silly windows, PERSIST timers, and ACKs

In article <BvoH71.3v9@mentor.cc.purdue.edu>, 
dls@mentor.cc.purdue.edu (David L Stevens) writes:
|> 	I think your analysis is correct. The real problem is that the
|> Berkeley code uses a 5 second timer, when they should be using on the order
|> of the estimated round trip time (see section 4.2.2.17 of RFC 1122). I
|> pointed out the problem and fix to Keith Bostic a couple years ago, but haven't
|> checked to see if it made it into any subsequent releases.
|> 	The BSD code assumes that the other side will send a gratuitous
|> window update when the situation has changed (as their implementation does),
|> but the TCP specification does not require it. Rather, the sender is required
|> to do the probing to make sure data keeps flowing. That forces 5 second delays
|> on connections between conforming, but arguably not optimal TCP's and BSD's
|> version (and derivatives).

The original BSD code may well have had problems but it doesn't seem to
apply here as the original poster stated that the destination site sent
a gratuitous window update.

-- 

Michael Salmon

#include	<standard.disclaimer>
#include	<witty.saying>
#include	<fancy.pseudo.graphics>

Ericsson Telecom AB
Stockholm

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Oct 1992 10:14:23 GMT
From:      tkevans@fallst (Tim Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: pc-tcp s/w

radha@yrloc.ipsa.reuter.COM (radha) writes:


>is there any public domain s/w equvalent to pc-tcp?

CUTCP/CUTE is available via ftp from sun.soe.clarkson.edu and
NCSA Telnet from zaphod.uiuc.edu.

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Oct 1992 10:19:11 GMT
From:      shlam@eng.ie.cuhk.hk (Alan S H Lam)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   SLIP for ULTRIX and MSDOS


I know it had been asked before but I missed them.
Sorry for asking again. 

Could anyone tell me where I can get the 
SLIP driver for ULTRIX 4.2 on DEC machine and
SLIP driver for MSDOS on PC?

If anyone know it, please send me a e-mail.
I will very appreciate it. Thanks.


--
Alan S. H. Lam
Department of Information Engineering, CUHK, Hong Kong
E-mail: shlam@eng.ie.cuhk.hk 
Tel: (852) 609 7975 Fax: (852) 603 5032

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Oct 1992 14:54:26 GMT
From:      peter@ferranti.com (peter da silva)
To:        comp.protocols.tcp-ip
Subject:   Re: what does completion of write() really mean?

In article <1992Oct5.163538.26590@PA.dec.com> mohanram@wsl.dec.com (Narayan Mohanram) writes:
> I agree with this. The sematics of write (or send) should be associated with
> data going out completely.

They never have been, on UNIX. On VMS, where these semantics are guaranteed,
we get horrible network performance on OSI as the stack manfully attempts to
keep all the write borders intact all the way through to the ether.

I'd rather a "complete write" function at the system call level (fsync)
for the cases where it matters, instead of forcing all I/O to complete
before a write returns.

It's not a networking problem, and shouldn't be addressed at the networking
level. That's how we got UNIX networking in the mess it is in the first place.
-- 
Peter da Silva                                          `-_-'
Ferranti Intl. Ctls. Corp.                               'U` 
Sugar Land, TX  77487-5012           "Heeft u vandaag al uw wolf geknuffeld?"
+1 713 274 5180            "Dat is mijn gezel, en niet bedoeld als een fooi."

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Tue, 06 Oct 1992 15:20:37 GMT
From:      phill@sidus.ocunix.on.ca (Phil Linttell)
To:        comp.sys.novell,comp.mail.misc,comp.protocols.tcp-ip
Subject:   WP Office <-> SMTP? (or MHS <-> SMTP)

I'm looking for suggestions for gating WordPerfect Office (MS-DOS) mail to 
Simple Mail Transport Protocol (SMTP) mail under UNIX.  Specifically, the 
host system is an Encore system running an 88open BCS/OCS implementation of
UNIX.  WordPerfect Office does not appear to be scheduled to move to 88open
in the near future (currently on SPARC and SCO; RS6000 and HP700 under 
development).

A discussion with the WordPerfect gateway support department reveals that 
a DOS WPO SMTP gateway is in beta and will be available 1Q93.  In the mean-
time, it occured to me that if I could find some information on an MHS to
SMTP gateway for DOS, that I could use that in conjuction with the WordPerfect
office MHS gateway.  I've already investigated an X.400 path to the Encore,
but am looking for a lower cost solution.

So, does anyone have any suggestions on linking WPO to SMTP, I'd love to
hear them.  I'll post a summary of responses.

TC, Phil
-- 
Phil Linttell,              5310 Canotek Road, Unit 16
SCO Product Manager         Ottawa, Ontario, K1J 9N5  CANADA
Sidus Systems, Inc.         t. 613-749-1777  f. 613-749-3850
phill@sidus.ocunix.on.ca    "This is as real as your so-called life gets." - Q.

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 92 20:06:58 GMT
From:      lrxi00@icts01.Kodak.COM (James Nonnemacher)
To:        comp.protocols.tcp-ip
Subject:   Ethernet on Mac SE's & Plus's

Does anyone know if it's possible to connect Mac SE's and Plus's to an ethernet network? If so, where 
can the adapters be purchased.

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 92 21:13:51 GMT
From:      booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
To:        comp.protocols.tcp-ip
Subject:   Re: Silly windows, PERSIST timers, and ACKs

In article <1992Oct6.082044.4126@ericsson.se> etxmesa@eos.ericsson.se (Michael Salmon) writes:
>
>The original BSD code may well have had problems but it doesn't seem to
>apply here as the original poster stated that the destination site sent
>a gratuitous window update.
>

I would like to comment a little on this.  In my previous message, I stated
I observed the following:  Normally, the receiver advertises a window of 
16 KB.  At some point, the receiver advertises a 5 KB window (even though it 
acks all the data), then immediately follows with an ACK advertising a window 
of about 13 KB.  The result is the sender delays 5 seconds.  Is it possible
the sender is going to delay until the receiver offers another 16 KB window?

The reason I ask this is as follows:  Elswhere in the trace I took, there are 
exchanges where, after acking all the data in the previous packet sent, the 
receiver advertises first an 4 KB window, followed immediately by 12 KB, and 
then 16 KB (a total of three ACKs).  After the third ACK, the sender goes ahead
and sends 16 KB.

In the second scenario, we have no delay.  The only difference (I detect) from
the first case is that the receiver sends an ACK advertising a window of 16 KB,
a window equal in size to the largest window we have ever advertised.  Is it
possible this is what the sender is waiting for?

This is a rather nasty problem for us, as we are in the process of migrating
a Cray from HYPERchannel to FDDI, but are being held up (in part) by this
little oddity (which kills performance).

>Michael Salmon

regards,
mb
-- 
Mark Boolootian		booloo@llnl.gov		+1 510 423 1948

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Oct 1992 21:59:33 GMT
From:      jjensen@convex.com (James Jensen)
To:        comp.protocols.tcp-ip
Subject:   Re: Silly windows, PERSIST timers, and ACKs

booloo@framsparc.ocf.llnl.gov (Mark Boolootian) writes:

In your first message you said you filled the 16k window with a single send
but here you say you are using fddi.  Are you doing something funny 
with the mtu, or do you mean send, as in "send()"?

if you have a 16k mtu, and a 16k window the behavior you see can
be explained.  Either up the window or lower the mtu. The window should
be at least 2*the mtu used by the connection. This should be done
automaticaly by tcp when it sets up the connection. 

If mtu is 4k then I don't know what your problem is.  I would try
increasing the send and recieve windows. 

Jim Jensen - jjensen@convex.com

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 92 22:30:56 GMT
From:      westes@sti.com (Will Estes)
To:        comp.protocols.tcp-ip,comp.sun.admin
Subject:   Best Way To Check For Sources Of Poor Network Performance?

When I started to use x-based applications today on an MS-windows
x-server logging into a SunOS host, I noted that the performance was
abysmal.  I quickly noted that the load on the SunOS host was virtually
nil, and that one UNIX host had been added to the same ethernet segment
as the one connected to the SunOS host.  Several other people on the same 
segment as the SunOS host also noted that the performance was bad during 
the same time period.

My question is are there any tools, short of purchasing an expensive
network analyzer, that can be used under UNIX on the SunOS host to check
for broadcast storms or other obvious network problems?  An ftp source
for something that works either under SunOS or on an ethernet-attached
PC would be ideal.  If it's a PC utility, it should handle IPX and TCP
traffic.

What are some likely causes for this kind of problem?  There are about
30 hosts attached to the suspect ethernet.
-- 
Will Estes		Internet: westes@netcom.com

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Oct 1992 02:33:24 GMT
From:      peter@cujo.curtin.edu.au (Peter N Lewis)
To:        comp.protocols.tcp-ip
Subject:   Connection reset by peer?

Hi All,

Can anyone tell me what that means?  I get it occasionally when I ftp
from SunOS to my Mac ftp daemon (which is most likely the cause, but I
don't know what it means, so it makes figuring out what to do about it
tricky...).  Either 'dir' or 'get' commands can cause it, and it says:

netin: Connection reset by peer

and aborts the transfer.  If anyone can give me any help on what this
means (and anything I can do to stop it happening), I'd really
appreciate it!

Thanks,
   Peter.
... I had a .sig, but I've temporarily misplaced it ...

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Oct 1992 10:28:37 GMT
From:      VAAGA@gribb.hsr.no (Vaaga, Hans Egil       7-93)
To:        comp.protocols.tcp-ip
Subject:   Reading all packets from TCP/IP from an HP 9000/700 Unix workstation

Hello!

We are 7 students who is working with a project. The task is to read all 
packets on a network and make statistics of this.

Our problem is that we don't know how to read the packets. We are using an 
HP 9000/700 workstation (UNIX). We know that we need something called a NIT(
Network interface tap). But this NIT exist only on SUN-machines. Can anybody 
help us?

Goup member Vaaga


-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 1992 18:08:41 -0400
From:      mjo@ef2007.efhd.ford.com (Mike O'Connor)
To:        comp.protocols.tcp-ip
Subject:   Re: Where to get not-online RFCs?

In article <1925@shaman.wv.tek.com> andrew@frip.wv.tek.com writes:
:[Surely this is a FAQ but I can't find the FAQ list ...]
:
:How can I get an RFC that is no longer online at nic.ddn.mil?

I thought that all the RFCs were online at nic.ddn.mil.  If they're
not, I'd like to know why.

						.../\/\ike

-- 
 Michael J. O'Connor           |  Internet:  mjo@fmsrl7.srl.ford.com
 Ford Motor Company, OPEO      |  UUCP:      ...!{backbone}!fmsrl7!mjo
 20000 Rotunda, Bldg. 1-3001   |  Phone:     +1 (313) 248-1260
 Dearborn, MI  48121           |  Fax:       +1 (313) 323-6277

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 92 13:38:16 GMT
From:      dclunie@sirius.ucs.adelaide.edu.au (David Clunie)
To:        comp.protocols.tcp-ip
Subject:   TCPIP for VAX/VMS


We have an old Seimens MRI scanner based on a Dec VAX 750 that we want
to put on an ethernet running TCP/IP to Suns and so on. I am not
a DEC person so I have no idea where to go to get the cheapest
solution. I presume that DEC sells an expensive Ethernet card and
software to do TCP/IP, and ftp and so on (we need it to run under
VMS, and not the latest version of VMS by any means), but I also
presume that there are cheaper hardware solutions and probably an
alternative (if not free) software solution.

Any advice would be much appreciated.

david
-- 
David Clunie (dclunie@itd.adelaide.edu.au)

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Oct 1992 16:20:49 GMT
From:      rsivaram@vela.acs.oakland.edu (siva)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Help Needed in installing SUN RPC sources...

Dear Netters,
	I am tring to install SUN's free RPC and XDR sources in my m/c 
which runs Ultrix 4.2. When I typed 'make install'
it gave the following error in the file getrpcent.c:
"static function declared and referenced but not defined :index"
The following is the declaration statement and the routine
where it is used where it throws the error:

static	char *index();

static struct rpcent *
interpret(val, len)
{
	register struct rpcdata *d = _rpcdata();
	char *p;
	register char *cp, **q;

	if (d == 0)
		return;
	strncpy(d->line, val, len);
	p = d->line;
	d->line[len] = '\n';
	if (*p == '#')
		return (getrpcent());
	cp = index(p, '#');
	if (cp == NULL)
    {
		cp = index(p, '\n');
		if (cp == NULL)
			return (getrpcent());
	}
	*cp = '\0';
	cp = index(p, ' ');
	if (cp == NULL)
    {
		cp = index(p, '\t');
		if (cp == NULL)
			return (getrpcent());
	}
	*cp++ = '\0';
	/* THIS STUFF IS INTERNET SPECIFIC */
	d->rpc.r_name = d->line;
	while (*cp == ' ' || *cp == '\t')
		cp++;
	d->rpc.r_number = atoi(cp);
	q = d->rpc.r_aliases = d->rpc_aliases;
	cp = index(p, ' ');
	if (cp != NULL)
		*cp++ = '\0';
	else
    {
		cp = index(p, '\t');
		if (cp != NULL)
			*cp++ = '\0';
	}
	while (cp && *cp) {
		if (*cp == ' ' || *cp == '\t') {
			cp++;
			continue;
		}
		if (q < &(d->rpc_aliases[MAXALIASES - 1]))
			*q++ = cp;
		cp = index(p, ' ');
		if (cp != NULL)
			*cp++ = '\0';
		else
	    {
			cp = index(p, '\t');
			if (cp != NULL)
				*cp++ = '\0';
		}
	}
	*q = NULL;
	return (&d->rpc);
}
I would greatly appreciate if someone could throw light on this

thanks
-siva

-- 



-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Oct 1992 16:55:38 GMT
From:      fff@microplex.com (Fred Fierling)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Print under TCP/IP

In article <Bvo6qu.AwA@animal.gcs.co.nz> lchiu@animal.gcs.co.nz (Laurence Chiu) writes:
>There will be no printers connected to the Unix box, rather we would
>like printers to be either LAN attached or attached to LAN workstations.
>Is it possible to print from Unix (or better from the application) to
>a printer connected like this?

Sounds like you might be interested in our M200 TCP/IP Printer Adapter.  It
allows your host to submit print jobs via LPD or rsh to any serial or parallel
port printer.  For more information:

 info@microplex.com
-- 
Fred Fierling    fff@microplex.com      Tel: 604 875-1461   Fax: 604 875-9029
Microplex Systems Ltd   265 East 1st Avenue   Vancouver, BC  V5T 1A7,  Canada

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 92 20:15:41 GMT
From:      kratz@goofy.zdv.uni-mainz.de (Thomas Kratz)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   LPR-command with WINQVT-43

I have a problem with WINQVT version 43 on a 386 with 8MB and WINDOWS 3.1,
trying to use lpr on an UNIX-host. 
The entries in qvt_tcp.rc are - as far as i know - correct but after klicking
the OK-button in the LPR-window a window with the message
    
                      LPR-DEAMON refused 'send control file' command

My supervisor has checked his settings and the NCSA-Telnet-2.14-lpr.exe
works fine.
Has anybody similar problems or an idea how to solve them?
Please send me email to

    kratz@goofy.zdv.uni-mainz.de

or a RE: to that newsgroup          Thanks, Thomas
 
****************************************************************************
"Even a stopped clock gives the right time twice a day"
                                        source unknown, will be changed soon

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Oct 1992 20:26:38 GMT
From:      vittallo@ssd.comm.mot.com (John Vittallo)
To:        comp.protocols.tcp-ip
Subject:   UDP has to do an ARP after 1/2 hour of inactivity?

I have two boards in a VME system that communicate using  
UDP port #7000. The problem is that when there is a pause in 
communication, about 1/2 hour,  the board that wants to send out 
a message has to ARP the other board. During this ARP the message 
never gets out. The software is expecting a response so it times out 
and  sends another message. This message gets over without a problem.

Is this a part of UDP, that it loses the ARP table for UDP destinations?
Both boards, a VME 167 running UNIX and a VME 147 running PSOS are on a
LARGE, BUSY, NETWORK. Users are using the 167 board for ftp, rlogin
etc during my testing.

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 92 20:28:05 GMT
From:      haas@bnr.ca (Mark Haas)
To:        comp.protocols.iso,comp.protocols.misc,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Call for Papers - International Conference on Network Protocols - 1993

**********************************************************************************
*                                                                                *
*                          Call for Papers                                       *
*                                                                                *
*     1993 International Conference on Network Protocols (ICNP-93)               *
*                                                                                *
*     ANA Hotel - San Francisco, California, USA - October 19-22, 1993           *
*                                                                                *
**********************************************************************************
*                                                                                *
*    ICNP-93 is sponsored by the IEEE Computer Society Technical Committee on    *
*    Distributed Processing.  Original technical papers addressing the following *
*    topics of interest are solicited for presentation at the conference and     *
*    publication in the conference proceedings. Topics of interest include:      *
*                                                                                *
*         - Network Architectures         - Protocol Conversion                  *
*         - Switching Protocols           - Broadcast Systems                    *
*         - Routing Protocols             - Distributed Operating Systems        *
*         - Flow and Congestion Control   - System Support and Interfaces        *
*         - High-Speed Networks           - Protocol Design Methodology          *
*         - Real-Time Protocols           - Protocol Verification                *
*         - Network Security              - Protocol Testing and Debugging       *
*         - Name Servers and Directories  - Protocol Implementation              *
*                                                                                *
*    Authors are requested to submit six copies (in English) of their            *
*    double-spaced typed manuscript (maximum of 25 pages) with an abstract to    *
*    the program chair by MARCH 1, 1993. Papers will be considered for           *
*    publication in the new journal "IEEE/ACM Transactions on Networking."       *
*    Submit papers to:                                                           *
*                                                                                *
*         Prof. Mohamed G. Gouda, Program Chair                                  *
*         Department of Computer Science                                         *
*         University of Texas                                                    *
*         Austin, Texas 78712, USA                                               *
*         Tel: (512) 471-9532                                                    *
*         E-mail: gouda@cs.utexas.edu                                            *
*                                                                                *
*    The day before the conference (October 19) will be devoted for tutorials    *
*    for providing the background for the conference. Send tutorial proposals    *
*    by MARCH 1, 1993 to:                                                        *
*                                                                                *
*         Dr. M. Umit Uyar, Tutorials Chair                                      *
*         AT&T Bell Labs, Room 3D-501A                                           *
*         Crawfords Corner Road                                                  *
*         Holmdel, New Jersey 07733, USA                                         *
*         E-mail: umit@honet5.att.com                                            *
*                                                                                *
*    The conference timetable is as follows:                                     *
*         Papers and proposals due:           March 1, 1993                      *
*         Acceptance letters sent:            June 15, 1993                      *
*         Camera ready copies due:            August 1, 1993                     *
*         Tutorials:                          October 19, 1993                   *
*         Conference:                         October 20-22, 1993                *
*                                                                                *
*    For further information, please contact:                                    *
*                                                                                *
*         Prof. Ming T. (Mike) Liu, General Chair                                *
*         Dept. of Computer and Information Science                              *
*         The Ohio State University                                              *
*         2036 Nell Ave.                                                         *
*         Columbus, Ohio 43210, USA                                              *
*         E-mail: liu@cis.ohio-state.edu                                         *
*                                                                                *
**********************************************************************************

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 92 20:37:18 GMT
From:      andrew@frip.WV.TEK.COM (Andrew Klossner)
To:        comp.protocols.tcp-ip
Subject:   Where to get not-online RFCs?

[Surely this is a FAQ but I can't find the FAQ list ...]

How can I get an RFC that is no longer online at nic.ddn.mil?

  -=- Andrew Klossner  (andrew@frip.wv.tek.com)
                       (uunet!tektronix!frip.WV.TEK!andrew)

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 92 22:46:15 GMT
From:      romkey@asylum.UUCP (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP has to do an ARP after 1/2 hour of inactivity?

vittallo@ssd.comm.mot.com (John Vittallo) writes:
>I have two boards in a VME system that communicate using  
>UDP port #7000. The problem is that when there is a pause in 
>communication, about 1/2 hour,  the board that wants to send out 
>a message has to ARP the other board. During this ARP the message 
>never gets out. The software is expecting a response so it times out 
>and  sends another message. This message gets over without a problem.
 
>Is this a part of UDP, that it loses the ARP table for UDP destinations?
>Both boards, a VME 167 running UNIX and a VME 147 running PSOS are on a
>LARGE, BUSY, NETWORK. Users are using the 167 board for ftp, rlogin
>etc during my testing.

It should have nothing to do with UDP, per se. UDP should know nothing about
ARP or the media it's running over.

What's probably happening is one of these two things: 

ARP may be reusing the cache entry because no communication has
happened for half an hour. ARP implementations usually have caches
smaller than the total number of possible hosts they may be able
reasonably ARP; this is an okay assumption because on most networks a
system talks to very few other systems. An ARP implementation will
reuse a cache entry, usually the oldest one, if it runs out of empty
slots.

An ARP implementation should also expire old entries (as stated in host
requirements) because you don't want an ARP entry to get stale. This
is a protection against the system you're talking to changing its ethernet
address (as it might do if its ethernet board were replaced). If it
did and ARP didn't ever expire the address you wouldn't be able to talk
to the system again until you rebooted.

ARP should *not* throw away the packet that caused the ARP request, though,
so you should complain to your TCP/IP vendor that their ARP implementation
is behaving stupidly by doing this. Here host requirements overrides the
ARP RFC.
-- 
	- john romkey	  ELF Communications	 romkey@ELF.com

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Oct 1992 23:51:24 GMT
From:      johnr@pacdata.uucp (John Reed)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Printers.

In article <2480015@hprnd.rose.hp.com> k@hprnd.rose.hp.com (Steve Kao) writes:
>Timothy Lange:
>> I'm looking for a TCP/IP ready printer to connect via Ethernet.  I
>> have seen lots of IPX and Appletalk ready printers but none for TCP/IP
>> (lpd).  Has anyone seen such a machine?
>
>HP has several printers that work over tcp/ip.  For LaserJets II, IID,
>III, and IIID, you can get either the C2071S (for twisted-pair) or
>C2071T (for Thin co-ax) cards for the printer.  The LaserJet IIISi, you
>can get the C2059T card.
>
>QMS also has a tcp/ip printer.
>
>- Steve Kao

For the price of a used Sun3/50 (diskless, 4 Megs Ram, no monitor = $175.00
from Minicomputer Exchange), and a little software work, you can easily make
your own.

I just wrote both a tftp server and an lpd server that execute on top
of Xinu (version 7.9 from Purdue), which runs natively on the 3/50.

Together with a memory spooler, I have a very nice tcp/ip print
server/spooler.

I connect ttyb to the Laser Printer serial port (19200 baud), and have
ttya (the Xinu console) wired into a 16-channel Mux of another computer.

My lpd server currently handles 4 connections (controlled by a #define),
with one of the connections reserved for non-data messages (like lpq or lprm).
My tftp server handles only 1 connection.

Anyone who is interested in the details, please ask.



JR



-- 


   /------------------------------------------------------------------\
  |  John Reed                           {ucsd,uunet}!pacdata!johnr    |
  |  Pacific Data Products               johnr@pacdata.com             |
  |                    ---------------------                           |
  |  George Herbert Walker Bush, with the letters re-arranged spells:  |
  |                                                                    |
  |                 Huge Berserk Rebel Warthog                         |
  |                                     -- From Cosmic Trigger II      |
   \------------------------------------------------------------------/

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Oct 1992 02:01:05 GMT
From:      mnukala@cs.ulowell.edu (Vamsi)
To:        comp.protocols.tcp-ip
Subject:   Source Code of Internetworking with TCP/IP I&II -Douglas Comer


Hi,
	I am looking for the source code given in Internetworking with
	TCP/IP Vol I & II by Douglas Comer.
	Any information about an FTP site is greatly appreciated.

Thanks,
Vamsi Nukala


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

I'd like to be a could be               I'd rather be a has been
If I could not be an are,          Than a might have been, by far,
For a could be is a maybe          For a might have been has never been
With a chance of reaching par.     Where a has been was and are



-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Oct 1992 06:06:19 GMT
From:      koziol@void.ncsa.uiuc.edu (Quincey Koziol)
To:        comp.protocols.tcp-ip
Subject:   Re: pc-tcp s/w

In article <1992Oct6.101423.9757@fallst> tkevans@fallst (Tim Evans) writes:
>radha@yrloc.ipsa.reuter.COM (radha) writes:
>
>
>>is there any public domain s/w equvalent to pc-tcp?
>
>CUTCP/CUTE is available via ftp from sun.soe.clarkson.edu and
>NCSA Telnet from zaphod.uiuc.edu.
                  ^^^^^^^^^^^^^^^
Close, but this should actually be: ftp.ncsa.uiuc.edu (also answers to
zaphod.ncsa.uiuc.edu) and the software is in the /PC/Telnet directory.
There is also equivalent Telnet software for the Macintosh in the
/Mac/Telnet directory.

	Quincey Koziol
	NCSA

koziol@ncsa.uiuc.edu




-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Oct 1992 06:22:01 GMT
From:      koziol@void.ncsa.uiuc.edu (Quincey Koziol)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP implementation help?

I've recently been modifying the TCP/IP kernel for NCSA Telnet for the
PC to be a happier and healthier member of the Internet host community
and I've come across an interesting problem.  First, some background:
The TCP/IP kernel is not interupt driven, i.e. the application using
the kernel must periodicly call a function which polls the network for
received packets and does the protocol interpretation of them.  The
other piece of background is that the routine which empties the TCP
buffer onto the network does not call the routine which polls the
network for incoming packet at any time while it is emptying the
TCP buffers.
	What tends to happen, is that everything will work fine for quite
a while and then a packet that we've sent out will get dropped (unbeknownest
to the sending host).  The rest of the buffer will finish being emptied out
onto the network, then the sending host waits for an ack of the data.
Because a packet has been dropped, this never comes, and eventually the
TCP port times out and begins resending the data.  All this works fine,
but somewhere through the resend of the outgoing data, an ack usually
comes through for the entire set of data which has been previously sent
(i.e. the dropped packet plus the entire bufferful which was initially
sent after the dropped packet).
	What I'd like to do is have that incoming ack update the information
in the outgoing port so that the rest of the buffer (which the receiving
host already has and has ack'ed) is not re-sent.  I'm unwilling,
however, to introduce a poll for received packets in the middle
of this tight loop pushing packets onto the net as fast as it can.  I was
wondering (if anyone has actually understood this so far... :-)
if anyone has a good algorithm for helping re-sends of TCP data act
a little more intelligent?

	Thanks,
		Quincey Koziol
		NCSA

koziol@ncsa.uiuc.edu


-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 92 07:59:11 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Reading all packets from TCP/IP from an HP 9000/700 Unix



 >We are 7 students who is working with a project. The task is to read all 
 >packets on a network and make statistics of this.
 
 >Our problem is that we don't know how to read the packets. We are using an 
 >HP 9000/700 workstation (UNIX). We know that we need something called a NIT(
 >Network interface tap). But this NIT exist only on SUN-machines. Can anybody 
 >help us?

get HP to put berkeley packet filter (public available, better than
nit, apparently) into H-PUX (if it isn't already...)

 jon

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Oct 1992 09:45:11 GMT
From:      Josef Moellers <mollers.pad@sni.de>
To:        comp.protocols.tcp-ip
Subject:   Re: UDP has to do an ARP after 1/2 hour of inactivity?

In <1992Oct7.202638.19578@lmpsbbs.comm.mot.com> vittallo@ssd.comm.mot.com (John Vittallo) writes:

>I have two boards in a VME system that communicate using  
>UDP port #7000. The problem is that when there is a pause in 
>communication, about 1/2 hour,  the board that wants to send out 
>a message has to ARP the other board. During this ARP the message 
>never gets out. The software is expecting a response so it times out 
>and  sends another message. This message gets over without a problem.
 
>Is this a part of UDP, that it loses the ARP table for UDP destinations?
>Both boards, a VME 167 running UNIX and a VME 147 running PSOS are on a
>LARGE, BUSY, NETWORK. Users are using the 167 board for ftp, rlogin
>etc during my testing.

I found a thing (bug?) in SVR4, where a large (larger than the MTU)
packet was split up in two (to cater for the MTU) and the two parts sent
one after the other. The first one was queued due to a missing ARP entry
(this was the first packet being sent to the destination or the ARP
entry had aged out). When the second part was to be sent immediately
after the first one was queued (the ARP request still on the way), it
was dropped, because the code allowed only for one packet to be queued.

You can try this by calling "ping" with a packet size set to the
network's MTU (the additional header(s) will push it past the limit) and
fiddling around with ARP entries (use "arp" to selectively remove the
entries.) You'll lose the first "ping"-packet!
-- 
| Josef Moellers		| c/o Siemens Nixdorf Informationssysteme AG  |
|  USA: mollers.pad@sni-usa.com	| Abt. STO-XS 113	   | Riemekestrasse   |
| !USA: mollers.pad@sni.de	| Phone: (+49) 5251 835124 | D-4790 Paderborn |

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 92 10:09:32 GMT
From:      mikeg@Ingres.COM (Mike Glendinning)
To:        comp.protocols.tcp-ip
Subject:   Strange Output from 'netstat -a'.

I did a 'netstat -a' command on a SVR4 box the other day, and it
came up with this strange (and worrying) output.  Amidst the
usual stuff, there were at least a dozen lines identical to the
following:

   Proto Recv-Q Send-Q Local Address        Foreign Address    (state)

   tcp        0    536 *.*                  *.*                CLOSED

What does this mean?  Normally, you just get one such line, with a
"Send-Q" of zero, which presumably indicates that any completely
inactive or unknown TCP port/address combinations are treated as
though they were in the CLOSED state.

-Mike Glendinning, Ingres UK.

mikeg@ingres.com

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 92 15:10:43 EST
From:      inpractutor@qut.edu.au
To:        comp.protocols.tcp-ip
Subject:   Retrieving network information

Hi friends,
I am now writing programs for my project assignment in tcp/ip. I am using
HP-UX and 386 BSD. I need to read the network information, such as IP address,
netmask, ARP table, network srtatistic (packets sent and received), etc.
I have tried to copy the small program from the Ultric manual ( because I do not
have HP-UX manual for that) but it didd not work. As I know that I should use
ioctl command. For those who knows to solve this problem, would you please help
me ? Thank you for your help.

Andrey Andoko

E-mail : andrey@sleet.fit.qut.edu.au

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 92 10:11:22 GMT
From:      adam@castle.ed.ac.uk (Adam Hamilton)
To:        comp.protocols.tcp-ip
Subject:   Re: Reading all packets from TCP/IP from an HP 9000/700 Unix

In article <3070@ucl-cs.uucp> J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) writes:
:
:
: >Our problem is that we don't know how to read the packets. We are using an 
: >HP 9000/700 workstation (UNIX). We know that we need something called a NIT(
: >Network interface tap). But this NIT exist only on SUN-machines. Can anybody 
: >help us?
:
:get HP to put berkeley packet filter (public available, better than
:nit, apparently) into H-PUX (if it isn't already...)
:
	I'll post what I mailed.  /etc/nettl can give you a trace of most
everything happening in HP-UX's world of comms (e.g. every packet through
its ether interface).  /etc/netfmt will filter and format this for you.
I don't know if it lets you put the ether into promiscuous mode.  This works.
		Adam	

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 92 11:44:22 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Reading all packets from TCP/IP from an HP 9000/700 Unix

% We are 7 students who is working with a project. The task is to read all 
% packets on a network and make statistics of this.
% 
% Our problem is that we don't know how to read the packets. We are using an 
% HP 9000/700 workstation (UNIX). We know that we need something called a NIT(
% Network interface tap). But this NIT exist only on SUN-machines. Can anybody 
% help us?

  One might try looking at the nettl(1m) and related commands supplied with
H-POX.  Allegedly they support tracing of packets and other network events.

In article <3070@ucl-cs.uucp> J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) writes:
>get HP to put berkeley packet filter (public available, better than
>nit, apparently) into H-PUX (if it isn't already...)
>
> jon

  Regrettably, HP appears to be more focused on how little they can
give you and still claim it is UNIX.  For example, they don't supply
traceroute(8) -- fortunately there are a number of people on the net
who have that and are willing to share.  LOTS of other pieces and
parts that are included with every other flavour of UNIX are just not
supplied with HPUX.  It's a pity the software is so deficient, because
the hardware is nice.

Ran
atkinson@itd.nrl.navy.mil

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 92 12:11:24 GMT
From:      ag129@cus.cam.ac.uk (Alasdair Grant)
To:        comp.protocols.tcp-ip
Subject:   IP over Ethernet: LSAP=6 vs. SNAP


RFC 948 specified IP on 802.3 using an LSAP of 6, i.e. the IEEE-assigned
LSAP for IP.  RFC 1042 then obsoleted this and specified the use of SNAP,
i.e. LSAP 170, with Ethertypes 0800 etc. as used originally.  What was the
technical reason for this, given that it's an extra layer of encapsulation
and longer frames?

Was it just for people who run DIX Ethernet and 802.3 on the same cable?

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 1992 00:31:04 -0700
From:      tli@skat.usc.edu (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over Ethernet: LSAP=6 vs. SNAP

    IP over LANs depends on the use of ARP.  Given the limited number of
    available 802.2 LSAPs, IEEE would not assign one for ARP, but was
    convinced to allocate one for the SNAP mechanism.  

So people frequently use HP probe as an ARP substitute when running 802.3.

    You could still run DIX and 802.3/802.2 versions of IP on the same wire.
    SNAP is just the preferred encoding.

... by the standards bodies.  Almost everyone is using (or is
migrating towards) DIX. 

-- 
Tony Li - Escapee from the USC Computer Science Department          tli@usc.edu
		       The net is not what it seems.

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Oct 1992 14:04:50 GMT
From:      rob@icarus.inmos.co.uk (Robin Pickering)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Strange Output from 'netstat -a'.

In article <1992Oct8.100932.18923@pony.Ingres.COM> mikeg@Ingres.COM (Mike Glendinning) writes:
>I did a 'netstat -a' command on a SVR4 box the other day, and it
>came up with this strange (and worrying) output.

Unless netstat on SVR4 is implemented very differently than BSD, beware
of believing it's output on a moderately loaded machine.

Netstat (and others such as ps) have to go trunking
round the contents of /dev/kmem to get their information, and as user processes
have no way of maintaining locks on the data. This means that data structures
can be moved round between say sucessive reads of a linked list, leading to
garbage being read. This could well be the source of your worying output.

--
   Rob.

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Thu, 08 Oct 1992 14:33:54 GMT
From:      mcgarvey@vnet.ibm.com
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet server that runs on a PC?

In  <19vqmoINNb4f@usenet.INS.CWRU.Edu>  pvg@po.CWRU.Edu (Paul V. Gerwe) writes:
> 
> Greetings.
> 
> I am looking for a telnet server that will run on a PC and that is 
> capable of running Dos applications simultaneously.  If you have 
> any information, please send me mail at pvg@po.cwru.edu.  Thanks!
> 
> Hat

TCP/IP for OS/2 has this function

John McGarvey

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Thu, 08 Oct 1992 14:37:33 GMT
From:      mcgarvey@vnet.ibm.com
To:        comp.protocols.tcp-ip
Subject:   VT220 TELNET client

When I run certain editors on a VAX, e.g. TPU, I get escape
sequences that my VT220 TELNET client does not understand.
These are

CSI'z  and CSI'{

These aren't in the VT220 spec.  What are they supposed to
do?

John McGarvey

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 92 14:47:12 GMT
From:      turletti@jerry.inria.fr (Thierry Turletti)
To:        comp.protocols.tcp-ip
Subject:   Videoconferencing over the Internet


The INRIA Videoconferencing System IVS is designed with the explicit goal to
demonstrate that it is possible today to use a standard workstation for 
video-/audioconferences. Thus, in order to conduct a videoconference with IVS,
only minimal hardware upgrades are required to a machine commonly found 
today on the desk of an engineer (a Videocamera and a Videocard).

A further design goal of IVS is to allow more than two persons to conduct a
videoconference using IP multicast extensions. Thus, with IVS, a group of 
people can participate at a conference at the same time.

IVS allows to use standard Internet technology to transmit 
video/audio-data. This is achieved by implementing a software version of a 
H.261 codec (video codec for audiovisual services at p*64 kb/s) in IVS. 
Furthermore, where conventional H.261 hardware codecs require leased lines or 
switched circuits for data-transmission, the H.261 software codec of IVS uses 
standard UDP datagrams.

This system has been already tested over many countries including France, 
Germany, Sweden, the Nederthlands and the USA.

The following also contributed to the development of IVS:

David Berry <David.Berry@eng.sun.com> (Videopix grabbing improvement)
Jack Jansen <Jack.Jansen@cwi.nl> (ADPCM 32kb/s audio codec)
Guido van Rossum <Guido.van.Rossum@cwi.nl> (SGI Indigo compatibility)
Winston Dang <wkd@uhunix.uhcc.Hawaii.Edu> (speed improvements)

Technical Data
--------------

System requirements: SUN SparcStation or SGI Indigo stations, Video grabber 
(VideoPix Card for SUN stations), Video Camera, X-Windows, Internet-Access.

ftp adress: Version 1.10 of IVS is available for anonymous ftp from 
	avahi.inria.fr in directory "/pub/videoconference/ivs.tar.Z".


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

   Thierry Turletti.

   Project RODEO - INRIA Sophia-Antipolis - FRANCE

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Oct 1992 15:30:17 GMT
From:      add@philabs.philips.com (Aninda V. Dasgupta)
To:        comp.protocols.tcp-ip,aus.wanted
Subject:   Re: AS400s and Suns together

In article <1992Oct05.160806.16381@xenitec.on.ca> merce@xenitec.on.ca (Jim Mercer) writes:

>given all of that, there are API's that look kinda berkeleyesque for 
>RPG and Pascal (and i believe C).
>
>i would encourage others to pick it up and run with it.  if we can get some
>kind of cooperative code sharing thing going, we might be able to show
>some of the traditional IBM shops what networking is really about.
>
>[ Jim Mercer   Reptilian Research  merce@iguana.reptiles.org  +1 519 893-6085 ]
>[             I don't want to work for a company that has a CIO.              ]
>[              Disclaimer! I don't need no stinking Disclaimer!               ]

We are about to embark on a project to make our AS/400 talk to our Sun Sparc boxes.
We are buying IBM's TCP/IP programming library (APIs) and have been promised very
Berkleyish interfaces.  We are going to write everything in Pascal since the
TCP/IP programmer's manual from IBM had example code and mentioned libraries for
Pascal. Moreover, the C compiler costs approx. $10,000 while the Pascal compiler
about $5000. Our Sun application needs to search databases on the AS/400 and return
the search results to "front end engines" on other boxes on the network. 

The projected time of completion of this work is middle of December. So if anybody
is interested in hearing about our experiences (I might even be able to "lend" you
some code come Dec., provided my manager approves) get in touch with me....

In the meantime, if anybody has any experience to share in socket-like Pascal
programming on the AS/400 please get in touch with me, I will be most
grateful.


-- 
Aninda DasGupta   (add@philabs.philips.com)
Ph : (914) 945-6071    Fax : (914) 945-6552
Philips Labs\n 345 Scarborough Rd\n  Briarcliff Manor\n NY 10510
(Gas from Phillips Petroleum, Antacid from Phillips Medical, Lightbulbs from us)

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 92 17:34:37 GMT
From:      dougm@boulder.Central.Sun.COM (Doug McCallum)
To:        comp.protocols.tcp-ip
Subject:   Re: Strange Output from 'netstat -a'.

In article <1992Oct8.100932.18923@pony.Ingres.COM> mikeg@Ingres.COM (Mike Glendinning) writes:

   I did a 'netstat -a' command on a SVR4 box the other day, and it
   came up with this strange (and worrying) output.  Amidst the
   usual stuff, there were at least a dozen lines identical to the
   following:

      Proto Recv-Q Send-Q Local Address        Foreign Address    (state)

      tcp        0    536 *.*                  *.*                CLOSED

This is an artifact of STREAMS.  All it means is that there is an
STREAM that was opened to TCP that hasn't been bound or has been
unbound but not closed.  When the initial plumbing for TCP/IP is
setup, a STREAM is opened that doesn't get closed until the stack is
brought down at shutdown.  This is part of holding the stack together.
That is the origin of the first one.

You can get additional ones for a number of reasons.  For example, do
a "sleep 60 </dev/tcp &" and then do a "netstat -a" and you will see a
new one that will exists for as long as the stream is opened.

You can also get them when an application doesn't do a "close()" after
the connection has been closed.  You shouldn't get them with data in
the send Q.  That sounds like a bug.

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Oct 1992 18:06:16 GMT
From:      mvm@cbnewsb.cb.att.com (michael.v.murphy)
To:        comp.protocols.tcp-ip
Subject:   Opens and binds on Sparcstation TCP

  We are currently running tests on some code that resides on a Sun. The tests
include stress tests that push through tens of thousands of identical and
relatively small (less than 1500 byte) messages. The majority of these
messages flow through ok, however every 500 or so we get a 'system error' on
a t_bind or t_open on one of the messages. I am thinking of putting in retry
logic and possibly a short sleep interval to allow the system to 'catch up',
but I thought I would post the problem first and see if anyone has had
similar experiences or possible reasons/solutions to the problem. 

  Also, could anyone share good/bad experiences with 'mainframe' TCP packages
such as IBM's TCP and Interlink's SNS TCP?

							Many Thanks,
							Mike Murphy


-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 1992 18:07:03 GMT
From:      haynes@cats.ucsc.edu (Jim Haynes)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Printers.


In article <1992Oct7.235124.29730@pacdata.uucp> johnr@pacdata.uucp (John Reed) writes:
>For the price of a used Sun3/50 (diskless, 4 Megs Ram, no monitor = $175.00
>from Minicomputer Exchange), and a little software work, you can easily make
>your own.

I spoze the down side of this is the need to maintain the 3/50, but at $175.00
you can probably afford all the spares you want.

The up side of this, and the reason I have a hard time taking tcp/ip printers
seriously, is that you may not want the printer printing just anything that
is thrown at it over the network.  I haven't looked at these printers, so
I don't know what kind of access controls and accounting they offer,
but I'd be surprised if they are as configurable as some of us would like.

There are those of us who would like to have Kerberos authentication,
perhaps a list of people who are allowed to print on a certain printer,
perhaps accounting, print quotas, etc.
-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle


-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Oct 1992 18:20:53 GMT
From:      bob@astph (Bob Ford)
To:        comp.protocols.tcp-ip
Subject:   Problems with Talk & Telnet

The first paragraph is a repost:
We are having problems getting talk to run on some of our terminals,
using ISC/Sunsoft UNIX 3.0, TCP/IP version 1.3, on 386 & 486's.  Talk 
works fine between consoles and virtual terminals, either on a local
system or between two remote machines.  However, when trying to talk
to or from a Wyse 60, or a Televideo tvi950, problems arise  :(
For the Wyse, the keyboard freezes up, and only an interupt frees it
up.  For the tvis, the screen turns to funky arabic-type characters,
and only an exit will restore sanity to the screen.
 
This is new material:
We have discovered similar problems with telnet not working from Wyse
60 or Tvi950 terminals.  We get a login prompt, but the keyboard locks
up, and the connection times out.  Rlogin works fine from both the
Wyse and Tvi terminals, and telnet works fine from the console.

We have also unearthed hassles with rlogin from the terminals when
we try to use VP/ix on the remote systems.  From a Wyse 60, when
VP/ix is accessed, the keyboard has echoing problems, ie., when it
switches into PC Term mode, each keystrike produces two characters,
one on the downstroke, and one on the upstroke.  Once again, 
everything works perfectly from the console

We called ISC/SunSoft about this.  Their explanation was that most
of the tcp/ip functions work in 7 bit mode, and that the 8th control
bit was stripped off.  Hence, nothing will work from the terminals.
They suggested trying to run rlogin in 8 bit mode to get around the
VP/ix problem, but it didn't help.

So, what do we do?  Does ISC's explanation make sense?  Is there a
workaround?  Is there hope?
-- 
Bob Ford                           (814) 234-8592x36
INTERNET: astph!bob@attmail.com     UUCP: attmail.com!astph!bob
Philadelphia Phillies

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 92 19:32:30 GMT
From:      booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
To:        comp.protocols.tcp-ip
Subject:   Silly Window Problem resolved (WAS: Silly windows, PERSIST timers...)

I'll explain, to the best of my understanding, how we resolved the silly
window problem (for anyone who cares) in a moment.  First, I wanted to
respond to the issue raised in the following post.

In article <1992Oct6.215933.7706@news.eng.convex.com> jjensen@convex.com (James Jensen) writes:
>booloo@framsparc.ocf.llnl.gov (Mark Boolootian) writes:
>
>In your first message you said you filled the 16k window with a single send
>but here you say you are using fddi.  Are you doing something funny 
>with the mtu, or do you mean send, as in "send()"?
>
>if you have a 16k mtu, and a 16k window the behavior you see can
>be explained.  Either up the window or lower the mtu. The window should
>be at least 2*the mtu used by the connection. This should be done
>automaticaly by tcp when it sets up the connection. 
>
>If mtu is 4k then I don't know what your problem is.  I would try
>increasing the send and recieve windows. 
>Jim Jensen - jjensen@convex.com

Good observation.  What we are working with are a Cray and an Amdahl, each
with a HYPERchannel connection, and the HYPERchannels are connected by FDDI.
To be precise, the Amdahl connects directly to HYPERchannel with an NSC
N220 adapter.  The Cray connects to FDDI via an NSC N130 adapter (the N130,
in this situation behaves as a router).  The MTU for the HYPERchannel is
16 KB.  Even though the Cray is "connected" to FDDI, the network interface
the Cray IOS sees is that of HYPERchannel.  Thus, the negotiated MSS is
16 KB.  As a consequence, we end up fragmenting packets on the FDDI ring.
(Probably not a good thing, and we will likely change the MTU to 4K).

Now, the explanation for our silly window situation.  We saw this problem
occur when the Amdahl sent data to the Cray.  The transfer was between
the ftp servers running on these two machines (a third-party or proxy
transfer).  I looked at the Cray daemon and found code which looks something
like this:

		while (buffer not completely filled)
			read data from network;
		write buffer to disk;

It appeared to me likely that we could be leaving data sitting in a socket
buffer when we finally decide to write out the buffer to disk.  So I changed
the code to follow every read from the network by a write to disk (the
typical approach in ftp servers).  This corrected the problem.  However,
there is one other factor which contributed to the cause of the problem.

With an MTU of 16 KB, packets are fragmented by the router tying HYPERchannel 
to FDDI (and reassembled by the Cray upon receipt).  When the MSS used was 
4 KB, and no fragmentation was occuring, we found that SWS did not occur; it
only would occur for transfers in which the MSS was 16 KB.  So, assuming we
change our MTU to 4 KB, the code change above may be superfluous.

Thanks for the responses, sorry for going on for so long.

regards,
mb
-- 
Mark Boolootian		booloo@llnl.gov		+1 510 423 1948

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 92 20:53:43 GMT
From:      mc@math.math.mv.dupont.com (Matt Cunningham-Software Development)
To:        comp.protocols.tcp-ip
Subject:   netmask - SUN/SPARC

I need to determine the netmask of say 'le0' from inside a program.  I know the
'ifconfig' command will do this for me from the command line but as I said I 
must do it from in my program.  I am aware there is an ioctl SIOCGIFNETMASK
that is supposed to get the netmask for me however the specifics of how to use
the ioctl and what structure it places the info in is not known to me.  Can
anyone shed some light on this problem and possibly explain how these ioctls
work.  I'm working on a SUN/SPARC station using SUNOS 4.1.1.


							THANKS
							Matt Cunningham
							mc@mv.dupont.com

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 92 22:50:37 GMT
From:      tron@Veritas.COM (Ronald S. Karr)
To:        comp.protocols.tcp-ip
Subject:   SLIP/PPP for SVR4.0 or SVR4.2

Does anyone have working SLIP, CSLIP, and/or PPP drivers for AT&T SVR4.0
or SVR4.2 running on Intel 386 platforms?  We have sources for a driver
that was posted to the net some time ago that supports just SLIP, and
that works on SVR4.0 version 3, but not (apparently) on version 4.  It
also has severe memory leaks.
-- 
	tron |-<=>-|		ARPAnet:  veritas!tron@apple.com
      tron@veritas.com		UUCPnet:  {apple,pyramid}!veritas!tron

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 92 00:42:22 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over Ethernet: LSAP=6 vs. SNAP

In article <1992Oct8.121124.1835@infodev.cam.ac.uk> ag129@cus.cam.ac.uk (Alasdair Grant) writes:
>
>RFC 948 specified IP on 802.3 using an LSAP of 6, i.e. the IEEE-assigned
>LSAP for IP.  RFC 1042 then obsoleted this and specified the use of SNAP,
>i.e. LSAP 170, with Ethertypes 0800 etc. as used originally.  What was the
>technical reason for this, given that it's an extra layer of encapsulation
>and longer frames?

IP over LANs depends on the use of ARP.  Given the limited number of
available 802.2 LSAPs, IEEE would not assign one for ARP, but was
convinced to allocate one for the SNAP mechanism.  Also, IP packets
following an 802.3/802.2 LLC header are on an odd alignment, causing
a performance hit in some routers.  SNAP puts the network layer header
back on a desirable alignment.  Between the need to run ARP using SNAP
and the alignment problem, it was deemed a better idea to also run IP
over SNAP.

>Was it just for people who run DIX Ethernet and 802.3 on the same cable?

You could still run DIX and 802.3/802.2 versions of IP on the same wire.
SNAP is just the preferred encoding.
SNAP has since found it's way into many other environments (FR, SMDS,
ISDN, etc).

Art

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 92 00:44:11 GMT
From:      sam@bsu-cs.bsu.edu (B. Samuel Blanchard)
To:        comp.protocols.tcp-ip
Subject:   Re: TCPIP for VAX/VMS

In article <1aup88INN8vn@huon.itd.adelaide.edu.au> dclunie@sirius.ucs.adelaide.edu.au (David Clunie) writes:
>
>We have an old Seimens MRI scanner based on a Dec VAX 750 that we want
>to put on an ethernet running TCP/IP to Suns and so on.
 
>David Clunie (dclunie@itd.adelaide.edu.au)

Process Software has a product that my old boss looked at.
The contact was Joe DelRossi  delrossi@process.com
(800)722-7770

I posted in case anyone was familiar with this product.  I only have sales
literature and a quote from 1990.  Please let me know how you solve your
problem (and I can update this old folder  :-)

-- 
B. Sam Blanchard        sam@bsu-cs.bsu.edu
418 Winfield Dr         (317) 284-7131   work
Greenfield, IN 46140

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Oct 1992 02:31:33 GMT
From:      jamesd@lna.oz.au (James D)
To:        comp.protocols.tcp-ip
Subject:   Benchmarks and Alternative protocols

Two questions: I know this is probably a FAQ, so if it is, just point
me to the FAQ file, or whatever, but I need a list of available 
benchmark tests for tcp-ip sockets. As our network contains different 
machines/configurations we wish to gain some actual data on how useful
each setup is in regards to possible real time comms between processes.

The second question follows from the above. The Ultrix OS and SunOS
make use of tcp/ip for IPC. They also allow for using other protocols,
and I would like to know if there are any alternatives available that 
give tcp/ip a run for it's money? 

I realise that its probably a question of trade-offs, but we definitly
need real-time and reliability is still quite important. At the moment
our product uses Versados, but we would like to move to Unix if we
could satisfy the real-time constraints.

Any information / discussion would be appreciated.

							-- James Duff

-- My views may reflect the views of my employer,
-- but only while he can hear me :-)


-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Oct 1992 12:05:29 GMT
From:      VAAGA@gribb.hsr.no (Vaaga, Hans Egil       7-93)
To:        comp.protocols.tcp-ip
Subject:   Once more: Reading all packets with HP 9000/700.

Hello again!

I've sent this question one time before with less details.

I will try to describe it better this time.

As I said, we are 7 students who is working for a company called HITEC (
Norwegian company). We are going to make a program in C++. This program will 
read the packets form an ethernet. Our workstation, an HP 9000/700 (using 
UNIX of course), will communicate over an ethernet using TCP/IP.

Our problem is that we need C-routines that fetch packets from the network. 
We will make C-routines that count all the packets and make other statistics 
as well. The result will be printed on screen and printer.

I hope this will make things more clear.

Thanks for all help so far.


Vaaga

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Oct 1992 13:21:41 GMT
From:      GJAMES@HUSKY1.STMARYS.CA (GJames)
To:        comp.protocols.tcp-ip
Subject:   Packet Capture

I had a program a few months ago that would capture all of the packets on my 
ethernet segment (it got deleted in a moment of stupidity). I have looked at 
gobbler, beholder, spectre and netwatch. None of these actually capture all 
of the packets on my wire. Gobbler seems to be the closest but only 
captures part of the trafficand Idont know how to configure it to get 
allof the packets. 

Am I nuts or is there a program that does this?

Thanks for any help

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Oct 1992 15:03:50 GMT
From:      wehr@fmsrl7.srl.ford.com (Bruce Wehr)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.misc,comp.os.msdos.misc,comp.os.msdos.programmer
Subject:   Programming with sockets

    I recently learned Berkeley socket programming on Interactive Unix,
    and I learned just enough to get my job done. Now, I have some
    colleagues learning socket programming on DOS, and they're coming
    to me with questions (some of which I can't answer). They're using
    the PC/TCP Development Kit from FTP Software to develop a client
    that will talk to a server running under VxWorks on a 68K VME box.

    Here's a simple, general socket question straight from Socket
    Programming 101: Once a client is connected, how does one
    disconnect? If one uses close(), then you cannot immediately use
    connect() again ... you have to call socket() again.

    Put another way: when open() is used to open a file, it does two
    things: it assigns a file descriptor and it associates that
    descriptor with a file. You can then jump right in with read()s and
    write()s. With sockets, however, the socket() call (which is like
    open) only does one of those things: it assigns a socket descriptor
    - it doesn't associate that descriptor with a server yet. You must
    call connect() before you can do any read()s or write()s. The
    question then becomes: can one disconnect (thus reversing what
    connect() did) without using close() (which would reverse both what
    connect() and socket() did)?

    Question 2 is probably specific to the FTP Software development
    kit:  they're finding that, when their client attempts to close a
    socket, the process hangs until the server closes its socket. I
    *know* this doesn't happen in the environment I'm familiar with
    (Interactive Unix on a PC). Does anyone know why this happens?
    Currently, they're getting around this by having the client send a
    "All Done" token as its last message, but they'd like to understand
    what's going on (and so would I).

    Question 3: is there any way for a DOS client to check for
    available data on a socket? Since DOS doesn't support multiple
    processes, hanging on a read() from a socket that has no data
    available may not be desirable. I started telling them about
    various ways to check for available data when I realized I was
    giving them Unix solutions, not DOS solutions (they weren't
    familiar with any of the functions I mentioned). So, does DOS or
    the FTP package provide any functions for this?

    If you're still reading this, I must thank you for enduring my
    diatribe.  Any solutions, answers or pointers thereto would be
    greatly appreciated. Please mail your responses and I'll summarize
    if there is interest. I've directed followups to me.

    Thanks.

--
               Bruce Wehr (wehr%dptc.decnet@srlvx0.srl.ford.com)
	           Ford Motor Company - Electronics Division
   Electronics Technical Center - Powertrain Electronic Controls Engineering
       17000 Rotunda Drive, Room B360, Dearborn, MI  48121 (313)248-5530

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 92 16:46:39 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over Ethernet: LSAP=6 vs. SNAP

In article <1b3cfoINNing@skat.usc.edu> tli@skat.usc.edu (Tony Li) writes:
>    IP over LANs depends on the use of ARP.  Given the limited number of
>    available 802.2 LSAPs, IEEE would not assign one for ARP, but was
>    convinced to allocate one for the SNAP mechanism.  
>
>So people frequently use HP probe as an ARP substitute when running 802.3.

Is Probe really used anywhere but on networks running older versions of HP
TCP/IP?

>    You could still run DIX and 802.3/802.2 versions of IP on the same wire.
>    SNAP is just the preferred encoding.
>
>... by the standards bodies.  Almost everyone is using (or is
>migrating towards) DIX. 

Guess I wasn't clear enough.  I was just pointing out that either
802.3/802.2/IP or 802.3/802.2/SNAP/IP would co-exist with DIX Ethernet
(all three for that matter), but that SNAP was preferred to raw 802.2.
I agree that for IP (and most non ISO protocols), DIX Ethernet is preferred.

Art

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 92 17:36:52 GMT
From:      hugues@gna.org (Hugues Lafarge)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Looking for references on Inter-Process-Communications


I'm asking this for a friend:

Being working on an remote procedure call replacement for
an experimental operating system, i'm looking for any
reference (document, software, etc...) about RPC, or any
alternative scheme.

I'm also interested in knowing if what were (if any)
previous schemes of interprocess communication (either
local or remote)

Please reply via e-mail, i'll summarize to the net
if there's any interest.

Thanks in advance.
--
Hugues Lafarge 	hugues@gna.axis-design.fr or hugues@gna.org
Voice		+33 1 40 35 20 20

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Oct 1992 17:55:12 GMT
From:      fredg@ariel.yorku.ca (Fredrick Gonsalves)
To:        comp.protocols.tcp-ip
Subject:   Internet Address to Marquette University



Does anybody know the internet address for Marquette University ??


-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 92 18:49:03 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Host Requirements testing ?


  Are there any freely distributable programs that test a host's
conformance to the requirements of the Host Requirements RFCs (RFC
1122 and RFC 1123) ?

  Please email and I'll summarise back to the list.

Ran
atkinson@itd.nrl.navy.mil

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 92 19:04:00 GMT
From:      gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546)
To:        comp.protocols.tcp-ip
Subject:   Re: TCPIP for VAX/VMS

In article <2810@bsu-cs.bsu.edu>, sam@bsu-cs.bsu.edu (B. Samuel Blanchard) 
writes...
#In article <1aup88INN8vn@huon.itd.adelaide.edu.au> dclunie@sirius.ucs.adelaide.edu.au (David Clunie) writes:
#>
#>We have an old Seimens MRI scanner based on a Dec VAX 750 that we want
#>to put on an ethernet running TCP/IP to Suns and so on.
# 
#>David Clunie (dclunie@itd.adelaide.edu.au)
# 
#Process Software has a product that my old boss looked at.
#The contact was Joe DelRossi  delrossi@process.com
#(800)722-7770
# 

There are many TCP/IP for VMS products.  Probably the best in the market
is TGV MultiNet.  They also have an Australian distribution point (you
could ask simon@internode.com.au who that is).  Their address in the USA
is sales@tgv.com, 1-800-TGV-3440.

TGV Is the only *complete* package which supports NFS Client and Server,
RMT Client and Server, as well as a host of other products in a 100%
reliable configuration.

Their software also emulates the interface to the Wollongong and DEC UCX
products, so software can be run without changes.

Disclaimer: I don't work for TGV but I love their product and use it myself!

Ehud

--
Ehud Gavron        (EG76)     
gavron@vesta.sunquest.com
With YOU, I can be MYSELF..  We don't NEED Dan Rather..

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 92 19:14:18 GMT
From:      alanlb@bethesda.cs.vt.edu (Alan L. Batongbacal)
To:        comp.protocols.tcp-ip,comp.unix.ultrix
Subject:   WANTED: spray client for Ultrix

Hi there!  I recently installed an FDDI hookup between two DECstation
5000/240's running Ultrix 4.2a and would like to see just how far I
can push the link with regard to throughput.

I got hold of tcpspray from some archive and need a responding client
on the other side (which Ultrix apparently does not provide).  Is there
source available for such a client?  If not, what do you suggest I use
as a means of benchmarking the link?

Thank you!

alan l. batongbacal

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 92 20:33:14 GMT
From:      doug@happy.vf.ge.com (Doug Hughes)
To:        comp.sys.sun.misc,comp.protocols.tcp-ip
Subject:   Setting up UDP socket for broadcast


I have set the SO_BROADCAST option using setsockopt on a udp DGRAM
socket.  However, this has proved in sufficient to send a broadcast
message.  What other steps need I do to send a broadcast message to
port 2074 on all machine on the subnet?  I would prefer not to muck
around with the nit_pf filters if possible. Though, if need be,
I can do it this way.
  Any help pointers would be appreciated
-- 
_____________________________________________________________
Doug Hughes
Software Developer - GE Aerospace (M&DSO), Valley Forge, PA
doug@happy.vf.ge.com	or	hughes@sde.mdso.vf.ge.com

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 92 20:52:14 GMT
From:      hughes@sde.mdso.vf.ge.com (Hughes Doug)
To:        comp.sys.sun.misc,comp.protocols.tcp-ip
Subject:   Re: Setting up UDP socket for broadcast

In article <1992Oct9.203314.24657@knight.vf.ge.com>, doug@happy.vf.ge.com (Doug Hughes) writes:
> 
> I have set the SO_BROADCAST option using setsockopt on a udp DGRAM
> socket.  However, this has proved in sufficient to send a broadcast
> message.  What other steps need I do to send a broadcast message to
> port 2074 on all machine on the subnet?  I would prefer not to muck
> around with the nit_pf filters if possible. Though, if need be,
> I can do it this way.
>   Any help pointers would be appreciated
> -- 
> _____________________________________________________________
> Doug Hughes
> Software Developer - GE Aerospace (M&DSO), Valley Forge, PA
> doug@happy.vf.ge.com	or	hughes@sde.mdso.vf.ge.com

Never mind! I figured it out myself! I had set the host part to 255
but I had forgotten to set the subnet mask portion (we use a different
subnet mask than the default 255.255.255.0)

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Oct 1992 21:35:38 GMT
From:      jjensen@convex.com (James Jensen)
To:        comp.protocols.tcp-ip
Subject:   Re: Silly Window Problem resolved (WAS: Silly windows, PERSIST timers...)

booloo@framsparc.ocf.llnl.gov (Mark Boolootian) writes:
-
- transfer).  I looked at the Cray daemon and found code which looks
something
- like this:
-
-               while (buffer not completely filled)
-                       read data from network;
-               write buffer to disk;
-

If what I think is happening, is and the read buffer is <16k This may not
completly fix the problem.  You may want to change the above code to:

                while (buffer has 16k more space)
                        read data from network;
                write buffer to disk;
for better performance.

-
- only would occur for transfers in which the MSS was 16 KB.  So,
assuming we
- change our MTU to 4 KB, the code change above may be superfluous.

The ip fragmentation is probably not your problem, but it is icky. I
would suggest changing your MTU to 4k(what ever FDDI's is).  That
would get rid of your problem.

I don't think what you have is silly window syndrome, which involves
sending silly amounts of data that gets the connection stuck in
a rut of sending less that mtu sized packets.

What I think you see is:
incoming 16k packet wakes up read which does a 5k read. This 
causes the first window update because your 
advertized window(0) is < 65% of your window(5k)
ftp does another read and gets 8k (is the read buffer 8k?)
this causes the 8k window update(13k total) because the 
advertized window(5) is < 65% of your window(13k)
ftp does another read of 3k, but 
advertized window(13) is > 65% of your window(16k)
so No window update.

Meanwhile, back on the sending side, tcp *really* wants to send
an mtu sized packet and is waiting for the window update 
which it doesn't get until the receiving side times out
and does a delayed ack.

At least thats what Berkeley tcp would do.

Jim Jensen - jjensen@convex.com

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 92 22:31:23 GMT
From:      booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
To:        comp.protocols.tcp-ip,comp.benchmarks
Subject:   Re: TCP/IP Benchmarks

In article <qdtg0po@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>The primary source for ttcp is brl.mil.  BRL evidently does not
>consider it a benchmark, but a file transfer protocol.  That's
>why they insisted on keeping the crazy -s default.

I think Mr. Schryver probably means ftp.brl.mil (128.63.16.158).  You can find 
ttcp.c under /pub on that machine.

mb
-- 
Mark Boolootian		booloo@llnl.gov		+1 510 423 1948

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Sat, 10 Oct 1992 01:24:39 GMT
From:      ricardo@malloco.ing.puc.cl (Ricardo Schmutzer von Oldershausen)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Help Needed in installing SUN RPC sources...

Just remove "static" from the index() declaration.
It worked for me but have not tested properly the generated code.

Ricardo Schmutzer
ricardo@ing.puc.cl


-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 92 20:44:02 GMT
From:      pmod@pfbs.philips.se (Par-Mikael Odsater)
To:        comp.protocols.tcp-ip
Subject:   KEEPALIVE ?????

Hi Netters,

Does anybody know what KEEPALIVE is?

Please send me a e-mail if you know.

Best, P-M
--
 Par-Mikael (P-M) Odsater           | Digital Equipment BCFI AB
                                    | Box 904
 pmod@pfbs.philips.se               | S-175 29 Jarfalla, Sweden 
 ..!mcsun!seunet!dakotaS!pmod@pfbs  | Phone: +46 8 7594928, Fax: +46 8 7398676

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Sat, 10 Oct 1992 20:50:28 GMT
From:      helen@pulua.hcc.hawaii.edu (Helen Rapozo)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet on Mac SE's & Plus's

In article <3801@eastman.UUCP> lrxi00@icts01.Kodak.COM (James Nonnemacher) writes:
>Does anyone know if it's possible to connect Mac SE's and Plus's to an ethernet network? If so, where 
>can the adapters be purchased.
**********
We got an Ethernet adapter for a Macintosh SE from 3Com.  It was called the
EtherLink/SE Adapter.  3Com's address is 3164 Kifer Road, Santa Clara, CA
95052-8145.  My only gripe with this adapter is that you cann't leave
just the finder's background window clear (it needs a window to be
open at all times, otherwise it just loops on it).

As a suggestion if you have a lot of Macintosh SE or Plus to connect
to the Ethernet network, you might want to use their AppleTalk
network and then use a GatorBox or FastPath to route AppleTalk to
Ethernet packets.



Honolulu Community College            cs_rapozo@hccadb.hcc.hawaii.edu
874 Dillingham Blvd.                  helen@pulua.hcc.hawaii.edu
Honolulu, HI 96817                    rapozo@uhunix.uhcc.hawaii.edu
Ph#: (808) 845-9202

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Sun, 11 Oct 1992 05:30:19 GMT
From:      merce@xenitec.on.ca (Jim Mercer)
To:        comp.protocols.tcp-ip,aus.wanted
Subject:   Re: AS400s and Suns together

In article <elogan.718304279@mistxt.oc.com> elogan@mistxt.oc.com (Ernie Logan) writes:
>merce@xenitec.on.ca (Jim Mercer) writes:
>
>>telnet into the AS/400 requires tn3270 or tn5250 (the latter is hard to find).
>
>Well, Jim, I tend to agree with most of what you said, except that TN5250
>is hard to come by. You only need to email info@oc.com, or call or write:

hmmm, you forgot your smiley.

when there is basically only one source, and a commercial one, for a telnet
flavour, i would call that hard to come by.

8^)

i have a demo version of the Open Connect TN5250 for MSDOS, which i have not
had a chance to try out yet.  (RSN now, as the boss is getting a little
impatient).

my only bitch about this product (which i have not tried), and others like
it, is that it is only available for specific TCP/IP stacks.

why can you not produce one for those of us (especially in the academic
world) that don't use a specific kernel (ie. FTP, B&W, LWP, etc).

can you not put a TCP kernel in your product?

if not, i know someone who would do it as a piece work contract.  8^)

another note:  we have just received a blurb from IBM about the "new"
release, which will support incoming VT100 (yeaaa!!!) and outgoing VT100
telnet sessions (how is this done on a block mode terminal?)

ernie, maybe you can give us some technical info that would be real useful.

how many sessions will the current and "new" versions support? (incoming)

also, how much of a load does telnet put on the system, compared to say
PC Support, which don't work worth a shit over ethernet (ok, it works, but
it requires the MSDOS workstation to run ODI, NDIS and LANSUP all at once,
not to mention that the terminal emulation is only implemented as a TSR,
so you need bazillions of spare bytes.)

answer these simple questions, and you'll build up some USENET karma points.

[ disclaimer: it's Sunday morning, at 1:30 AM, and i was out octoberfesting,
  so the format of this article may not follow my norms. ]

-- 
[ Jim Mercer   Reptilian Research  merce@iguana.reptiles.org  +1 519 893-6085 ]
[             I don't want to work for a company that has a CIO.              ]
[              Disclaimer! I don't need no stinking Disclaimer!               ]

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Sun, 11 Oct 1992 08:36:34 GMT
From:      peter@cujo.curtin.edu.au (Peter N Lewis)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.sys.sun.hardware
Subject:   PCRoute <-> Sun SPARC Slip-4.1 problems

Hi All,

I've got PCRoute on an 8MHz IBM PC Clone connected via a 9600 baud
permanent modem link to a SPARC2 running slip-4.1.  It works fine for
the most part, but on large TCP sends from the SPARC to PCRoute, the
connection dies (eg, ftp put, or Sendmail transfers from the Sun to
machines connected via ethernet to the PCRoute box work fine if they are
short, but if they are larg (>30k) the connection aborts part way thru).
Connections in the other direction have no problems.

I don't really even know where to start looking.  It would seem likely
that the fault is on the Sun end, since I have PCRoute running at
another location (to a terminal server) without the problem.  It may be
to do with a lack of handshaking, since I'm not certain what the
handshaking setup on the sun, modems, or pcroute box is (the modems are
syncronous with sync<->async addapters at each end, just to confuse the
issue).

netstat -s says:
ip:
        166003 total packets received
        0 bad header checksums
        0 with size smaller than minimum
        0 with data size < data length
        0 with header length < data size
        0 with data length < header length
        255 fragments received
        0 fragments dropped (dup or out of space)
        0 fragments dropped after timeout
        71435 packets forwarded
        0 packets not forwardable
        0 redirects sent
        0 ip input queue drops
icmp:
        4 calls to icmp_error
        0 errors not generated 'cuz old message too short
        0 errors not generated 'cuz old message was icmp
        Output histogram:
                destination unreachable: 4
        0 messages with bad code fields
        0 messages < minimum length
        0 bad checksums
        0 messages with bad length
        Input histogram:
                destination unreachable: 2
                source quench: 2
        0 message responses generated
tcp:
        60804 packets sent
                45803 data packets (2902623 bytes)
                1363 data packets (683114 bytes) retransmitted
                12116 ack-only packets (10569 delayed)
                0 URG only packets
                4 window probe packets
                603 window update packets
                915 control packets
        91424 packets received
                45181 acks (for 2857596 bytes)
                1260 duplicate acks
                0 acks for unsent data
                45002 packets (3448495 bytes) received in-sequence
                492 completely duplicate packets (111043 bytes)
                48 packets with some dup. data (11473 bytes duped)
                1846 out-of-order packets (738127 bytes)
                0 packets (0 bytes) of data after window
                0 window probes
                589 window update packets
                5 packets received after close
                0 discarded for bad checksums
                0 discarded for bad header offset fields
                0 discarded because packet too short
        239 connection requests
        396 connection accepts
        632 connections established (including accepts)
        680 connections closed (including 37 drops)
        3 embryonic connections dropped
        43539 segments updated rtt (of 44407 attempts)
        814 retransmit timeouts
                31 connections dropped by rexmit timeout
        6 persist timeouts
        1 keepalive timeout
                1 keepalive probe sent
                0 connections dropped by keepalive
udp:
        0 incomplete headers
        0 bad data length fields
        0 bad checksums
        0 socket overflows

A diff before and after a failed ftp put from the sun shows:

[Most zero entries not shown]
ip:
        721 total packets received
        13 packets forwarded
tcp:
        510 packets sent
                385 data packets (78038 bytes)
                62 data packets (56398 bytes) retransmitted
                49 ack-only packets (30 delayed)
                14 control packets
        697 packets received
                365 acks (for 75155 bytes)
                40 duplicate acks
                0 acks for unsent data
                277 packets (568 bytes) received in-sequence
                0 completely duplicate packets (0 bytes)
                0 packets with some dup. data (0 bytes duped)
                5 out-of-order packets (0 bytes)
                0 packets (0 bytes) of data after window
                0 window probes
                7 window update packets
                1 packets received after close
                0 discarded for bad checksums
                0 discarded for bad header offset fields
                0 discarded because packet too short
        4 connection requests
        7 connection accepts
        11 connections established (including accepts)
        12 connections closed (including 1 drops)
        0 embryonic connections dropped
        323 segments updated rtt (of 341 attempts)
        19 retransmit timeouts
                1 connections dropped by rexmit timeout
        0 persist timeouts
        0 keepalive timeout
                0 keepalive probe sent
                0 connections dropped by keepalive

So, anyone got any ideas?  THANKS for any info!
   Peter.


-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Sun, 11 Oct 1992 17:39:08 GMT
From:      merce@xenitec.on.ca (Jim Mercer)
To:        comp.protocols.tcp-ip
Subject:   Re: AS400s and Suns together

In article <9947@kralizec.zeta.org.au> nick@kralizec.zeta.org.au writes:
>merce@xenitec.on.ca (Jim Mercer) writes:
>
>>personally i think an AS/400 would make an excellent news server. 8^)
>>(they tend to have oodles of memory and disk space)
>
>I'm going to try it later this year. Keep the news on an nfs-mounted
>partition. I hope the AS/400 supports links!

AS/400 TCP does not support NFS.

my reference about was with regards to potentially implementing nntp using
RPG (one of the languages supported by the TCP API)

anyone got a good C to RPG converter?  8^)

-- 
[ Jim Mercer   Reptilian Research  merce@iguana.reptiles.org  +1 519 893-6085 ]
[             I don't want to work for a company that has a CIO.              ]
[              Disclaimer! I don't need no stinking Disclaimer!               ]

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Sun, 11 Oct 1992 18:11:41 GMT
From:      normi@hugo.uucp (Norman Dutton)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: Looking for references on Inter-Process-Communications

In article <HUGUES.92Oct9183652@gna.gna.org> hugues@gna.org (Hugues Lafarge) writes:
>
>I'm asking this for a friend:
>
>Being working on an remote procedure call replacement for
>an experimental operating system, i'm looking for any
>reference (document, software, etc...) about RPC, or any
>alternative scheme.
>
>I'm also interested in knowing if what were (if any)
>previous schemes of interprocess communication (either
>local or remote)
>
>Please reply via e-mail, i'll summarize to the net
>if there's any interest.
>
>Thanks in advance.
>--
>Hugues Lafarge 	hugues@gna.axis-design.fr or hugues@gna.org
>Voice		+33 1 40 35 20 20

O'Reilly & Associates has a book in their 'Nutshell' series called 'Power
Programming with RPC' ISBN 0-937175-77-3.  They have a European distributor
in the Netherlands:

Addison-Wesley Publishing Group
Concertgebouwplein 25
1017 LM Amsterdam
The Netherlands
Telephone: 31-20-671-72-96
Fax 31-20-664-53-34

Other than getting a copy of 'Managing uucp and Usenet' from UUNET when we
got an account with them, I have no connection with O'Reilly and Associates.

-- 
--
Norman Dutton;                  | uucp:    uunet!hugo!normi
D & M Associates                | Internet: hugo!normi@uunet.uu.net
4208 Evergreen Lane, Suite 213  | Voice: 1.703.941.7526 or 1.703.777.5677

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 92 22:40:39 GMT
From:      johnh@nnshh127.uucp (John Hawkins)
To:        comp.protocols.tcp-ip
Subject:   telnet & packet size


   We are currently using telnet to connect to host manchines -->
   Which is not a problem in itself, when the connection is made via
   a LAN.  However if we have many users connect via tcp/ip and telnet
   over our WAN, the number of packets being sent to and fro is unacceptable.
   Many of these packets being sent from  pc's contain only one character!
   Could someone help me out here?
   I have heard of IP header compression, but don't have any useful knowledge.

   I already have optimized the telnetd daemon on the unix side to send the
   largest packets possible!

   Any ideas are welcome!  e-mail nvjhh01@NT.COM

   THANKS, rather new to this subject:)

-- 
John Hawkins       }) #define disclaimer(x) printf(stderr," x\n");
Northern Telecom   }) Communication: Voice 615 734 4468   /* Able was I ere */
200 Athens Way     {)                Fax   615 734 4771   /* I saw Elba     */
Nashville TN 37728 {) Internet:  nvjhh01@NT.COM           /* Columbus ~1492 */

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Oct 1992 04:12:40 GMT
From:      hsu@cs.hut.fi (Heikki Suonsivu)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.sys.sun.hardware
Subject:   Re: PCRoute <-> Sun SPARC Slip-4.1 problems


In article <1992Oct11.083634.25880@cujo.curtin.edu.au> peter@cujo.curtin.edu.au (Peter N Lewis) writes:
   the most part, but on large TCP sends from the SPARC to PCRoute, the

I have seen this, when the PC has old ethernet cards with small buffers
(wd8003 with 8K and 3c501 with 1K?).  Suns want to send large 8K packets,
thus overflowing the PC ethernet card.  I think you can cut down the packet
size in SunOS kernel configuration somewhere, but I don't know how.
I solved the problem by getting new ethernet boards.  I guess theoretically
you might be able to patch pcroute to munge tcp initialization packets to
make them look like that the other end wants to receive small packets, but
I'm not sure, don't know TCP well enough.

The symptom is because TCP does not make packet size smaller when a
transmit fails.  Thus, it will keep retrying the packet too large, and
finally drops dead :-(

-
Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND,
hsu@{otax.tky.hut,cs.hut,clinet}.fi  +385-0-8031121
/G=Heikki/S=Suonsivu/O=hut/OU=cs/PRMD=Inet/ADMD=Fumail/C=FI,
mcsun!hutcs!hsu, riippu SN, Email preferable.

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Oct 92 04:32:03 GMT
From:      larry@vishnu.eco.twg.com (Lawrence B. Henry III)
To:        comp.protocols.tcp-ip
Subject:   Re: TCPIP for VAX/VMS


In article <9OCT199212040916@spades.aces.com>, gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546) writes:
|>Path: eco.twg.com!uunet!sunquest!spades.aces.com!gavron
|>From: gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546)
|>Newsgroups: comp.protocols.tcp-ip
|>Subject: Re: TCPIP for VAX/VMS
|>Message-ID: <9OCT199212040916@spades.aces.com>
|>Date: 9 Oct 92 19:04:00 GMT
|>References: <1aup88INN8vn@huon.itd.adelaide.edu.au> <2810@bsu-cs.bsu.edu>
|>Sender: news@sunquest.UUCP
|>Reply-To: gavron@ACES.COM
|>Organization: ACES Consulting Inc.
|>Lines: 34
|>News-Software: VAX/VMS VNEWS 1.4-b1
|>
|>In article <2810@bsu-cs.bsu.edu>, sam@bsu-cs.bsu.edu (B. Samuel Blanchard) 
|>writes...
|>#In article <1aup88INN8vn@huon.itd.adelaide.edu.au> dclunie@sirius.ucs.adelaide.edu.au (David Clunie) writes:
|>#>
|>#>We have an old Seimens MRI scanner based on a Dec VAX 750 that we want
|>#>to put on an ethernet running TCP/IP to Suns and so on.
|># 
|>#>David Clunie (dclunie@itd.adelaide.edu.au)
|># 
|>#Process Software has a product that my old boss looked at.
|>#The contact was Joe DelRossi  delrossi@process.com
|>#(800)722-7770
|># 
|>
|>There are many TCP/IP for VMS products.  Probably the best in the market
|>is TGV MultiNet.  They also have an Australian distribution point (you
|>could ask simon@internode.com.au who that is).  Their address in the USA
|>is sales@tgv.com, 1-800-TGV-3440.
|>
|>TGV Is the only *complete* package which supports NFS Client and Server,
|>RMT Client and Server, as well as a host of other products in a 100%
|>reliable configuration.
|>
|>Their software also emulates the interface to the Wollongong and DEC UCX
|>products, so software can be run without changes.
|>
|>Disclaimer: I don't work for TGV but I love their product and use it myself!
|>
|>Ehud
|>
|>--
|>Ehud Gavron        (EG76)     
|>gavron@vesta.sunquest.com
|>With YOU, I can be MYSELF..  We don't NEED Dan Rather..
|>
Before everyone gets too fired up about this.. I think what Ehud is trying to
say is check out what is out there before you go off and just buy Process or
anyone's TCP on VMS.. since there are lots of packages *complete* or otherwise
it just depends on your point of view and preferences.. If you like a TOPS
interface, a DCL interface or whatever.. ;-)

-Larry.
The Wollongong Group.

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 92 04:34:12 GMT
From:      ce1zzes@prism.gatech.EDU (Eric Sheppard)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   PC-NFS: yp_match failed

Our Sun Sparc 2 has been very frequently reporting this error message,
since we brought it up as a server for 25 PC's running PC-NFS 4.0a:

Oct  8 14:21:10 ce pcnfsd[125]: rpc.pcnfsd: yp_match failed

Which end is this coming from?  Do we have a rogue PC in our lab causing
this error message?  And finally, what could be done to correct it?

Any thoughts or helpful tips appreciated.
Eric
-- 
Eric Sheppard      Georgia Tech    |   "Of course the US Constitution isn't
Atlanta, GA                        | perfect, but it's a lot better than what
ARPA: ce1zzes@prism.gatech.edu     |             we have now." -Unknown
uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!ce1zzes

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Oct 1992 17:28:43 GMT
From:      kent@manzi.unx.sas.com (Paul Kent)
To:        comp.sys.hp,comp.protocols.tcpip
Subject:   accept() failures and how to deal with




hi y'all


i support a tcpip application that serves multiple clients and 
multiplexes those clients using a home grown tasking library
together with select() to see which clients are in need
of "service".


sooner or later i run out of file handles in my server process
and i get into trouble as the accept() call fails with ENFILE or
EMFILE. 



i witness have two snags i'd like your wisdom on.

1) the error condition is not reflected in the clients connect()
   call until i close the listen() socket.

2) the server goes into a loop, as there is always something
   ready according to select() == the listen socket is always
   ready...



it seems that a failed accept() does not remove the request
from the queue of "connectees" lined up on the listen()
socket, nor does it reflect an error to the connectee.
(at least i have a toy program that verifies this on HPUX 8.07,
SUNOS 4.1 and AIX 3.2)



my strategy is to close and then reopen the listen socket. that
delivers an error to the client's connect() and saves me from looping
till i get another attempted connect in my server, whereupon i do the same
open/close shuffle. hoping that some other client has "left" in the
meantime.




how have other folks dealt with this? my guess is that most
applications can spawn another instance of the server process
-- this is not practical for my application as we dont have the
infrastructure needed to allow two or more server processes to
share the same open files.

i don't want to go the udp route. i dont want to reinvent all
the guarenteed delivery byte stream semantics i take for granted
with tcp/ip...  for now, i setrlimit(RLIMIT_NOFILE, ... bignumber ...)
and live with the limitations..


any war stories out there that might help me out?




thanks
paul.

-- 

Paul Kent (SQL r&d)                   " nothing ventured, nothing disclaimed "
kent@unx.sas.com         SAS Institute Inc, SAS Campus Dr, Cary NC 27513-2414.

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 92 18:02:49 GMT
From:      heading@breeze.rsre.mod.uk (Anthony J.R. Heading)
To:        comp.protocols.tcp-ip
Subject:   A cheap router - suggestions?

I envisage a situation arising where I have a local ethernet
with Unix workstations, and also a 64K X.25 line which expects
serial input - SLIP or PPP I guess. And I will want to connect
the two. What's the best way to do it?

a) Buy a Cisco or some sort of dedicated router?

b) slattach the serial line of a Sun and let it happen
   automatically - how fast could that run?

c) Buy a 486 PC?
    i)  running BSD Unix
   ii)  running a dedicated packet filter
        Does such a program exist in the PD?


Any opinions?

Anthony
------------------------------------------------------------
Defence Research Agency, St. Andrews Road, Malvern, Worcs, UK.
heading@hermes.mod.uk            Work: +44 684 896066
heading@ccint1.rsre.mod.uk       Home: +44 684 563596
-- 
Anthony Heading  (heading@hermes.mod.uk)
DRA Malvern, UK
Any opinions expressed are my own and in no way
represent those of my employer or any other organization.

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 92 18:10:25 GMT
From:      tomc@cse.HauppaugeNY (Tom Canino)
To:        comp.protocols.tcp-ip
Subject:   BREAK via TLI


I have an application that establishes a connection using TLI and then
pops "timod" off the stream and pushes "tirdwr" on to the stream so
that the read(2) and write(2), etc., system calls can be used.  I can
successfully transfer data using this connection, but I am
having difficulty transmitting a break over the network.  

Is there a way to transmit a BREAK on a TLI connection which has the
tirdwr module pushed on it?

By the way, I'am running a NCR System 3000, Unix 2.0, WIN-TCP 2.00.03.00

Thanks in advance for any insight.  :)

Please email your response and I'll post a summary to the net.

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 92 18:41:04 GMT
From:      sam@bsu-cs.bsu.edu (B. Samuel Blanchard)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet & packet size

In article <1992Oct11.224039.11856@bnr.ca> johnh@nnshh127.uucp (John Hawkins) writes:
>   Many of these packets being sent from  pc's contain only one character!
>   Could someone help me out here?
Our terminal serves have an option to send data based on number of characters
or a timeout value.  This is a very common configuration option.  stty on many
UNIX systems has settings for this.  If you convey the package on the PCs then
you might get a more specific response.

>   I have heard of IP header compression, but don't have any useful knowledge.
IP header compression is great where applicable.  Your problem with single
characters/packet is not related.  Your overall traffic problem could be.
I am not really qualified to give much more :-)

>   Any ideas are welcome!  e-mail nvjhh01@NT.COM
>John Hawkins       Internet:  nvjhh01@NT.COM

I am just now placing PCs on our backbone and very much would like to hear
how you solve your problem.

-- 
B. Sam Blanchard        sam@bsu-cs.bsu.edu
418 Winfield Dr         (317) 284-7131   work
Greenfield, IN 46140

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Oct 1992 21:18:52 GMT
From:      sbinder@hpfcso.FC.HP.COM (Stephen Binder)
To:        comp.protocols.tcp-ip
Subject:   Network Management: References??

I am a Network Engineer for a large computer manufacturer with the
responsibility for defining our site (campus of 4 buildings, 2700 people, 3500
networked devices) strategy for local area network management.  The goal of 
my project is to define processes for network management that could be offered
to our site customers.  This process for network management will include (as
a start) network performance monitoring, fault management, account management,
and configuration management.  Lucky for us the network consists of mainly
TCP/IP devices running SNMP.

I have been doing some investigation, including trying to locate reference
materials for network management  (TCP/IP and SNMP environment).

I came across a book recently published by Addison-Wesley:
"Network Management: A Practical Perscpective" by Leinwand & Fang.

The book is a fairly extensive overview of Network Management including the 5
OSI areas: Fault, Performance, Configuration, Security, and Account Management.

It has good sections regarding SNMP and MIB (this was one of its strengths).  Itgives the reader just what it says: A PRACTICAL approach to managing LANs/WNAs
and dicusses several approaches using what it calls: "A simple tool; a more
complex tool; and an advanced tool".

Several questions:

1) Those of you chartered with providing Network Management Services or
   responsible for the Management of your LAN(S), have you suggestions for 
   additional references; have you read the book, what do you think?
2) Have you suggestions for implementing quality fault, configuration, 
   performance monitoring net mgmt services for a complex network?
3) What tools/processes have you used with a)great success, b) moderate
   success, c) limited or no success?

Thank You for any insights you may have.

Stephen Binder
+------------------------+---------------------------------------------------+
|   HEWLETT/  /          |  Stephen Binder                                   |
|         /hp/           |  Telecommunications Engineer                      |
|        /__/PACKARD     |  3404 East Harmony Road  MS#12                    |
|   Fort Collins Site    |  Ft. Collins, Colorado   80525                    |
| Networking & Computing |  INTERNET: sbinder@fc.hp.com                      |
|       Services         |  HPDesk  : stephen_binder@hp4000                  |
|  Data Networks Group   |  (303)-229-3236   Telnet 229-3236                 |
 +------------------------+---------------------------------------------------+

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 92 00:30:14 GMT
From:      dbox@net4.ics.uci.edu (Don Box)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   XTI References

I'm looking for references on XTI.  Can someone tell me via email
where to find them (hopefully in electronic form).

Thanks in advance,
DB

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 92 01:58:29 GMT
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: A cheap router - suggestions?

In article <Bw0stF.Lz3@breeze.rsre.mod.uk> heading%hermes.mod.uk@relay.mod.uk writes:
>I envisage a situation arising where I have a local ethernet
>with Unix workstations, and also a 64K X.25 line which expects
>serial input - SLIP or PPP I guess. And I will want to connect
>the two. What's the best way to do it?
>
   See if any of your Unix workstation vendors have the magical
   "glue" layer code which allows you to run TCP/IP over X.25.
   There are two ways of doing this...the "milnet" style just
   maps between X.25 and IP addresses.  The "csnet" [computer
   science net] style uses mapping tables to convert IP address to
   the appropriate X.25 address.    

   Most have it, most implementations I've seen interoperate quite
   well.  

   If I recall correctly, Perdue did a lot of the background on
   this...there is an RFC, but the Perdue papers are far more
   informative.   

   The nice thing about the TCP/IP on X.25 implementation is that
   you can still use the same X.25 circuit for OTHER protocols at
   the same time.  The number of virtual circuits used for TCP/IP is
   usually configurable.   


>a) Buy a Cisco or some sort of dedicated router?
>
   You'd need two...one at each end of the link.   They don't use
   the CSNET type of TCP/IP on X.25.

   

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Oct 1992 02:40:05 GMT
From:      smackie@lager.cisco.com (Scott Mackie)
To:        comp.protocols.tcp-ip
Subject:   Re: A cheap router - suggestions?

In article <183863@pyramid.pyramid.com>, lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:
|>
|>    [Stuff deleted]
|> 
|>    The nice thing about the TCP/IP on X.25 implementation is that
|>    you can still use the same X.25 circuit for OTHER protocols at
|>    the same time.  The number of virtual circuits used for TCP/IP is
|>    usually configurable.   

Minor terminology quibble:

X.25 is able to open multiple circuits down the same bit of cable that
may support a protocol per circuit. If you want to run multiple protocols
over the *same circuit* then you start having to do things like put SNAP
encapsulations at the start of the data (or some other form on unique
id field), i.e. add more "protocol" data.

Not many generic IP/X.25 encapsulators support this (if any). Most use
the Call User Data == 0xCC method and assume that all the data on that
circuit will be encapsulated IP.

|> >a) Buy a Cisco or some sort of dedicated router?
|> >
|>    You'd need two...one at each end of the link.   They don't use
|>    the CSNET type of TCP/IP on X.25.

Modesty prevents me from commenting on this... 

;-)

Scott...

-- 
---
Scott Mackie, Engineering      Email   : smackie@cisco.com
Cisco Systems Inc,             Paper   : (415) 688 8282
Menlo Park, CA94025            Voice   : (415) 688 4642
                               Quote   : "Then Fluffy realised her mistake"

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 92 14:18:20
From:      kdorota@kruuna.hut.fi
To:        comp.protocols.tcp-ip
Subject:   PC-NFS_4.0 for SysVR3.2


I'm looking for PC-NFS 4.0  for Unisys 6000/50 SysVR3.2.
Tell me please via email where to find it.

Thanks in advance,
KD
*------------------------------------------------------------------------*
! Krzysztof DOROTA, Helsinki University of Technology,  Administration
! Office, Information Systems,       Otakaari 1, SF-02150 Espoo Finland
! Voice: + 358 0 4512012,  Fax: + 358 0 464788,  E-mail: kdorota@hut.fi 
*------------------------------------------------------------------------*

--

*------------------------------------------------------------------------*
! Krzysztof DOROTA, Helsinki University of Technology,  Administration   !
! Office, Information Systems,       Otakaari 1, SF-02150 Espoo Finland  !
! Voice: + 358 0 4512012,  Fax: + 358 0 464788,  E-mail: kdorota@hut.fi  !
*------------------------------------------------------------------------*


-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Oct 1992 12:11:11 GMT
From:      kemenade@hsacsd.signaal.nl (Van Kemenade ba)
To:        comp.protocols.tcp-ip
Subject:   IGMP info wanted

Hello everybody,

I'm having the following problem:

We have an application that broadcasts messages on our local network.
Since every connected node is bothered with these messages (even if it 
is not interested in them) we want to use multicasted messages.

I heard there is a protocol called IGMP (see RFC 1112) on top of IP 
which allows to send messages to a group of nodes (multicast) instead 
of to an individual node (unicast) or to every node (broadcast).

Our local network consists of, among others, DEC5000's, SUN3's and SUN4's

Questions
1) Is IGMP available on DEC5000, SUN3 and SUN4 ?
2) Is it or will it be always part of the TCP/IP package, or just an 
   extension ?
3) How can I use IGMP, when, in what release ?
4) Will it be a standard, will it be implemented by many vendors ?
5) Is it my only alternative to multicast ?

If you have any help, suggestions, information etc, please reply by e-mail.

Thanks,

                 John
--
J.M.F.M. v. Kemenade, Hollandse Signaal Apparaten bv, Civil Systems Division
Oude Apeldoornseweg 41-45,  PO. box 245, 7300 AE APELDOORN,  The Netherlands
Tel: +31-55-433287,  Fax: +31-55-432553,   Email: kemenade@hsacsd.signaal.nl
--





-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 92 12:39:38 GMT
From:      long@ceb.csb (L. Rodney Long)
To:        comp.protocols.tcp-ip
Subject:   Tools for TCP/IP Internet Performance

Keywords:tools,TCP/IP,Internet,performance

I'm looking for software tools to help understand TCP/IP performance
for Internet transmission of some large image files.  I would like
to collect route data showing the specific route taken by packets,
the delays between routers, and some statistical information on
the number of  lost packets and retransmissions.

We're running SunOS 4.1.3 on on a Sun 670MP.  If you have any
suggestions, I would appreciate a note.

Thanks.

Rodney Long

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Oct 1992 13:48:43 GMT
From:      stewart@tweety.cis.udel.edu (John Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Management: References??

In article <7250004@hpfcso.FC.HP.COM> sbinder@hpfcso.FC.HP.COM (Stephen Binder) writes:
>1) Those of you chartered with providing Network Management Services or
>   responsible for the Management of your LAN(S), have you suggestions for 
>   additional references;

Probably the most widely read book on this subject is Rose's _The Simple
Book: An Introduction to the Management of TCP/IP-based Internets_.  I
don't know if it will have any facts not present in the book you mentioned,
so you might want to scan the book before purchasing it.

/jws

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Oct 1992 15:45:12 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Print under TCP/IP

If I understand you correctly, you want a network printer to accept jobs
from a unix box.  Netware 3.11 workstations will be connected to the
unix box, and all their printing to the network printer will be through
the unix box.

The IIISi has a network card that allows this as long as the unix box is
a SunOS Sparc station or an HP-UX box.  The card is the C2059T, and
costs $895.00 in the US.  You'll also need the appropriate media, and
the FAQ I'll append as the next note in this string should show how to
order the card.

Note that the IIISi also has a Novell Netware card.  If the unix box
will be doing very little printing and the Netware workstations a lot,
you may want to get this card instead.  It costs $695 in the US.  I have
no FAQ for it.

- Steve Kao

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Oct 1992 15:48:55 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Print under TCP/IP

People have been asking about the TCP/IP card for LaserJet printers (via
e-mail).  I'll summarize information here.

(US$895.00)  C2059T:  LaserJet IIISi or DesignJet Plotter
(US$895.00)  C2071T:  LJ II, IID, III, or IIID for thin coax
(US$895.00)  C2071S:  LJ II, IID, III, or IIID for twisted-pair

Given one of the above, you must also order one of the following
options.

(US$100.00)  AA0 - 1/4" tape for HP-UX
(US$100.00)  AAH - DAT tape for HP-UX
(US$100.00)  AAV - 1/4" tape for SunOS
(  $0.00  )  1AK - No software tape.

Given the above, you must also order one of the following options.

ABA - English
ABD - German
ABE - Spanish
ABF - French
ABN - Norwegian
ABS - Swedish
ABZ - Italian
ABJ - Japanese (for the C2059T only)

So, if you order a TCP/IP card for the IIISi that's meant to be used on
a SunOS system in Italy, you'd order C2059T-AAV-ABZ.

Note, the tape contains the drivers and filters needed to install a
master spooler on one system.  If you plan on having multiple master
spoolers, I recommend copying the tape to a system in a permanent store
directory.  To install a master spooler, ftp all files in that directory
to the target system in /usr/lib/hpnp, preserving file structure.  Then
following the installation instructions that come with the tape. You can
do this between HP and SunOS systems, too.  (The data on the tape is the
same, regardless of whether it's in Sun or HP tape format.)

Note, if you want to purchase cards for multiple printers, you only need
to order the tape option once.  Suppose in the Italian example above,
you also want to order a TCP/IP card for the DesignJet plotter and 3
TCP/IP cards for a IIID on twisted-pair, with a mix of HP and SunOS
(Sparc) systems.  The order would then be:

Quantity  -  Part Number  -  Option 1  -  Option 2  -  Unit Price - Total Price
   1         C2059T           AAV          ABZ           $995.00     $995.00
   1         C2059T           1AK          ABZ           $895.00     $995.00
   3         C2071S           1AK          ABZ           $895.00    $2685.00

The install tape would be copied onto a SunOS system, and then ftp'ed to
all systems you want to be master spoolers.  You'd follow the
installation structions for installing the master spooler on all desired
systems.  The master spooler can be either HP-UX or SunOS, as long as
the system has ftp access to whatever system you copied the install
tape onto.

If you happen to purchase the JetDirect card without any software, you
may find the card unusable.  You need to purchase the appropriate tape
and format for your systems.  Use the following part numbers when
purchasing the tape without the card.

C2850-13301:  1/4" tape for HP-UX        (option AA0 above)
C2850-13601:  DDS (DAT) tape for HP-UX   (option AAH above)
 5010-9808:   1/4" tape for SunOS        (option AAV above)

- Steve Kao

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Oct 1992 16:57:12 GMT
From:      gorton@tiger1.prime.com (Scott Gorton)
To:        comp.protocols.tcp-ip,comp.sys.sun.wanted
Subject:   Re: Dial-up SLIP for Sun wanted

In article <1992Oct10.175334.474@elvis.sovusa.com>, andr@elvis.sovusa.com (Andrei Arkhipov) writes:
> Hi.
> 
> I'm looking for SLIP implementation for SunOS 4.x with dial-up capability.
> Can anybody help me?
> 
> Andrei.

UnixWorld (I think April '92) had a three or four page article entitled, 
"Giving your Sun the Slip".  In it, they described where to obtain the SLIP
sources and how to build it into your kernal.

Scott Gorton <gorton@s35.prime.com> 

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 1992 17:52:36 GMT
From:      5714krishnan@vms.csd.mu.edu
To:        comp.protocols.tcp-ip
Subject:   SMTP Confusion

I am thinking of implementing SMTP (RFC 821).. 
I have a very basic problem that being, how does a sender
get a reply for
(a) HELO
(b) MAIL FROM: <sender>
I guess, one needs to have a connection established (socket)
before one starts getting back reply codes.
For this connection one needs to know who he/she wants
to mail to, (the address for) which does not come up until
RCPT TO: <user@domain>
I am possibly missing something very evident/obvious somewhere.
I have gone thru the RFC a number of times and the example of
a SMTP session that is given in the RFC just shows reply codes
of the kind
S: HELO
R: 250 OK
Where does the "250 OK" originate from and how does it communicate ?

Can anyone help me out or let me know where to look for help
Replies would be most appreciated

Thanx
Sunderam Krishnan
e-mail: 5714krishnan@vmsd.csd.mu.edu

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 92 18:37:38 GMT
From:      C51413@TRMETU.BITNET
To:        comp.protocols.tcp-ip
Subject:   Where can I get SPARC SLIP 4.1 ...

Is there anybodyout there can help me to find a SLIP implementation
for Sun Sparc (SunOS 4.1.2) workstations. If I am writing to a wrong
news section please forgive me, this seems to be the best place I
have found. Thanks goes all...

Tarkan Sevim

VLSI Design Eng.
TAEAGE METU

     e-mail:c51413@trmetu.bitnet

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 1992 20:03:09 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP Confusion

In article <0096207E.D04131A0@vms.csd.mu.edu> 5714krishnan@vms.csd.mu.edu writes:
>I am thinking of implementing SMTP (RFC 821).. 
>I have a very basic problem that being, how does a sender
>get a reply for
>(a) HELO
>(b) MAIL FROM: <sender>
>I guess, one needs to have a connection established (socket)
>before one starts getting back reply codes.

Yes.  In order to send a message, you connect to port 25 of the destination
system.

>For this connection one needs to know who he/she wants
>to mail to, (the address for) which does not come up until
>RCPT TO: <user@domain>
>I am possibly missing something very evident/obvious somewhere.
>I have gone thru the RFC a number of times and the example of
>a SMTP session that is given in the RFC just shows reply codes
>of the kind
>S: HELO
>R: 250 OK
>Where does the "250 OK" originate from and how does it communicate ?

The assumption is that the sending software "knows" which system it wishes
to communicate with.  Usually the API between the user application and the
mail transfer software provides a way to specify the destination.  In other
systems, the mail transfer software looks in the mail header for the "To",
"Cc", and "Bcc" headers and extracts destinations from there.  You should
also see the Domain Name System RFC's for information about looking up MX
records to find out the appropriate system to deliver mail to for a
particular address.

The RFC's only concern themselves with communication between systems, not
the interfaces between mail software on the sending or receiving systems.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Oct 92 21:44:49 GMT
From:      mohanram@wsl.dec.com (Narayan Mohanram)
To:        comp.protocols.tcp-ip
Subject:   PPP over Sync lines (Any Implementations??)

<line-eater-bait>
Does anybody have PPP implementations over Sync lines. I am looking for
details. The RFC 1134 mainly deals with Async line formats. I am not sure
if this is what needs to be done over sync lines.

I would like to talk to some-body who has implemented this.

narayan


-- 
USnail: 909 W. Olive			***************************************
	Sunnyvale, CA 94086		* Life is a Reach                     *
Phone: 408-738-4165(H)/415-688-1559(W)	* 	Then you jibe		      *
Email: mohanram@pa.dec.com		***************************************

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 92 21:45:09 GMT
From:      cs161fgp@sdcc10.ucsd.edu (Adam Tilghman)
To:        comp.protocols.tcp-ip
Subject:   Can I run SLIP over a telnet session?


  The subject pretty much says it all - can I telnet into a machine
running a SL/IP server?  What if I use an 8-bit-clean rlogin
connection?

    Any info would be appreciated. 

    -- adam

Adam G. Tilghman - atilghma@ucsd.edu - Voice: (619)622-1944 <10pmPST

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 92 00:24:01 GMT
From:      leinwand@CISCO.COM (Allan Leinwand)
To:        comp.protocols.tcp-ip
Subject:   Network Management: A Practical Perspective

>I came across a book recently published by Addison-Wesley:
>"Network Management: A Practical Perscpective" by Leinwand & Fang.
>
>The book is a fairly extensive overview of Network Management including the 5
>OSI areas: Fault, Performance, Configuration, Security, and Account Management
>
>It has good sections regarding SNMP and MIB (this was one of its
>strengths).  It gives the reader just what it says: A PRACTICAL
>approach to managing LANs/WNAs and dicusses several approaches using
>what it calls: "A simple tool; a more complex tool; and an advanced
>tool".

Hello Stephen,

   Thank you for your interest in the book.  The official title is
"Network Management: A Practical Perspective" by Leinwand and Fang,
recently published by Addison-Wesley.  Please feel free on contact me
directly (leinwand@cisco.com) or my co-author Karen (fang@cisco.com)
if you need additional information on the book or network management
issues.

Thanks,

Allan Leinwand
cisco Systems
(415) 688-7653
leinwand@cisco.com

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Oct 1992 00:43:12 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: what does completion of write() really mean?

In article <qnblp1k@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>Never mind that combining the write()'s is the obvious thing to do.
>The X guys say they have good reasons.

Tell the X guys that their reasons, whatever they are, aren't good
enough to justify doubling the number of packets sent and, hence,
doubling the impact their application has on the network
infrastructure.  Blaming the poor performance of this transmission
"technique" on TCP is something like using low octane gas in a race
car, and then blaming the poor performance on the engine.

						don provan
						donp@novell.com

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Oct 1992 01:32:13 GMT
From:      kdenning@portal.hq.videocart.com (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   Re: PPP over Sync lines (Any Implementations??)

In article <1992Oct13.214449.17017@PA.dec.com> mohanram@wsl.dec.com (Narayan Mohanram) writes:
><line-eater-bait>
>Does anybody have PPP implementations over Sync lines. I am looking for
>details. The RFC 1134 mainly deals with Async line formats. I am not sure
>if this is what needs to be done over sync lines.
>
>I would like to talk to some-body who has implemented this.

Both Telebit and CISCO have this available, and they interoperate fine.

--
Karl Denninger 		Inet:  kdenning@hq.videocart.com
VideOcart Inc.		Voice: (312) 987-5022


-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Oct 1992 02:22:38 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: what does completion of write() really mean?

In article <1992Oct14.004312.22804@novell.com>, donp@novell.com (don provan) writes:
> In article <qnblp1k@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> >Never mind that combining the write()'s is the obvious thing to do.
> >The X guys say they have good reasons.
> 
> Tell the X guys that their reasons, whatever they are, aren't good
> enough to justify doubling the number of packets sent and, hence,
> doubling the impact their application has on the network
> infrastructure.  Blaming the poor performance of this transmission
> "technique" on TCP is something like using low octane gas in a race
> car, and then blaming the poor performance on the engine.
> 
> 						don provan
> 						donp@novell.com


No, you tell the X guys.
They are too many thousand of them for a coward like me.
Telling the X guys how badly they understand TCP/IP is as profitless
as pointing out the glaring network related holes and mistakes in that
netware stuff.

(I was talking about X, the window system, protocol, whatever.
  (They make some picayune distinctions among window manager, window
   system, and other stuff that if you get wrong, they won't talk to you.))


Vernon Schryver,  vjs@sgi.com

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Oct 1992 04:33:26 GMT
From:      wcs@anchor.ho.att.com (Bill Stewart +1-908-949-0705)
To:        comp.protocols.tcp-ip
Subject:   Re: Password capture on anonymous FTP?

How to find who's ftping your stuff?
In article <717817072snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
   Technological fix: insist on an email address as a password.
   You might do something like insist on a valid and/or valid-looking
   address.  The wustl FTP server checks for valid-looking addresses.

But *please* don't.  uunet does this.  The ftp-across-firewall code we
use limits passwords to 8 characters (unless the new version fixes it),
so I can't put my real email address there, just a bogus string that
has the right syntax like me@x.com .  So my .netrc has to have a
special case for talking to them that uses that instead of wcs@att,
since I'm not going to type in anonymous by hand :-)

If you want a technological fix, keep track of their IP address.

   Sociological fix: Ask them for a valid email address.
Much nicer!
--
				Pray for peace;      Bill
#Bill Stewart 908-949-0705 wcs@anchor.ho.att.com AT&T Bell Labs 4M312 Holmdel NJ
# Trickle-Down Economics: Giving money to government bureaucrats 
#	and hoping some will trickle down to the people who need help.

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Oct 1992 05:20:27 GMT
From:      wcs@anchor.ho.att.com (Bill Stewart +1-908-949-0705)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet server that runs on a PC?

   > I am looking for a telnet server that will run on a PC and that is 
   > capable of running Dos applications simultaneously.  If you have 
   TCP/IP for OS/2 has this function

DESQview/X can also do this, letting you run DOS apps remotely from an
X Window, if you have it set up right.
--
				Pray for peace;      Bill
#Bill Stewart 908-949-0705 wcs@anchor.ho.att.com AT&T Bell Labs 4M312 Holmdel NJ
# Trickle-Down Economics: Giving money to government bureaucrats 
#	and hoping some will trickle down to the people who need help.

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 92 05:57:29 GMT
From:      westes@sti.com (Will Estes)
To:        comp.protocols.tcp-ip
Subject:   Ping Reports: 31% Packet Loss...Possible Causes?

I need help in determining possible causes for a network performance
problem.

Here I am by myself on a MS-Windows machine trying to use x-server
software to connect to a UNIX host.  I am alone on an ethernet segment 
that goes through a single router to the second ethernet segment that
attaches to the UNIX host.  Out of nowhere, performance on the network
goes to hell (again, no one is in our office now except for me).

I went to the UNIX host and issued a ping -s command against a few hosts
on the second ethernet segment, and the throughput is great and packet
loss is 0%.  I then did a ping -s back to my host and the results mirror
what I'm experiencing.  Throughput will be great for about four tries, and
then it is poor for one, good for four, poor for one, etc.  Packet loss
is 31%.  

I think something is happening that is localized to my segment.  What
are some possible causes for the symptoms I am describing?  I do not
have a UNIX box on my ethernet, so I can't run etherfind, traffic, etc.

-- 
Will Estes		Internet: westes@netcom.com

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Oct 1992 06:17:28 GMT
From:      ken@cujo.curtin.edu.au (Ken Taylor)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP Confusion

5714krishnan@vms.csd.mu.edu wrote:
: I am thinking of implementing SMTP (RFC 821).. 
: I have a very basic problem that being, how does a sender
: get a reply for
: (a) HELO
: (b) MAIL FROM: <sender>
: I guess, one needs to have a connection established (socket)
: before one starts getting back reply codes.

Yes.. The most common form of this transport is to open a TCP connection
with port 25 of a local SMTP host...
(See appendix A of the RFC)

Usually, when you open the connection, the host will respond with a "welcome"
message, you then say "HELO your.machine.name"..

The host will then say "250..followed by something else irrelevant"

: For this connection one needs to know who he/she wants
: to mail to, (the address for) which does not come up until
: RCPT TO: <user@domain>

Why?

You should be able to send the mail to just about any SMTP host and it will
then take care of the forwarding of the message to the correct final
destination...

: I am possibly missing something very evident/obvious somewhere.
: I have gone thru the RFC a number of times and the example of
: a SMTP session that is given in the RFC just shows reply codes
: of the kind
: S: HELO
: R: 250 OK
: Where does the "250 OK" originate from and how does it communicate ?
: 
: Can anyone help me out or let me know where to look for help
: Replies would be most appreciated

Feel free to mail me if you need advice..  I have written a SMTP mailer
for the Macintosh and hence, been there before..

Ken
-- 
 Ken Taylor              |  "I have a friend who's seen inside my tiny brain
 ken@cujo.curtin.edu.au  |   He's seen the aging and the mildew from the rain
 Curtin University       |   And he does what he can to keep on top of every
 Perth, W. Australia     |     one of them"     - Happy Rhodes

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Oct 1992 09:29:45 GMT
From:      danh@hpgnarpo.grenoble.hp.com (Dan Herington)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Management: References??

Hi Stephen,

Perhaps you haven't heard, but HP makes one of the most popular Network
Management products available on the market - the HP OpenView Network
Node Manager. It should be convenient for you to get all the information
you want about it because it was developed in Fort Collins.  Why don't
you drop into building 1L and ask someone for more information.

As far as references, the most popular one that I have seen for SNMP is
"The Simple Book" - It should be available at any techie bookstore.

Regards,
Dan
---------------------------------------------------------------------------
                               Dan Herington
                     HP OpenView Technical Consulting

HP European Network Marketing Center             danh@hpgnd.grenoble.hp.com
5, avenue Raymond Chanas (No. 28) - EYBENS          Dan HERINGTON/HP6330/M1
38053 Grenoble CEDEX 9, France                             (33) 76.62.53.74
---------------------------------------------------------------------------

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 92 10:09:14 GMT
From:      martin@parst1.paradigm.CO.ZA (Martin Walker)
To:        comp.mail.misc,comp.sys.novell,comp.protocols.tcp-ip
Subject:   Summary: MHS-SMTP gateway

A couple of weeks ago, I wrote :
>Hi all,
>
>As the subject line says, I am looking for a public domain MHS to SMTP
>gateway that will allow me to shove mail around transparently between
>an MHS based mail system and our Unix machines, which are all using SMTP 
>as a transport.
>
>Please mail replies to me and I will summarise shortly....
>
>Thanks in advance for any help,
>Martin.

OK, well here's the promised summary. For the sake of brevity, I have hacked
what people said down quite a bit, and also added some comments of my own
(in brackets [] ). Apologies for taking so long to produce this.

---
From jdickins@novell.com Mon Sep 21 16:38:32 1992

I think most people who require PD software use the Charon gateway.
I am not familiar with this product myself, but it may require
Pegasus mail as the MHS email application.

[As I understand it, Charon works directly with the information specifically
on a Novell server, so it couldn't be used as a general purpose MHS-SMTP
gateway (eg. CC:mail with MHS support). Someone please correct me if I'm
wrong here.]

If shareware would be acceptable, there is UGATE, which is an MHS<->
UUCP gateway.  It is available from The Hunger Project, fax 212-532-9785.
Suggested price US$200.

There is also a commercially available (ie, you have to pay money) 
MHS<->SMTP gateway (yes, I know you said you aren't interested, but
I like to make complete lists) called S-Bridge, made by Computer Mail
Services, voice 313-352-6700.
---
From alan@alans.scf.lmsc.lockheed.com Mon Sep 21 18:49:45 1992

	Here's part of the doc from XGATE40.ZIP, a shareware version.
	I do not know if the newer charon 4.0 is supported.
	US$199 is requested. I included part of the 'registration'
	form at the end.


				alan

                                       XGATE
                   A high-powered inexpensive SMTP to MHS gateway
                                                     XGATE - SMTP/MHS Gateway
       ----------------------------------------------------------------------
       Introduction
       XGATE is a highly reliable, stable, and intuitive SMTP to MHS gateway.
       It bridges  the broad  worlds of  MHS  and  SMTP  using  a  simplistic
       addressing scheme  that  requires  no  routing,  aliasing,  user  name
       tables,  or   anything  else   that  would   be  considered   periodic
       maintenance.
 
[...]
                                    Dave Frailey
                                 DAC Micro Systems

[Most of this deleted. It _does_ sound like it should do the job, but works
with Charon and Novell, so again would not, I think, solve everyone's 
MHS-SMTP gateway needs : It seems that although it will route MHS and
SMTP mail not directly related to any of the users on the Novell, it uses
the Novell file server as an intermediary, so you would at least need
such a server somewhere on your network. Basically, XGATE runs on one PC,
and Charon (with a driver to fool it into allowing addressing of users
not actually in the Novell bindery) runs on another. These two then pass
files to each other via the file server. Perhaps someone could correct
me if I have this wrong...?

BTW, if anyone wants a copy of the full text of the description, e-mail and 
I'll forward what I have.]

---
From: kent@humu.nosc.mil
I know of one commercial product called "S-Bridge" that costs $2500.

---
From: Leo Smith

I just wrote one. Yesterday was the first time it got up and worked.

It links into the mmdf subsystem of a SCO unix, and dumps messages
in, and collects them from, in and out directories more or less in
SMF format.

I am using it to link CCmail running on PC's NFS'ed to the SCO as a
server, with our UUCP connection to the internet!

e-mail me as [...zapped...] for more details.

[Now this would be very neat for my purposes! BTW, I have deleted the 
gentleman's e-mail address, since he may not appreciate being innundated
with e-mail about this. If he actually _wants_ that dubious pleasure, I'll
leave it up to him to release his address. I'll also mail him and ask if it's
OK to forward it to anyone asking me for it...]

---
From cwong@cs.cornell.edu Fri Sep 18 15:13:24 1992

I doubt if you need to summarize replies to your question: it is certainly
an FAQ. Many on the net will give the same reply: Charon 4.0. The 
freeware combination of Pegasus Mail and Charon is legendary in 
Novell netland. Unfortunately, I am not sure if Charon actually 
translates MHS-SMTP or just Pegasus-SMTP. Best to load and find out for
yourself. I get my copies from info.umd.edu, which you can telnet. Of 
course, commercial SMTP gateways are freely available. Da Vinci, for
example. 

[Well, see my earlier comments... I will add, however, that indeed, the
Charon, Pegasus combination _is_ very widely used if what you need is
specifically Novell-SMTP mail integration.]

---
From servio!slc.com!chrisp@m2xenix.psg.com Fri Sep 18 09:38:52 1992

About a year and a half ago, I satisfied myself that such a thing
did not exist.

[OK, it does seem to now...] 

I had a go at writing something myself, but soon
realised that I couldn't easily come up with an elegant solution;
the addressing systems across the two domains are fundamentally
different, even though they look similar...

[I can't really comment on how elegant any of the solutions outlined above
actually are, since I still have to try them out. Perhaps someone else
would care to comment on this...?]

---
From rkh@d1.att.com Fri Sep 18 06:55:01 1992

[Another suggestion to use the Charon-Pegasus combination. Thanks.]

---
From arrent!angel@uu.psi.com Thu Oct  1 12:56:52 1992

[XGATE again... ]

---
From @wpdis02.hq.aflc.af.mil:WHITEHS.AFMC@WPGATE1.HQ.AFLC.AF.MIL Tue Sep 29 07:40:58 1992

This is the number that we use in order to get hold Computer Mail 
Services, which has an SMTP-MHS gateway available commercially:  
313-352-6700

Another product that you might be interested in is XGATE1.  XGATE1 runs in 
conjunction with the freeware application CHARON and is shareware.  You 
can probably get more info concerning this product by calling Compuserve.  
There is a timed demo of the product in the NOVLIB area.

---
From aim1!cstat!steve@olsa99.olive.co.za Fri Sep 25 10:34:03 1992

I believe I have just the thing.  It is known as XGATE.  Oh, perhaps not
perfect: it's shareware.

---

OK, well that's the lot. The gist of it is that if you are specifically looking
at connectiing Novell with SMTP (and hence the rest of the world), go for
the Pegasus mail, Charon combination. If you need a more generic solution,
and have a Novell fileserver handy, use XGATE and Charon. If you don't have
a Novell fileserver, good luck.... :-)

Hope this is of use to someone,
Mart.
-- 
Martin Walker               |  "One way to stop a runaway horse
Paradigm Systems Technology |   is to bet on him"
Pretoria, South Africa      | UUCP : martin@parst1.UUCP  
++27-12-344-3973            | DNS  : martin@paradigm.CO.ZA

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Oct 92 13:35:33 GMT
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: Ping Reports: 31% Packet Loss...Possible Causes?

In article <Bw3KJu.6F8@sti.com> westes@sti.com (Will Estes) writes:
>I need help in determining possible causes for a network performance
>problem.
>
>Here I am by myself on a MS-Windows machine trying to use x-server
>software to connect to a UNIX host.  I am alone on an ethernet segment 
>that goes through a single router to the second ethernet segment that
>attaches to the UNIX host.  Out of nowhere, performance on the network
>goes to hell (again, no one is in our office now except for me).

Sounds like a packet storm.  Check to make sure your router understands
SQE.  If not, make sure all ethernet devices have SQE (a.k.a "heartbeat")
disabled.

--Dave
-- 
System Administrator, Population Research Institute    barr@pop.psu.edu

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Oct 1992 18:11:12 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: PPP over Sync lines (Any Implementations??)

In article <1992Oct13.214449.17017@PA.dec.com> mohanram@wsl.dec.com (Narayan Mohanram) writes:
   Does anybody have PPP implementations over Sync lines.  I am looking
   for details.  The RFC 1134 mainly deals with Async line formats.  I
   am not sure if this is what needs to be done over sync lines.

RFC-1134 is quite ancient and should be mostly disregarded, except
when wondering why a new implementation might not get all the options
it wants when talking to something older.  The current PPP spec,
RFC-1331, talks quite a bit about synchronous line issues.  Write to
ietf-ppp@ucdavis.edu with any specific questions.

   I would like to talk to some-body who has implemented this.

Most router vendors can run PPP over synchronous lines.  Both UNIX PPP
vendors of my acquaintance (Brixton Systems and Morning Star
Technologies) can too, using appropriate add-on hardware as necessary.
I don't know of any freely-available UNIX PPP that talks over
synchronous lines.  I don't know of any DOS implementation that talks
synchronous PPP, and I don't know of any Mac PPP at all.

If you'd like to talk to some implementors, stop by the PPP
Demonstration Center (booth 5384) at Interop in San Francisco, October
26-30.

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Oct 1992 18:31:05 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP implementation help?

 koziol@void.ncsa.uiuc.edu (Quincey Koziol) writes:
>I've recently been modifying the TCP/IP kernel for NCSA Telnet for the
>PC to be a happier and healthier member of the Internet host community
>and I've come across an interesting problem.  
>...
>	What tends to happen, is that everything will work fine for quite
>a while and then a packet that we've sent out will get dropped (unbeknownest
>to the sending host).  The rest of the buffer will finish being emptied out
>onto the network, then the sending host waits for an ack of the data.
>Because a packet has been dropped, this never comes, and eventually the
>TCP port times out and begins resending the data.  All this works fine,
>but somewhere through the resend of the outgoing data, an ack usually
>comes through for the entire set of data which has been previously sent
>(i.e. the dropped packet plus the entire bufferful which was initially
>sent after the dropped packet).
>	What I'd like to do is have that incoming ack update the information
>in the outgoing port so that the rest of the buffer (which the receiving
>host already has and has ack'ed) is not re-sent.  I'm unwilling,
>however, to introduce a poll for received packets in the middle
>of this tight loop pushing packets onto the net as fast as it can.  I was
>wondering (if anyone has actually understood this so far... :-)
>if anyone has a good algorithm for helping re-sends of TCP data act
>a little more intelligent?
>

The answer is not as obvious because it isn't fully in the RFCs,
or at least it wasn't when I had to figure it out.  And jet lag
is setting in so I almost called Van Jacobson by the name Van Morrison.
I hope this comes out coherently.

Host Requirements (1122) tells us to use Van Jacobson's and Phil Karn's 
algorithms and merely refers you to their respective papers.  Look
up Van's paper and he shows how you ought to chop down your transmit
packet on a retransmit, and that will effectively solve the problem
you mention as well as being more conservative with your network bandwidth.

As for the tight loop, your incoming packet routine should up a counter
and you can quickly check that counter in a loop.  But the above
algorithm dramatically reduces the need to do so anways.

Erick
-- 
----------------------------------------------------------------------------
Erick Engelke				 	            WATTCP Architect
erick@development.uwaterloo.ca     TCP/IP was easy but i still can't work VI

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 92 19:13:45 GMT
From:      ccurtis@acsu.buffalo.edu (Chris Curtis)
To:        comp.protocols.tcp-ip
Subject:   Socket Communication Problem


  I'm attempting to implement socket communication between a server
process (which performs database queries) and a remote client process
which sends queries to the server.  I've encountered a problem with
respect to sending certain data structures via the write() command.
It appears that the size of the data structure is exceeding the size
of the buffer used in the associated read() command.  The symptom
is that occasionally the pipe will be broken by the server process. 

  Has anyone had similar problems?  If so, is there any way to increase
the buffer size used in socket communication?  I've found that I can
get the communication to work as long as I "break apart" the data
structure into smaller pieces, and insert sync points during the
send.  This slows down the communication process substantially, and
I was hoping to do better.

  Please e-mail me directly if you can shed any light on a solution
to my dilemma.


Thanks in advance,

Chris Curtis (ccurtis@cs.buffalo.edu)

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Oct 1992 19:14:33 GMT
From:      ckd@eff.org (Christopher Davis)
To:        comp.protocols.tcp-ip
Subject:   Re: Password capture on anonymous FTP?

Bill> == Bill Stewart 1-908-949-0705 <wcs@anchor.ho.att.com> 

 Bill> But *please* don't.  uunet does this.  The ftp-across-firewall
 Bill> code we use limits passwords to 8 characters (unless the new
 Bill> version fixes it), so I can't put my real email address there,

Sure you can.  wcs@.  I've seen the code UUNET uses.  And most other
places accept that too...
--
Christopher K. Davis      |       NET.INSIGHTS INTO ARTISTIC CRITICISM:
<ckd@eff.org>   EFF #14   | ``[Y]ou don't cure bad art by locking it all up
System Administrator, EFF | in one museum, you cure it by throwing tomatoes
+1 617 864 0665  [CKD1]   | at bad artists.'' --Barry Shein <bzs@world.std.com>

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Oct 1992 19:31:51 GMT
From:      rick@seminole.b30.ingr.com (Rick Hopkins)
To:        comp.protocols.tcp-ip
Subject:   Telnet and telnetrc


Is there any public domain software that supports a telnetrc file?  We are
thinking about making the needed change to our telnet code but would like 
to poll the experts first.

Thanks,
rick hopkins
rick@seminole.b11.ingr.com

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Oct 1992 19:46:46 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: what does completion of write() really mean?

 donp@novell.com (don provan) writes:
> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>>Never mind that combining the write()'s is the obvious thing to do.
>>The X guys say they have good reasons.
>
>Tell the X guys that their reasons, whatever they are, aren't good
>enough to justify doubling the number of packets sent and, hence,
>doubling the impact their application has on the network
>infrastructure.  Blaming the poor performance of this transmission
>"technique" on TCP is something like using low octane gas in a race
>car, and then blaming the poor performance on the engine.
>

The problem is due to the use of a reliable protocol (tcp) to
send real-time, unimportant data, particularly mouse updates.
UDP would have been a better network choice, but would have
severely changed the transport independant design of X.
Had udp been used for mouse i/o, the rest of the X data could 
be sent comfortably over Nagled tcp and we would all breath 
easier.  But would you want to start recoding X?  Yuck!

Erick
-- 
----------------------------------------------------------------------------
Erick Engelke				 	            WATTCP Architect
erick@development.uwaterloo.ca     TCP/IP was easy but i still can't work VI

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 92 21:34:07 GMT
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: Ping Reports: 31% Packet Loss...Possible Causes?

In article <1992Oct14.075613.1@ptavv.llnl.gov> oberman@ptavv.llnl.gov writes:
>In article <-071H6tx4a@atlantis.psu.edu>, barr@pop.psu.edu (David Barr) writes:
>Not again! It seems that SQE is about the top area of total confusion in LANs.
>This advice is simply WRONG! If in doubt, get a book on the subject. But PLEASE
>don't post this sort of advice!

How about "Keeping the Link" by Martin Nemzow?

>SQE is a signal passed between the transceiver and the host. It does not send
>out any signal on the backbone media.

p 55. "When the network is not busy, and idle signal is transmitted by all
source/destination nodes, which is the 0.7-volt carrier sense.  This base
voltage is sometimes called the 'heartbeat.'"

Hm.   This sure sounds like a signal to me.

>802.3 mandates SQE for all terminal
>devices. That means anything EXCEPT a repeater.

Yep.  It is for exactly this reason that I've had to turn off SQE
on my one network.  It seems the repeater (a CISCO AGS) that I get doesn't
handle SQE, and if I have it enabled on my machines, the network quickly
grinds to a halt as the repeater dumps collision notices onto the wire.

>SQE exists because there is no
>other way for a system to know that its collision detection circuitry has
>failed. And the failure of this circuitry can result in major network failure.

Fine.  There are also cases when leaving it on results in major network
failure.  Solution?  If it hurts, don't do it.

>There is a good sized article on SQE in the biglan FAQ which was recently
>posted to comp.dcom.lans.ethernet. (OK. I'm a bit biased because I wrote it.)
>
>There are any number of things which might produce the symptoms reported.

Of course.  We all know that.  I just suggested one plausable thing to
check.  If it turns out not to be an incompatable ethernet device, then
you look for other problems.  No harm in checking.

--Dave
-- 
System Administrator, Population Research Institute    barr@pop.psu.edu

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 1992 09:14:33 -0700
From:      jamin@caldera.usc.edu (Sugih Jamin)
To:        comp.protocols.tcp-ip
Subject:   Bug fix for tcplib, a library of TCP traffic model

Hello,

This is a bug fix message for tcplib, a library of TCP traffic models.
We apologize for any inconvenience that this message may cause you.

Vern Paxson of LBL noticed that "there's a rather huge spike in the UCB 
ftp-data connections [of the trace data used in tcplib].  During that 
particular day [when the traces was collected,] there were 2312 
connections of 74 bytes each between the same two UCB and remote hosts.  
[Ninety five percent] of these connections came between 30 and 45 seconds
apart.  None of the other datasets showed this sort of traffic so it
clearly appears to be anomalous."

Fortunately for us...the anomaly did not show up in either our SIGCOMM or 
Journal of Internetworking papers because of the way we grouped multiple 
ftp-data connections into one conversation.

We have taken out the anomalous data from the two data files:
  ftp.nitems
  ftp.itemsize.
Both are available on jerico.usc.edu (128.125.11.6) for anonymous ftp,
in the directory pub/jamin/tcplib.  These files are meant to replace 
their namesakes in the tcplib/data.  To update your libtcp.a, remember 
to do a make in your tcplib directory after you replaced the two files.

Alternatively, you can get the new library or the whole set of sources 
from jerico.usc.edu:pub/jamin/tcplib as described below.  The papers 
[Caceres91] and [Danzig92] cited in the tech report are also available
for anonymous ftp from jerico.usc.edu:~ftp/pub/jamin/traffic. The file
traffic.ps.Z is for [Caceres91] and the files journal.part[1-4].ps.Z 
are for [Danzig92].
=======================================================================
The following technical report and the source library it describes are
available for anonymous ftp from jerico.usc.edu:~ftp/pub/jamin/tcplib.
(Jerico's IP address is 128.125.51.6.) The directory contains the 
following files:

  README
  libtcp_ds31_ultrix41.a.Z
  libtcp_hp90_hpux847.a.Z   /* not supported anymore because we 
                               lost access to our hp machine. */
  libtcp_sun3_sunos411.a.Z
  libtcp_sun4_sunos411.a.Z
  brkdn_dist.h
  tcpapps.h
  tcplib.1
  tcplib.tar.Z
  tcplibtr.ps.Z

All you need to transfer to use the library are: README, brkdn_dist.h, 
tcpapps.h, tcplib.1, and one of libtcp* that matches your setup.  You
need tcplib.tar.Z only if you must generate the library yourself.  
The file tcplibtr.ps.Z is the PostScript version of the tech. report 
which is introduced below:


    tcplib: A Library of TCP Internetwork Traffic Characteristics

                 Peter B. Danzig       Sugih Jamin

                    Computer Science Department, 
                 University of Southern California,
                 Los Angeles, California 90089-0781

                     traffic@excalibur.usc.edu

                            USC-CS-91-495

1. Introduction
  When simulating computer networks, it is necessary to specify the 
traffic between network nodes.  Typically, simulation studies of 
wide-area tcp/ip networks model traffic as a combination of Poisson 
processes and maximal rate streams--corresponding to telnet traffic 
and large file transfers respectively.  Such traffic models are 
justified when the modeler wants to show, for example, that his flow 
control or gateway scheduling algorithm responds well to worst case 
traffic or when essentially nothing is known about the real network
traffic.  However, such models do not reveal how similarly robust 
algorithms respond to the common case load.
  This paper describes tcplib, a library to help generate realistic 
tcp/ip network traffic.  Tcplib is motivated by our observation that 
present-day wide-area tcp/ip traffic cannot be accurately modeled with 
simple analytical expressions, but instead requires a combination of 
detailed knowledge of the end-user applications responsible for the 
traffic and certain measured probability distributions [Caceres91].  
We collected three-day traces of wide-area Internet traffic at UC 
Berkeley, University of Southern California, and Bell Communications 
Research.  Our study identified that out of more than 35 different 
application programs, ftp, smtp, nntp, vmnet, telnet, and rlogin are
responsible for 96% of wide-area tcp/ip bytes.  Two related studies, 
one at University College London and the other at Lawrence Berkeley 
Laboratory, identified a subset of these six applications as 
responsible for most of their wide-area tcp traffic [Crowcroft91] 
[Paxson91]. Tcplib models five of these six applications.  It excluded 
vmnet, an IBM mail exchange application , because it was absent from 
three of the five traces.  Furthermore, since telnet and rlogin have 
essentially the same characteristics, we have included in tcplib only 
routines describing telnetUs.  Additionally, we included characteristics 
of phone conversations based on the study reported in [Brady65] and a 
distribution of conversations composition breakdown derived from several 
stub-network traces.
-- 
sugih                                              Use email, save a tree.

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Oct 1992 22:45:32 GMT
From:      xxronr@convx1.lerc.nasa.gov (Ron Rivett)
To:        comp.protocols.tcp-ip
Subject:   lpr/lpd protocol standard ?



I obtained a copy of "rfc1179.txt" on the lpr protocol from "nic.ddn.mil". 
That document refered to the "IAB Official protocol Standards" for the
lpr/lpd protocol. Can anyone tell me how I can obtain a copy of that specific
standard (e.g. an anonymous ftp site, or a name, address, and phone number of 
someone to contact) ?

Thank you


================================================================================
Ronald R. Rivett                            voice: (216) 433-8281
Sverdrup Technology                 
NASA Lewis Research Center          NASA LeRC FAX: (216) 433-8000 
21000 Brook Park Road                      E-mail: xxronr@convx1.lerc.nasa.gov
Cleveland, Ohio 44135 
Mail Stop 142-2               
================================================================================



-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 92 23:32:17 GMT
From:      johnb@hpubvwa.nsr.hp.com (John Blommers)
To:        comp.protocols.tcp-ip
Subject:   Re: IPX tunneling via rfc1234

Note that IPX tunneling is supported in Netware 3.11

Don't roll your own - use the product !

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Oct 1992 00:07:31 GMT
From:      weber@world.std.com (Bob Weber)
To:        comp.protocols.tcp-ip
Subject:   Netbios Encapsulation

i believe there is one or more RFCs dealing with Netbios 
encapuslation within TCP packets.
can someone please tell me which they are?

does anyone have any experience with netbios 
encapuslation across an enterprise (WAN) internet? if
so, what are the problems, if any.  How does 
encapsulation affect problem resolution, if at all.
thanks.   
Bob Weber
 

-- 
------------------------------------------------------------------------
Robert Weber                       Voice: 617/570-0791 
Northeast Consulting Resources     Fax:   617/523-0150 
85 Devonshire Street, 4th floor   

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Oct 1992 01:54:22 GMT
From:      pwb@newt.phys.unsw.edu.au (Paul W. Brooks esq.)
To:        comp.protocols.tcp-ip
Subject:   RARP opcode 5 - what is it?

I have started seeing periodic RARP broadcasts with an opcode
of 5 - standard RARP uses opcode 3 for the request and 4 for the reply.
Can anybody enlighten me what these opcode 5 messages are for?

Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |If you have trouble sleeping, try lying on the end of
Kensington NSW 2033|   your bed. With a little luck you'll drop off. 
AUSTRALIA          |                              - Mark Twain. 

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 92 11:47:58 PST
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: Ping Reports: 31% Packet Loss...Possible Causes?

In article <m291Hg915a@atlantis.psu.edu>, barr@pop.psu.edu (David Barr) writes:
> In article <1992Oct14.075613.1@ptavv.llnl.gov> oberman@ptavv.llnl.gov writes:
>>In article <-071H6tx4a@atlantis.psu.edu>, barr@pop.psu.edu (David Barr) writes:
>>Not again! It seems that SQE is about the top area of total confusion in LANs.
>>This advice is simply WRONG! If in doubt, get a book on the subject. But PLEASE
>>don't post this sort of advice!
> 
> How about "Keeping the Link" by Martin Nemzow?
> 
>>SQE is a signal passed between the transceiver and the host. It does not send
>>out any signal on the backbone media.
> 
> p 55. "When the network is not busy, and idle signal is transmitted by all
> source/destination nodes, which is the 0.7-volt carrier sense.  This base
> voltage is sometimes called the 'heartbeat.'"
> 
> Hm.   This sure sounds like a signal to me.
> 

Boy, is this ever garbled! While I've read some silliness about LANs, if this
quotation is accurate, this book sets a new low. Carrier sense has NOTHING to
do with SQE. I retract my recommendation to read a book on the subject.
I guess I'll have to say "read 802.3". But that is VERY tough sledding for
someone who is not really familiar with the principles involved and even then
is pretty tough. The DIX Ethernet V2 spec is far more readable, but is not
quite the same. The single biggest difference between Ethernet V2 and 802.3 is
the replacement of CPT by SQE. Both are often called "heartbeat".

(Side note: Vernon, you are right about my advice to read a book. Guess I need
to find a good, accurate book to recommend.)

Any time a signal on the network generates a DC current which produces a
voltage exceeding 0.7 volt into 25 ohms (28 ma), any MAU attempting to access
the cable will detect carrier and defer transmission. If each idle MAU
generated such a signal, the whole thing would not work. N.B. I believe the .7
volt level is correct, but I have NOT confirmed it. It is at least close.
Someone snarffed my copy of the spec and I'm too lazy to run down to the
library to look it up.

SQE is a pulse generated by the MAU to the host after each write on the
collision line to confirm the operation of the collision detection circuitry.
IT is the only way that a system can tell if the collision detection is
working.

>>802.3 mandates SQE for all terminal
>>devices. That means anything EXCEPT a repeater.
> 
> Yep.  It is for exactly this reason that I've had to turn off SQE
> on my one network.  It seems the repeater (a CISCO AGS) that I get doesn't
> handle SQE, and if I have it enabled on my machines, the network quickly
> grinds to a halt as the repeater dumps collision notices onto the wire.

A cisco AGS is a router, NOT a repeater. And I have previously heard reports
that it did not properly meet specs in this regard. I have queried cisco and
received a reply that they did handle SQE correctly. A later message then said
that they think it does. Since it uses cisco's own Ethernet interface instead
of a chip like the AMD Lance  or a SEEQ, I can't confirm it. I can confirm that
my AGS (7 Ethernets and over 500 local nodes) has no trouble routing with SQE
on. This may be dependent on the microcode on the MEC or MCI card, since that
is where the Ethernet operations are really handled.

>>SQE exists because there is no
>>other way for a system to know that its collision detection circuitry has
>>failed. And the failure of this circuitry can result in major network failure.
> 
> Fine.  There are also cases when leaving it on results in major network
> failure.  Solution?  If it hurts, don't do it.

If leaving it on, when the equipment is not a repeater (or the dread fanout),
causes problems, get the offending equipment fixed! 

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov		(510) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 92 12:57:07 GMT
From:      bholley@dw3f.ess.harris.com (Bryan Holley)
To:        comp.protocols.tcp-ip
Subject:   IPMulticast

I am looking for workstation vendors who have implemented IP Multicast. 
In particular, using RFC 1112. I need company name,
as well as contact person and phone number. Please e-mail responses.
If I get positive responses, will post summary.
--

Bryan Holley, Staff Engineer        Voice: (407) 984-6668
M/S W2/7742, Harris GISD            Fax: (407) 984-6323
PO Box 98000                        email: harris.bholley@ic1d.harris.com
150 S Wickham Rd.
Melbourne, Fl 32902

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 92 14:45:35 GMT
From:      ema@netcom.com (Energy Management Assoc)
To:        comp.protocols.tcp-ip,comp.unix.aix,comp.protocols.ibm
Subject:   Anyone using OpenConnect software?

Is anyone out in net.world using OpenConnect software as a TCP/IP to
SNA gateway?  We are having numerous problems with our setup.
What other products are available?
Any information is greatly appreciated,

James Morse
 

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Oct 1992 16:05:13 GMT
From:      mbg@cbnewsi.cb.att.com (mitchell.b.germansky)
To:        comp.protocols.tcp-ip
Subject:   replacing Sys5 msgop with TLI or Sockets


i have an application using sys5 msg queues and we hit resource
limits wrt total msgs in the system and on a queue.  we want to
explore replacing the msgsnd()/msgrcv() with some
connectionless-oriented implementation where we don't have the
msgop limits.

i am wondering if someone has already developed a library emulating
the msgsnd()/msgrcv() interface over say TLI or Sockets using
datagrams.  we would like a reliable datagram implementation.

we need a heterogenuous implementation: sun and 3b2.

any suggestions or pointers to existing code would be greatly
appreciated.

thx and send email to:

	mitch germansky
	att!suntoss!mbg
	908-805-7841

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 92 19:08:01 GMT
From:      dhuber@autelca.ascom.ch (Daniel Huber)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   Broadcast and 'ether' and 'ieee' on LAN-card enabled...

Hi there,

Well, I just got into a strange behaviour on a 9000/380 here.
(probably this is normal, but then I would appreciate somebody tells
me why this happens?).

The problem is easy to describe. 

Open a dgram, SO_BROADCAST socket and sending a broadcast message to
the LAN. This works perfectly on a UNIX box. Only ONE broadcast comes
out the LAN card...
Now, running the same source on a HP 9000/380 will produce THREE (3)
broadcast packets sent *very* fast (so it can't be a timeout or
whatelse...).
I found out that this was partly caused by the fact that HP's do
enable 'ether' and 'ieee' frames on the LAN-card by default
(`lanconfig lan0 ieee ether` in /etc/netlinkrc). This two drivers,
each do forward the broadcast command comming down from the upper
layers separately.... This would explain TWO broadcast packets, but 
WHY ARE THERE THREE??
After disabling the 'ieee' frame, just one broadcast packet is sent
out, as wished.... (If I'd disable just 'ether' on the other hand, I'm
getting NFS timeout's. I assume that NFS uses 'ether' frames?)

Now my questions:

- What causes the third packet to be sent? 
- If I disable 'ieee' on the LAN-card, will this produce any other
  problems I'm not aware off? (the workstationd does NOT use NS..)
- Why does UDP (NFS) use 'ether' frames and not 'ieee' frames? 
  I thought that 'ether' frames are mostly used for Novel only
  networks? Am I totally wrong??

Thanks for any hint!

Regards

Daniel

(Yes, It's true. I work for HP, but not long enough to have all that
knowledge about that stuff....  :-(


-- 
Daniel J. Huber, AIN1 / Ascom Autelca AG / CH-3073 Guemligen / Switzerland
SMTP: dhuber@autelca.ascom.ch / Voice: +41 31 9996664 / Fax: +41 31 9996751 
X.400: /G=Daniel/S=Huber/OU=Autelca/O=Ascom/P=EUnet/A=Arcom/C=ch/
UNIX is the answer....what was the question?

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 92 19:57:53 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: Ping Reports: 31% Packet Loss...Possible Causes?

Path: ptavv.llnl.gov!oberman
From: oberman@ptavv.llnl.gov
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Ping Reports: 31% Packet Loss...Possible Causes?
Message-ID: <1992Oct15.114758.1@ptavv.llnl.gov>
Date: 15 Oct 92 11:47:58 PST
References: <Bw3KJu.6F8@sti.com> <-071H6tx4a@atlantis.psu.edu> <1992Oct14.075613.1@ptavv.llnl.gov> <m291Hg915a@atlantis.psu.edu>
Lines: 76

In article <m291Hg915a@atlantis.psu.edu>, barr@pop.psu.edu (David Barr) writes:
> In article <1992Oct14.075613.1@ptavv.llnl.gov> oberman@ptavv.llnl.gov writes:
>>In article <-071H6tx4a@atlantis.psu.edu>, barr@pop.psu.edu (David Barr) writes:
>>Not again! It seems that SQE is about the top area of total confusion in LANs.
>>This advice is simply WRONG! If in doubt, get a book on the subject. But PLEASE
>>don't post this sort of advice!
> 
> How about "Keeping the Link" by Martin Nemzow?
> 
>>SQE is a signal passed between the transceiver and the host. It does not send
>>out any signal on the backbone media.
> 
> p 55. "When the network is not busy, and idle signal is transmitted by all
> source/destination nodes, which is the 0.7-volt carrier sense.  This base
> voltage is sometimes called the 'heartbeat.'"
> 
> Hm.   This sure sounds like a signal to me.
> 

Boy, is this ever garbled! While I've read some silliness about LANs, if this
quotation is accurate, this book sets a new low. Carrier sense has NOTHING to
do with SQE. I retract my recommendation to read a book on the subject.
I guess I'll have to say "read 802.3". But that is VERY tough sledding for
someone who is not really familiar with the principles involved and even then
is pretty tough. The DIX Ethernet V2 spec is far more readable, but is not
quite the same. The single biggest difference between Ethernet V2 and 802.3 is
the replacement of CPT by SQE. Both are often called "heartbeat".

(Side note: Vernon, you are right about my advice to read a book. Guess I need
to find a good, accurate book to recommend.)

Any time a signal on the network generates a DC current which produces a
voltage exceeding 0.7 volt into 25 ohms (28 ma), any MAU attempting to access
the cable will detect carrier and defer transmission. If each idle MAU
generated such a signal, the whole thing would not work. N.B. I believe the .7
volt level is correct, but I have NOT confirmed it. It is at least close.
Someone snarffed my copy of the spec and I'm too lazy to run down to the
library to look it up.

SQE is a pulse generated by the MAU to the host after each write on the
collision line to confirm the operation of the collision detection circuitry.
IT is the only way that a system can tell if the collision detection is
working.

>>802.3 mandates SQE for all terminal
>>devices. That means anything EXCEPT a repeater.
> 
> Yep.  It is for exactly this reason that I've had to turn off SQE
> on my one network.  It seems the repeater (a CISCO AGS) that I get doesn't
> handle SQE, and if I have it enabled on my machines, the network quickly
> grinds to a halt as the repeater dumps collision notices onto the wire.

A cisco AGS is a router, NOT a repeater. And I have previously heard reports
that it did not properly meet specs in this regard. I have queried cisco and
received a reply that they did handle SQE correctly. A later message then said
that they think it does. Since it uses cisco's own Ethernet interface instead
of a chip like the AMD Lance  or a SEEQ, I can't confirm it. I can confirm that
my AGS (7 Ethernets and over 500 local nodes) has no trouble routing with SQE
on. This may be dependent on the microcode on the MEC or MCI card, since that
is where the Ethernet operations are really handled.

>>SQE exists because there is no
>>other way for a system to know that its collision detection circuitry has
>>failed. And the failure of this circuitry can result in major network failure.
> 
> Fine.  There are also cases when leaving it on results in major network
> failure.  Solution?  If it hurts, don't do it.

If leaving it on, when the equipment is not a repeater (or the dread fanout),
causes problems, get the offending equipment fixed! 

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov		(510) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 92 22:55:43 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Re: Need map showing how NDIS and ODI fit into OSI model

In article <case.44.719184091@ucs.sdsu.edu> case@ucs.sdsu.edu (Steve Case) writes:
>Subject pretty much says it all.

Well, no, actually it doesn't.

>Even a brief explanation of these two protocols and how 
>they relate to OSI would be good.

NDIS and ODI are interfaces, not protocols.  Like anything developed
outside of the OSI effort, they do not exactly conform to the OSI
model.  NDIS is approximately at the top of OSI layer 1, between the
physical and datalink layers.  ODI is somewhere near the top of layer
2, between the datalink and network layers.
						don provan
						donp@novell.com

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Oct 1992 02:23:24 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: Netbios Encapsulation

In article <Bw4z0K.74M@world.std.com>, weber@world.std.com (Bob Weber) wrote:
>i believe there is one or more RFCs dealing with Netbios 
>encapuslation within TCP packets.
>can someone please tell me which they are?

They are RFC 1001 and 1002.

...Sam
-- 
<skl@wimsey.bc.ca> -- Connectivity Technology Inc.

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Oct 1992 02:35:19 GMT
From:      karl@empirical.com (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: Ping Reports: 31% Packet Loss...Possible Causes?

>> Sounds like a packet storm.  Check to make sure your router understands
>> SQE.  If not, make sure all ethernet devices have SQE (a.k.a "heartbeat")
>> disabled.
>
>Not again! It seems that SQE is about the top area of total confusion in LANs.
>This advice is simply WRONG! If in doubt, get a book on the subject. But PLEASE
>don't post this sort of advice!

When setting up BIG networks, like Interop, we generally recommend that 
folks turn SQE off in Ethernet(tm of Xerox) MAUs.

The reason for this is two fold:

1) If it is turned off, almost nothing notices.

2) If it is turned on and is attached to the upstream port of a multi-port 
device (including a hub/concentrator) it violates IEEE specifcations and 
will cause what appears to be a collision on almost every packet.

			--karl--

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Oct 1992 02:58:20 GMT
From:      westes@sti.com (Will Estes)
To:        comp.protocols.tcp-ip,comp.dcom.lans.misc,comp.dcom.lans.ethernet
Subject:   Good References For Deciphering Output Of An Analyzer?

I have a simple public-domain network analyzer that I set up to help me
determine the source of a network problem.   Unfortunately, this
particular analyzer gives me some pretty crude output.  It basically
spits out the packet type number and then the header of the packet.
There are not any summary statistics.

Does anyone know of a good reference that will give me numbers for the 
different packet types, as well as a breakdown of the packet structure?  
I don't need a PhD thesis in terms of detail...I'm looking for more like 
Cliff Notes on packet analysis (yes, that was a serious remark :).  The
ideal book would spell out the five or six most common kinds of problems
and then spell out what kind of signature that problem leaves on the
network in terms of packets being passed back and forth.  Does 
anyone know of any good documents/books to get?  Anything by ftp?
Our net is running Novell and TCP traffic over ethernet, so those are the 
only cases I need to cover.

Someone had suggested that my problem might be caused by an SQE problem
and some other station on my segment erroneously sending out collision-detection
packets (if that is nonsense, forgive me).  What sort of signature
would this kind of problem have? 

-- 
Will Estes		Internet: westes@netcom.com

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 92 11:40:57 GMT
From:      heading@breeze.rsre.mod.uk (Anthony J.R. Heading)
To:        comp.protocols.tcp-ip
Subject:   Cheap routers: moving on

Thanks for the responses to my query about cheap routing. There
seemed to be a general feeling that none of the cheap-and-cheerful
methods were altogether satisfactory, so maybe buying a router
is the best way of doing things...

It transpires though, here in the sunny old UK, that packet-switched
X.25 connections are expensive. British Telecom seem fond of circuit
switching, and thus the best value comms option seems to be a
"Kilostream" line - which I understand to be a 64K synchronous link
which terminates with an X.21 port.

Does that change anybody's mind? If I wanted to connect that to a
Sun (for example), is it worth using a router to gate X.21 onto
an ethernet and then put an ethernet card in the "firewall" workstation,
or perhaps a SCSI X.21 port...

Any opinions gratefully received - peripheral facts as well. And if
I've completely got the wrong end of the stick I'd like to know
that too...

Anthony

------------------------------------------------------------
Defence Research Agency, St. Andrews Road, Malvern, Worcs, UK.
heading@hermes.mod.uk            Work: +44 684 896066
heading@ccint1.rsre.mod.uk       Home: +44 684 563596
-- 
Anthony Heading  (heading@hermes.mod.uk)
DRA Malvern, UK
Any opinions expressed are my own and in no way
represent those of my employer or any other organization.

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Oct 92 13:44:12 GMT
From:      jona@iscp.bellcore.com (Jon Alperin)
To:        comp.unix.aix,comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Highly available network routing (LONG POST)

Morning (at least it is for me...)

 I have several questions about TCP/IP RIP Routing, involving cisco
routers and IBM's AIX operating system (However, I will try to keep
things general in nature). I would appreciate e-mail replies to 
'jona@iscp.bellcore.com', as I do not normally read all these newsgroups.
I will summarize results for anyone interested.

 I have been involved in building a highly available internetwork to 
support continuous operability between various applications executing
on separate systems. The network itself is a ring topology of T1 links
connecting Cisco routers, and the routers themselves connect to the same
end networks:


           +====R1 ------------ R2==+
      S1 --|       \          /     |- S2
           |        \        /      |  
           +====r4 __\______/_ r5 ==+
                   \  \    / /
                    \   R3  /
                     \  |  /
                      \ | /
                        r6--- s3

The idea is that S1 (System 1) will always have a communication path with
S2, even if a network link or router is lost. R3 and R6 will connect to various
other systems. All S1 and S2 systems are running routed with a -q option.

All networks are given a class B address (e.g. 160.190), but the network mask
is 255.255.255.0 so that sunbetting is enabled. The cisco routers show
160.190.0.0 is subnetted into more than 18 subnets (due to the other systems
and networks which I did not show...). However, on S1 and S2 (both AIX V3.2.2
boxes), a netstat -r shows the following:

Routing tables
Destination      Gateway            Flags  Refcnt Use       Interface

Route Tree for Protocol Family 2:
(root node)
127              localhost          U           3     2799  lo0
160.190          160.190.100.100    UG         19     9886  tr0
[plus a route for the local interfaces...]

instead of each of the 18 routes. The gateway address cooresponds to 
only 1 router (R1 or R2) at any given time, even though I know the hop
count to a system (s3) hanging directly off r6 (and _not_ connected to r3)
should be less coming from r4 than from R1. yet r4 never shows up in the
routing table.

 Is this the expected result? Could it be that AIX is having a problem with
class B addresses and not picking the routes from the RIP updates?

 Also, when we do establish a connection (like a ping) between S1 and S2, 
sometimes we see a UGHD route directly to the host, with netstat reporting the
160.190.subnet.host address, so it obviously is simply truncating to a class
B network.

 The broadcast address on the systems is 160.190.subnet.255, and the
router uses all 1's for its broadcast (which is equivalent, right?).

When we disconnect a router R2, we expect that the S2 systen will pick
up routes from r5 after 90 seconds (30 to recieve a rip update,
30 for stale marked partitions, and 30 for deletion). However, it 
actually appears to take 4 minutes (or longer)
for this to occur. Can anyone account
for this time lag? Could it be because the aix system does not see each of
the subnets individually?

 On a slightly related note, when we disconnected the cisco token ring
interface from one of the lans, it turned the interface off (i.e. down), and
requires manual access to the router to re-initialze via a 'clear interface'
command. Can this be changed to always stay active (wellfleet does stay active, 
and simply logs wire faults...)? And when we reconnected the router (after the 
other router had been established as the network connection), the netstat
reported route switched back to this router (as if it were some sort of
primary router)...why?

 Any help would be greatly appreciated. Once again, please e-mail replies.

 Thanks,

 jon


-- 
Jon Alperin - Bellcore
---> Internet: jona@iscp.bellcore.com
---> Voicenet: (908) 699-8674

* All opinions and stupid questions are my own *

"I don't have any experience running up a 4 trillion dollar debt" - Ross Perot
"If there's a fair way, I'm all ears" - Ross Perot

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Oct 92 13:52:24 GMT
From:      J045820@LMSC5.IS.LMSC.LOCKHEED.COM
To:        comp.protocols.tcp-ip
Subject:   Hardware address translation

Hello , I have a question concerning or resolving may be a better way to
say it of, IP addresses to physical card addresses. I understand that
the physical address should be found during installation, but inevitably
one will be missed, so that brings me to my problem. Using a Sunworkstation
as a management tool, and the related network status commands such as netstat
ping and others is it possible to glean the physical addresses to coincide
with IP addresses. I understand this can be done with a protocol analyser
but I am trying to develope this capability from a central system (Sun).
If anyone has any suggestions I would appreciate the information.
                                      Thanks Bill Smith ,(LMSC)

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Oct 1992 14:42:19 GMT
From:      hughes@sde.mdso.vf.ge.com (Hughes Doug)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   netmasks and ICMP


  We here at GE have a somewhat unusual problem in that we do not have 
homogeneous netmasks through the network, thus, if I want to do a directed
broadcast to a remote LAN, I need to know what the proper netmask is. 
Through reading RFC's I've discovered that the ideal way to do this seems
to be a netmask req.  However, I have not discovered any code detailing
what a netmask req might look like. Has anyone ever done this?  I've checked
the ping code to some extent with limited results (since it doesn't use
netmask req.)	
			Thanks,
Doug Hughes					GE Aerospace
hughes@sde.mdso.vf.ge.com			
"To be intoxicated is to feel sophisticated, but not to be able to say it"

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 92 14:49:05 GMT
From:      garyo@apricot.co.uk (Gary Osborne)
To:        comp.protocols.tcp-ip
Subject:   UPS-MIBs for SNMP

I have read somewhere that some US UPS vendors are working with an
Internet Engineering task force to define some MIBs for SNMP.
Does anyone have any info on this or a contact name on the task force?

In hope ...

Gary Osborne.

---------------------------------------------------------------------------
Internet: garyo@apricot.co.uk                 | Apricot Computers Limited
UUCP:     garyo@apricot.uucp                  | Research and Development 
Tel: +44 21 472 3002  Fax: +44 21 471 2935    | 90, Vincent Drive
                                              | Edgbaston
If all else fails from US, try:               | Birmingham.  B15 2SP
          apricot!garyo@relay.EU.net          | United Kingdom
---------------------------------------------------------------------------

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 92 15:09:40 GMT
From:      heading@breeze.rsre.mod.uk (Anthony J.R. Heading)
To:        comp.protocols.tcp-ip
Subject:   Re: Cheap routers: moving on

A clarification. Apparently the US doesn't use X.21, but RS449
instead. So if I were to get a converter, the question becomes how
to connect RS449 to a Sun.

Something which did packet filtering would be nice.

Anthony
------------------------------------------------------------
Defence Research Agency, St. Andrews Road, Malvern, Worcs, UK.
heading@hermes.mod.uk            Work: +44 684 896066
heading@ccint1.rsre.mod.uk       Home: +44 684 563596

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Oct 92 15:50:21 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone using OpenConnect software?

In article <1992Oct15.144535.20393@netcom.com>, ema@netcom.com (Energy Management Assoc) writes:
|> Is anyone out in net.world using OpenConnect software as a TCP/IP to
|> SNA gateway?  We are having numerous problems with our setup.
|> What other products are available?
|> Any information is greatly appreciated,
|> 
|> James Morse
|>  
You probably should have Open Connect come and give you a hand.  This is
a good gateway product but their documentation is terrible.  We've had
this discussion (about the documentation) and even THEY say its
terrible.  One of the support engineers basically said that with the
current documentation, he didn't particularly consider the product user
installable.

Charles.
--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IS&DP Network Services		AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 92 16:15:42 GMT
From:      ric@updike.sri.com (Richard Steinberger)
To:        news.software.nn,news.software.nntp,comp.unix.solaris,comp.windows.x,comp.protocols.tcp-ip
Subject:   Solaris SW list: More program info needed


        I have started maintaining a list of software that currently runs,
or people would like to see run, under SUN's SOLARIS 2.x.  I will
append to this posting the information I have.  I am particularily
interested in hearing if anyone has ported any of the following
programs:

newsreading SW:  nn rn nntp cnews/rnews

communication:   kermit

SW development:  nihcl

network & adm:   perl tcpdump top traceroute

windows:         xarchie xlock xperfmon xntp motif

[If you have ported any of the above, please look at the list below and
send me information similar to what is presented.]

---------------------------------cut---here------------------------------------
Solaris SW list.  Maintained by ric@updike.sri.com.  Ric Steinberger.

Last updated: 10/05/92

Solaris 2.x compatibility information.  Here is an attempt to provide
some information about SW that may run under SUN's Solaris 2.x OS.
For now (9/92), feel free to send additional information regarding other
tools that you would like to see included.  If possible, include details
as to whether that product runs under 2.x [include x].  This list is
now available via anonymous FTP from updike.sri.com.
Please send suggestions to: ric@updike.sri.com.

Please use archie or other database to find out where these tools reside.
Most of the GNU programs are on prep.ai.mit.edu.  Many X11 programs
are on export.lcs.mit.edu.  pit-manager.mit.edu is a source for many
other programs.  So is ftp.uu.net.

I will only list a site if a "customized" 2.x-compatible version or
patches exist there.  [I would prefer not to get in the business of
listing distribution sites, as they tend to be very voluable entities.]

Note: Unless otherwise indicated, "builds" means compiles using SUN-supplied
compilers.  

IMPORTANT: If you have built a tool/utility listed here and you needed to
apply one or more patches, PLEASE contact the code's author so that
he/she may examine you efforts and incorporate them into the next release.
This will help everyone.  "HELP SAVE THE WORLD." - Larry Wall.

CAVEAT: The listing of a program/product below does NOT mean that I have
personally compiled or tested it.  The information in this list is
supplied to me by users like yourself.  I will attempt to keep this
list accurate and reasonably up to date, but I depend on YOU to help me
do this.  If you see something that is incomplete or inaccurate, please
try to obtain correct information and then contact me.


Status Codes:

1 Current distribution builds under Solaris 2.0
2 Current distribution builds with patches.  [See comments]
  [Most people who claimed that they we able to get XXX to build with
   only a "few" patches have generally been optimistic about others
   ability to do the same.  However this is not necessarily the case.]
3 Current distribution doesn't build yet.
4 Partial build. [See comments]
5 Cygnus distribution includes this.  See vendor/cygnus dir on ftp.uu.net.
6 Binary available.  Binaries have been posted to some sites known
  by archie and other databases.  It is clearly more desirable to have
  the source build properly, especially for tools that depend on
  significant selection of options prior to a build.
7 Compiles under 4.x compatibility mode.
8 Current distribution builds under Solaris 2.0 using gcc.

Patch distributors:

P1	davy@ecn.purdue.edu

Comment Codes:

Pn  Patches available.  See patch distributors.
 1  Use gcc (cygnus gcc from ftp.uu.net)


Product              Version             Status          Comment

amd (berkeley)
archie                                    2               P1. Minor BSD/SVRV
                                                          problems
bash                  1.12                1,6               1 
bison
byacc                                     5
cnews/rnews
contool
cvs                   1.3                 1
diff pgms             2.0                 1
dig                   2.0                 2                Minor BSD/SYSV
                                                           problems
dvips                 5.47                8                Define SYSV in
                                                           makefile
eispack
elm                   2.3P11              2
emacs                                     6
epoch                 4.2                 1
fileutils             3.3                 1                 1
flex                                      5
ftptool
gawk
gcc                   2.2.2               5,6
gdb                   4.6                 5
ghostscript           2.5.1               1
ghostview                                 1
gopher
gprof					  5
grep 
INN
jove                  4.14.7              2                 P1
kermit
lapack
less                  177                 8
linpack
log_tcp 
make                  3.62.16+            1
Metafont              2.7                 8
MH                    6.7.2               2                 P1
MicroEmacs            3.11a               8
Mtools
nihcl
nn 
NNTP
patch                 2.0.12.u8           5,8
perl 
pine
ping (post BSD)                           1
POP
rc                   1.4                  1
rcs                                       1
rn
shellutils           1.7                  1                 1
tar                  1.10                 1                 1
tcl
tcpdump
tcsh                                      6
TeX/LaTeX            3.14                 8
textutils            1.3                  1                 1
tgrind
top
traceroute 
WAIS
X11R4
X11R5 p1 17                              2,4                clients & libs
                                                            only. No server.
                                                            P1
-------------------------------------------------------------------------------

Various contributed X11 clients [R4.18 and/or R5.patch_level]

pbmplus
xarchie
xdvi                 patch15              2                 needs bzero and
                                                            bcopy .o files.
xfig                2.1.4                 2                 Minor BSD/SYSV
                                                            problems
xli
xlock
xntp 
xperfmon
xpipeman            X11R5 contrib         2,7
xpostit              3.1                  2
xrn                  6.17                 2
xtetris             X11R5 contrib         2                Minor stuff
xtroff              X11R5 contrib         1
xv                   2.21                 2,7,8
xview                3.0.1
xvnews               2.2                  2

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

SW from SUN that runs under Solaris 2.0:

[Note: It will be *impossible* to make this a complete list.  I will try
 to include the most "popular" software.  ]

??? indicates that someone would like to know if it is available.  Perhaps
someone from SUN could help.

cc
CC (c++)
Developers Guide
fortran
NewsPrint         ???
ShowMe 1.0
Sunlink FDDI
Sunlink X25
SunNet Manager
SUN PC

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

The list of "Other Commercial" is definitely going to be incomplete.  I will
try to include the more popular 3rd party software products.  If a "?"
appears, it means I have no information as to whether this product runs
under Solaris 2.x.  Feel free to contact the vendor and relay any information
back to me.


Other Commercial:              Runs under Solaris 2.x (Y/N/?)

Adobe Transcript      3.1      Need to build from source
AFS					?
Alsys Ada				?
Asterix					?
Aviator					?
BRS-Search				Y
Codeview/Objectview			?
Disspla					?
Empress					?
FrameMaker 3.1A				Y  (minor mods reqd.)
                                        Other reports say No.
FourGen accounting			Y
IDE (Software thru Pictures)            Y
ie (X11 text editor)			Y
IMSL					?
Informix				Y  (SE and RDS)
Ingres					Y
Interleaf 5                             ?
Island WPD				Y
Island Presents				Y
Maple					?
Mathematica 				?
Matlab 					?
Motif 					?
Oracle					Y
ParcPlace Smalltalk			?
PV-WAVE					Y	
QMS/Imagen printer SW			?
RSX					?
Sybase					?
Teamwork				?
Topic					?
Tuxedo					?	
UIM/X					?
WDSF					?
Word Perfect                            N
TMI Parallel Driver			?
Xmath 					?

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

Final notes:

Cygnus offers commercial support for much of the GNU software.
Their phone number is: 415 322 3811.  I am not a Cygnus employee.]


-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 1992 16:58:15 GMT
From:      emv@msen.com (Edward Vielmetti)
To:        comp.unix.aix,comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: Highly available network routing (LONG POST)

RIP converges slowly when the topology changes.  a link-state protocol
like OSPF will do a better job.  I forget whether Cisco has OSPF working
yet, but if they do, you should look into that.

--Ed

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 92 17:02:00 GMT
From:      rob@jdsny.com (Rob Yampolsky)
To:        comp.protocols.tcp-ip
Subject:   Just how bi-directional are sockets?


  Does anyone out there know if sockets (or streams) can be simultaneously
bi-directional?  I am writing a program that acts as a socket multiplexor.
Messages from multiple local sockets are forwarded over a single socket to
a remote server.  A message from one local socket can arrive for forwarding
at the same time as the server's response to a prior message from another
socket.
  Do I need to use separate sockets for reading from and writing to the
server, or will TCP/IP handle a write to the server socket when it has an
incoming message pending?
-- 
================================================================
=     Mail replies appreciated if possible (who has time to    =
=     read this stuff?)               Thanks, rob@jdsny.com    =
================================================================

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 92 17:23:24 GMT
From:      josevela@mtecv2.mty.itesm.mx (Jose A. Vela A.)
To:        comp.dcom.lans,comp.os.msdos.misc,comp.protocols.tcp-ip
Subject:   Re: Clarkson Token-Ring Packet Driver on PcRoute ver 2.4



 yes I used it, and it works perfectly 

 mmm try your token ring card with a TCP program : ping , telnet, 

 and make shure it works ..

 everything must work as exactly as any other packet driver ..

 good luck

 _____________________________________________________________________________
 Jose Angel Vela Avila.
  Instituto Tecnologico y de Estudios Superiores de Monterrey
    I.T.E.S.M    Mexico.
  ___               _    ___  _         __   josevela@mtecv2.mty.itesm.mx
 (   >             ' )  /    //        /  )  
  __/________    _  (  / _  // __.    /--/  
 / /  (_)  \_)__</_  \/ </_</_(_/|_  /  ( o  NetStorm <--- irc Nick 
<_/


-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Oct 92 21:45:06 EDT
From:      reganm@bluemoon.rn.com (Mark T Regan)
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone using OpenConnect software?

ema@netcom.com (Energy Management Assoc) writes:

> Is anyone out in net.world using OpenConnect software as a TCP/IP to
> SNA gateway?  We are having numerous problems with our setup.
> What other products are available?
> Any information is greatly appreciated,
> 
> James Morse
>  

What kind of problems are you having? My company (Nationwide Insurance)
has OCS/FTP Server installed.

Mark T. Regan
Work Email: reganm.regan@ibmx400-us.ibmmail.circe.fr

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 92 18:01:40 GMT
From:      dmiller@dragon.tricity.wsu.edu (David L. Miller)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Print under TCP/IP

In article <2480016@hprnd.rose.hp.com>, k@hprnd.rose.hp.com (Steve Kao) writes:
|> If I understand you correctly, you want a network printer to accept jobs
|> from a unix box.  Netware 3.11 workstations will be connected to the
|> unix box, and all their printing to the network printer will be through
|> the unix box.
|> 
|> The IIISi has a network card that allows this as long as the unix box is
|> a SunOS Sparc station or an HP-UX box.  The card is the C2059T, and
|> costs $895.00 in the US.  You'll also need the appropriate media, and
|> the FAQ I'll append as the next note in this string should show how to
|> order the card.
|> 
The Sun version of the software also works on a DECstation.  The biggest
problem is copying the software...

|> 
|> - Steve Kao
 
-- 
*****************************************************************************
David L. Miller                       Internet: dmiller@beta.tricity.wsu.edu
Systems Programmer/Network Analyst      BITNET: MILLERD@WSUVM1
Washington State University Tri-Cities    UUCP: ...!yoda!dmiller
100 Sprout Road                          
Richland, WA 99352                       Phone: (509)375-9245
*****************************************************************************

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 1992 19:00:00 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Hardware address translation

In article <92290.23844.J045820@LMSC5.IS.LMSC.LOCKHEED.COM> J045820@LMSC5.IS.LMSC.LOCKHEED.COM writes:
>Using a Sunworkstation
>as a management tool, and the related network status commands such as netstat
>ping and others is it possible to glean the physical addresses to coincide
>with IP addresses.

Using a Sun on the same subnet as the host whose physical address you're
trying to determine, do the following:

% ping <ip-address-or-name>
<ip-address-or-name> is alive
% arp <ip-address-or-name>
<ip-address-or-name> (<ip-address>) at <physical-address>
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 92 19:53:33 GMT
From:      bvs@nrc.com (Bill Versteeg)
To:        comp.protocols.tcp-ip
Subject:   rpc process chewing up resources


I have a process somewhere that is continually opening
up SUN RPC connections, and then leaving them
in TIME_WAIT. I want to shut him
down, but I can't figure which process is doing it.
Here is a netstat output

Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp        0      0  127.0.0.1.2544         127.0.0.1.sunrpc       TIME_WAIT
tcp        0      0  127.0.0.1.2543         127.0.0.1.sunrpc       TIME_WAIT
tcp        0      0  127.0.0.1.2542         127.0.0.1.sunrpc       TIME_WAIT
tcp        0      0  127.0.0.1.2541         127.0.0.1.sunrpc       TIME_WAIT
?



I have looked throuh a ps-aex output, and don't see anything
 out of the ordinary. 
ps -aex | grep rpc
    96 ?  IW    0:00 rpc.mountd -n HOME=/ PATH=/bin:/usr/bin:/usr/etc:/usr/ucb
   106 ?  IW    0:00 rpc.bootparamd HOME=/ PATH=/bin:/usr/bin:/usr/etc:/usr/ucb
   109 ?  IW    0:00 rpc.lockd HOME=/ PATH=/bin:/usr/bin:/usr/etc:/usr/ucb
   110 ?  IW    0:00 rpc.statd HOME=/ PATH=/bin:/usr/bin:/usr/etc:/usr/ucb
  6426 p1 S     0:00 grep rpc HOME=/home/bvs SHELL=/bin/csh TERM=sun-cmd USER=bv
  
I am running SUNOS3.x on sparcs and 3/60s.

The number of processes shown by netstat sometimes gets into the hundreds (
this is due to a lack of atomic action in the netstat kernel dives)
Occasionally the system runs out of mbufs when I run netstat because
of all of the rpc tcp connections . This is the real problem

So, the specific question is- What is opening these sessions?
	( I suspect rpc.mountd or rpc.statd)
The general question is- How do I tell what process is associated
	with a particular entry in netstat? (/etc/services does not help here)

	Bill VerSteeg
	bvs@nrc.com
-- 
Bill VerSteeg
VerSteeg CodeWorks
bvs@nrc.com

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 92 21:15:05 GMT
From:      booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
To:        comp.protocols.tcp-ip
Subject:   Why is there no FAQ for this newsgroup?

Has anyone here ever considered putting together an FAQ for this newsgroup?
If any newsgroup needs one, this one does.  I only read this group inter-
mittently, but every time I check on it, I find discussions about KEEPALIVE,
requests for TCP/IP benchmarks, general network programming questions,
questions regarding RFCs, broadcast questions, etc, etc.

What does it take to get an FAQ going?  I'd consider doing it myself (if I
had any time), but it seems to me there are others out there with a great
deal more general knowledge, who are regular readers of this group, who are
likely much more familiar with the types of frequently asked questions,
who might be cajoled into producing (or helping to produce) an FAQ.  

How about it folks?  Anyone out there willing to take a stab at it?

mb
-- 
Mark Boolootian		booloo@llnl.gov		+1 510 423 1948

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Oct 1992 21:44:11 GMT
From:      matt@ra.oc.com (Matthew Lyle)
To:        comp.protocols.tcp-ip,aus.wanted
Subject:   Re: AS400s and Suns together

merce@xenitec.on.ca (Jim Mercer) writes:
>In article elogan@mistxt.oc.com (Ernie Logan) writes:
>>merce@xenitec.on.ca (Jim Mercer) writes:
>>>In article elogan@mistxt.oc.com (Ernie Logan) writes:
>>>>merce@xenitec.on.ca (Jim Mercer) writes:
>>>i have a demo version of the Open Connect TN5250 for MSDOS, which i have not
>>>had a chance to try out yet.  (RSN now, as the boss is getting a little
>>>impatient).
>>>my only bitch about this product (which i have not tried), and others like
>>>it, is that it is only available for specific TCP/IP stacks.
>>
>>Maybe so, but look at at how many stacks it is available for, and after all,
>>don't most netters already have some TCP/IP on their system?
>
>this is exactly my point.  correct me if i'm wrong, it's been a while since
>i've looked at your liturature, but the demo version i have only supports
>the FTP kernel.  you may well have expanded that to cover most of
>the major commercial kernels.

That was probably what the sales type ordered for you.  We support 9 TCP/IP
implementations, one just added recently.  We've supported "most of the 
major commercial kernels" for some time.  It can be arranged, no doubt, for
you to get the kernel support you need.

-- 
Matthew Lyle                                           matt@oc.com
Technical Support Specialist                           matt@utdallas.bitnet
OpenConnect System, Dallas, Texas                      (214) 888-0474

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Oct 1992 22:35:26 GMT
From:      ronf@panther3.panther.mot.com (Ron Feigen)
To:        comp.protocols.tcp-ip
Subject:   closing/re-using TCP sockets


A month or so back some folks posted the solution to enable immediate
reuse of TCP sockets (instead of having to wait for upto 2 minutes).
I thought it was TCP_LINGER, however this does not seem (per the man page)
to be the sockopt I am looking for.  Could somebody please repost the info.

Thanks in advance!


-- 

>
Ron Feigen
ronf@panther.mot.com

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 92 23:34:11 GMT
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: Why is there no FAQ for this newsgroup?

In article <139152@lll-winken.LLNL.GOV> booloo@framsparc.ocf.llnl.gov (Mark Boolootian) writes:
>Has anyone here ever considered putting together an FAQ for this newsgroup?
 Well, the ANSWERS are called RFC's...... >:-)

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 92 01:10:10 GMT
From:      jiliu@silver.ucs.indiana.edu (Jian Liu)
To:        comp.protocols.tcp-ip
Subject:   Re: QvtNET28 released ?

In article <1992Oct13.222135.6692@vlsi.polymtl.ca> fn@junior.mathtok.polymtl.ca (Francois Normant) writes:
>A file called qvtnet28.zip has been uploaded to 
>ftp.cica.indiana.edu:pub/pc/win3/uploads
>but the archive seems to be corrupted.
>
>Is it an official release ? What is the official site for QPC softwares ?
>

But there is another file in the same directory called qvtnetsx.exe, which
self-extracts itself successfully into version 2.8.  I just tested it and
liked the better buttoned interface.

Jian

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Sat, 17 Oct 1992 01:44:28 GMT
From:      tga@oar.net (Germann Associates)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Print under TCP/IP


For those of us who forgot to hit the s key in rn, what tcp port does the 
HP TCP card use?

Eric

eric@tga.com

-- 
============================================================================

Eric Germann                               Quote for the time being:
The Germann Associates                     "Lead, follow, or get out of the 

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 92 02:18:17 GMT
From:      dmiller@dragon.tricity.wsu.edu (David L. Miller)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Print under TCP/IP

The HP JetDirect card uses port 9100.

In article <1992Oct17.014428.10452@oar.net>, tga@oar.net (Germann Associates) writes:
|> 
|> For those of us who forgot to hit the s key in rn, what tcp port does the 
|> HP TCP card use?
|> 
|> Eric
|> 
|> eric@tga.com
|> 
|> -- 
|> ============================================================================
|> 
|> Eric Germann                               Quote for the time being:
|> The Germann Associates                     "Lead, follow, or get out of the 
 
-- 
*****************************************************************************
David L. Miller                       Internet: dmiller@beta.tricity.wsu.edu
Systems Programmer/Network Analyst      BITNET: MILLERD@WSUVM1
Washington State University Tri-Cities    UUCP: ...!yoda!dmiller
100 Sprout Road                          
Richland, WA 99352                       Phone: (509)375-9245
*****************************************************************************

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 92 10:25:26 MST
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.dcom.servers,comp.protocols.tcp-ip
Subject:   How to TCP/IP print to a comm server (Was: Re: Annex 3 and lpd)

(Copying a thread from comp.dcom.servers into comp.protocols.tcpip...)

It has been noted that there is no standard way to implement TCP/IP
printing to a printer attached to a comm server.  The de facto standard
LPD protocol, as generally implemented, is held not to be suitable for
printing to comm servers, because it transfers the job control information
after the data itself, and therefore requires that the LPD server have a
large (typically multimegabyte) spool space.  Diskless comm servers
can't spool entire print jobs, and therefore can't act as traditional LPD
servers.  Basically, as LPD assumes that the print server is running 
a fullblown BSD Unix, it features a creeping crudism (e.g. having the 
server send e-mail at print job completion) that is inappropriate to
serving printers via commodity electronics.

Solutions that require a separate host to handle the queue for a 
comm server-attached printer (such as the "rtelnet" method) are unappealing 
due to the poor uptime of hosts (taken down for backups, 15-minute reboot 
times, etc.) and due to the fact that such solutions require print data to 
traverse the network twice en route to paper.  What is wanted is a method
that allows multiple print clients to directly access the printer via the net,
but which is cheap and easy to implement on the client side.

I would like to suggest that TCP/IP printer servers implement the
"raw TCP connection" approach, which TGV MultiNet implements on 
the client side as the "stream symbiont", and which I believe is basically 
the same thing as the Xylogics Annex aprint protocol.

In this very simple mechanism, it is up to each printer client
to maintain its own queue.  When the client-side daemon needs to 
despool a print job, it simply opens a raw TCP connection to the 
destination IP node / TCP port number (where the target TCP port
number should map to one or a set of physical serial ports on the
comm server.)  The client-side daemon then ships the data to
the comm server as a raw TCP stream of ASCII data.  When the 
server has acked the last of the TCP data, the client daemon closes
the TCP connection.

If there is already a TCP connection to the target port (typically from
another print client), then the comm server can simple refuse the
connection.  It would then be up to the client daemon periodically 
to retry establishing the TCP connection, say every 30 seconds or
so.  

A nice (but not essential) feature that the comm server could implement 
(a feature found in MultiNet) would be to maintain a per-TCP-port queue 
of connections to service.  (This queue should be of finite depth, say 3 to 
10 connections.)  If there is already data flowing to a port, then the comm 
server could accept incoming TCP connects to that port, but hold off on 
accepting data from that connection.  When the active connection closes,
the comm server would then begin accepting data on the next TCP connection
to service.  (If the TCP connection queue fills up, then of course the comm
server would refuse new TCP connects.)

Using TCP port queueing would have the advantage of more quickly servicing
a pending print job, because the print client wouldn't have to wait till the
next poll interval to send data.  It would also allow some network-wide
queueing fairness, by maintaining a FIFO of TCP connection, so that print
clients would have no incentive to embark on a beggar-thy-neighbor 
strategy of tiny TCP connection retry intevals.  However, port queueing
would be by no means necessary to the success of this scheme.

I believe that most TCP-capable comm servers already support direct
TCP connections to a serial port via a mapping from TCP port number to
physical port id.  In the specific case of the Xylogics Annex, unfortunately
there are software problems (or have been until very recently, at any case) 
that prevent "raw TCP connection" printing from working properly.  (The
Annex forgot flow control state between TCP connections to a port, so that
if a printer was set offline while there was no TCP connect in effect on it,
succeeding print jobs would be sent to the bit bucket.)

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
|>   If it ain't broke, break it.

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Oct 1992 12:41:00
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: what does completion of write() really mean?

In article <qnblp1k@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

    ...The Nagle algorithm causes amazingly bad performance for such
    applications.
    
    I think I've been told that common, standard X implementations like to
    do such things.  And so common X over TCP (instead of various local
    stuff) turns off the Nagle algorithm.

Having been on the receiving end of complaints about the lack of a Nagle
override in PC/TCP for DOS's TCP (only true of 2.03 and earlier), I can
comment.  First, the segment lengths they're handing in that way are
on the order of 80 to 160 bytes.  Second, the "amazingly bad performance"
they complained about was in fact "jerky mouse motion".  Which of course
you're going to get if there is any packet loss in transit anyway.

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488


-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 92 11:37:00 GMT
From:      gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546)
To:        comp.protocols.tcp-ip
Subject:   Re: AMERICANS and Texas kangaroos.us

In article <1992Oct19.164527.164803@dstos3.dsto.gov.au>, bat@dstos3.dsto.gov.au writes...
#I know I am about to raise a hornets nest with this one but the chance to
#annoy a whole nation I just can't resist.
..
#It sort of reminds me of the anecdote about the floral shirted American tourist
..
The British movie _Bullseye_ with Michael Caine and Roger Moore has a
running gag with some floral-shirted fat American tourist and his wife.
Every time some terrorist almost kills his wife, the American shouts after
him "Hey Buddy, at least let me buy you a drink!"

At one point a terrorist grabs this guy's wife and commands him to do
something... the American responds "I will not bargain with terrorists"
so the terrorist throws the wife into the river... and the American shouts
after the dude "Hey Buddy, at least let me buy you a drink! ... :-)"

#				Kick arse till you die  !

Yeah well if ya can't laugh at yourself, then you just
can't laugh at yourself.  - me at 4 in the morning

#				Brenton Thomas.
# 
#		
#							

Ehud

--
Ehud Gavron        (EG76)     
gavron@vesta.sunquest.com
So these three bartenders walk up to this string factory... and
there's a sign outside that says they don't serve bartenders...

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 92 12:04:18 GMT
From:      afc+@andrew.cmu.edu (Tony Calabrese)
To:        comp.protocols.tcp-ip
Subject:   name servers & bootp servers on 486


Has anyone used 486 PCs to run as name servers or bootp servers? If so,
could you please let me know the specifics on how it was done and how
reliable it was. If you have not used 486's as servers but know if they
can or can not be used as reliable servers, I would like to know that 
too. We are sort of in the design stage of our network, and using 486's
as dedicated servers seems to be a good way to provide dedicated and
inexpensive servers.


Thanks in advance,

Tony

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Oct 1992 13:00:44 GMT
From:      etxmesa@eos.ericsson.se (Michael Salmon)
To:        comp.protocols.tcp-ip
Subject:   Re: AMERICANS and Texas kangaroos.us

In article <1992Oct19.164527.164803@dstos3.dsto.gov.au>, 
bat@dstos3.dsto.gov.au writes:
|> I know I am about to raise a hornets nest with this one but the chance to
|> annoy a whole nation I just can't resist.
|> 
|> 	In the interests of internationalism, humility and just plain getting
|> along with your neighbours can we have a new top level domain called .us under
|> which .mil .com .edu etc are located ?   The rest of the planet all have to
|> route our mail via our own countries so  why not the Yanks ? 
|> 
|> I can understand the historical development and I am not attempting to 
|> understate American achievements in infotech but it bugs me.  

My understanding is that the .mil etc. domains were never intended to
be solely American it is just that few others have bothered to apply
for a name in one of those domains. I am pretty sure that the
University of Toronto for example is a member of the .edu domain and
the last time I looked that wasn't in the U.S.A.

Flame on.
One of my pet peeves is postings that are intentionally impolite.
Having spent far too may years in Australia I understand that it is a
part of the "Great Australian Kulture" but you might try behaving a
little better in international circles.
Flame off.

-- 

Michael Salmon

#include	<standard.disclaimer>
#include	<witty.saying>
#include	<fancy.pseudo.graphics>

Ericsson Telecom AB
Stockholm

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 92 13:32:21 GMT
From:      bjg@visionware.co.uk (Ben Giblett)
To:        comp.protocols.tcp-ip
Subject:   Kernel error message NOTICE: tcp sum:

I am running SCO Unix 3.2 rel 2 on an Apricot Qi 600 with 
the standard TCP/IP run time kit installed and running ok.

Everything on the network works ok. However:

Every 8-15 seconds I am seeing a Kernel error message on the console
as follows:

	NOTICE: tcp sum: src C09902FE, sum 0000683C

We have a router between this and another building and if I turn
that off then the message does not appear. In fact it buffers
the errors and turning the router back on means I see several 
at once.

Likewise if I unplug the machine from the Network then the 
message goes away.


Does anybody have any ideas.
It makes using the console and all its virtual terminals unuseable.

Please email me direct and I will post a SUMMARY.

Ben Giblett
--
-------------------------------------------------------------------------------
VISIONWARE LTD         | Job Title: Training Consultant 
57 Cardigan Lane       | Dept: Training Department     
Burley Road	       | EMAIL: ben.giblett@visionware.co.uk 
LEEDS LS4 2LE, England | VOICE:  +44 532 788858 FAX:  +44 532 304676
-------------- "VisionWare:   The home of DOS/UNIX/X/VMS integration" ---------

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Oct 1992 15:27:05 GMT
From:      rickf@theweav.cts.com (Rick Flower)
To:        comp.protocols.tcp-ip,comp.sys.sun.wanted
Subject:   Re: Dial-up SLIP for Sun wanted

gorton@tiger1.prime.com (Scott Gorton) writes:
: In article <1992Oct10.175334.474@elvis.sovusa.com>, andr@elvis.sovusa.com (Andrei Arkhipov) writes:
: > Hi.
: > 
: > I'm looking for SLIP implementation for SunOS 4.x with dial-up capability.
: > Can anybody help me?
: > 
: > Andrei.
: 
: UnixWorld (I think April '92) had a three or four page article entitled, 
: "Giving your Sun the Slip".  In it, they described where to obtain the SLIP
: sources and how to build it into your kernal.

You can also find the sources located on ftp.uu.net -- That's where I got them about a
month ago.  They have several versions -- based on the version of SunOS that you are 
running... Unfortunately, I don't have the exact directory where I found them.

: 
: Scott Gorton <gorton@s35.prime.com> 

-- Rick
-- 
+-----------------------------------------------------------------+
| Stimpy : Ren.. Will you Read Me a Bedtime Story??               |
| Ren    : A Bedtime Stoory.. Go read it yourself!!               |
+------------------------------------------------------+----------+

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Oct 1992 16:59:07 GMT
From:      markus@edfd.uucp (Markus Gruenkorn (MAGIC))
To:        comp.os.os2.networking,comp.protocols.tcp-ip
Subject:   Redirection of lpt1 with TCP/IP from FTP ?


Hi guys !
Is there any chance to redirect lpt1 to a
network printer with TCP/IP from FTP ?

Any information would be appreciated !


-- 
------ < MAGIC > ------

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Oct 1992 18:02:31 GMT
From:      karrer@bernina.ethz.ch (Andreas Karrer)
To:        comp.protocols.tcp-ip
Subject:   Re: Ping Reports: 31% Packet Loss...Possible Causes?

oberman@ptavv.llnl.gov writes:

[...CPT, SQE, heartbeat and the like...]

>If leaving it on, when the equipment is not a repeater (or the dread fanout),
>causes problems, get the offending equipment fixed! 

Someone please tell me:
What is so bad about fanouts, aka multiport transceivers, aka DELNIs; please?


Followups to comp.dcom.lans.ethernet



+-----------
  Andi Karrer, Communication Systems, ETH Zuerich, Switzerland
  karrer@bernina.ethz.ch    - Objects in mirror are closer than they appear

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Oct 1992 18:11:38 GMT
From:      ian@netcom.com (James Ian McGowan)
To:        comp.protocols.tcp-ip
Subject:   Beginner question - how do i find my ip addr when telnetting?

Is there any simple way of finding my own IP address when using
telnet?  Setting an environment variable from .login would be
optimal for what i'm trying to do.  Any help much appreciated...

ian@netcom.com
-- 
ian@netcom.com                         i'm not high on life, i'm high on drugs

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Oct 1992 18:18:03 GMT
From:      hartzman@kilroy.Jpl.Nasa.Gov (Les Hartzman)
To:        comp.os.os2.networking,comp.protocols.tcp-ip
Subject:   Re: Redirection of lpt1 with TCP/IP from FTP ?

In article <1992Oct19.165907.22251@edfd.uucp> markus@edfd.uucp (Markus Gruenkorn (MAGIC)) writes:
>
>Hi guys !
>Is there any chance to redirect lpt1 to a
>network printer with TCP/IP from FTP ?
>
>Any information would be appreciated !
>
>
>-- 
>------ < MAGIC > ------

Use LPRMON to redirect your output to the network.  Just tell it the server's
name, the printer's name (as known by the server), and which port (LPTn) you
are redirecting.  That should do it.  That is my current setup.

Good Luck.

Les

-- 
Les Hartzman                hartzman@kilroy.jpl.nasa.gov
Jet Propulsion Laboratory   M/S 238-528    (818) 354-5964
4800 Oak Grove Dr., Pasadena,  CA.  91109

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Oct 1992 18:34:23 GMT
From:      mike@gordian.com (Michael A. Thomas)
To:        comp.dcom.servers,comp.protocols.tcp-ip
Subject:   Re: How to TCP/IP print to a comm server (Was: Re: Annex 3 and lpd)

In article <1992Oct19.102528.3863@arizona.edu>, leonard@telcom.arizona.edu (Aaron Leonard) writes:
> (Copying a thread from comp.dcom.servers into comp.protocols.tcpip...)
> 
> It has been noted that there is no standard way to implement TCP/IP
> printing to a printer attached to a comm server.  The de facto standard
> LPD protocol, as generally implemented, is held not to be suitable for
> printing to comm servers, because it transfers the job control information
> after the data itself, and therefore requires that the LPD server have a
> large (typically multimegabyte) spool space.  Diskless comm servers
> can't spool entire print jobs, and therefore can't act as traditional LPD
> servers.  Basically, as LPD assumes that the print server is running 
> a fullblown BSD Unix, it features a creeping crudism (e.g. having the 
> server send e-mail at print job completion) that is inappropriate to
> serving printers via commodity electronics.

  Entirely correct. Actually, writing a dippy SMTP handler isn't so
bad; TROFF on the other hand...
 
> I would like to suggest that TCP/IP printer servers implement the
> "raw TCP connection" approach, which TGV MultiNet implements on 
> the client side as the "stream symbiont", and which I believe is basically 
> the same thing as the Xylogics Annex aprint protocol.
> 
> In this very simple mechanism, it is up to each printer client
> to maintain its own queue.  When the client-side daemon needs to 
> despool a print job, it simply opens a raw TCP connection to the 
> destination IP node / TCP port number (where the target TCP port
> number should map to one or a set of physical serial ports on the
> comm server.)  The client-side daemon then ships the data to
> the comm server as a raw TCP stream of ASCII data.  When the 
> server has acked the last of the TCP data, the client daemon closes
> the TCP connection.

  One nit here. In a multihost/multiprotocol situation, a polled 
approach as you suggest here leads to a "fairness" issue. That is,
a polling host could effectively be starved out of ever getting 
hold of the printing resource. The solution to this dilemma is
to have the server maintain a list of pending connect requests
and notify the next in line host when a printing opertunity
arises.
  This is how DEC's LAT protocol works, as well as Lantronix's
RTEL and Xyplex's printing protocol (sorry, I forgot it's name). 
Novell's Pserver can be munged into working this way as well
(since the polling it requires in done by the server, not the
client) Apple's PAP does have the "fairness" problem. Even then,
although it is polled I believe it takes requests on a timestamp
basis -- but don't quote me on that :-)

> If there is already a TCP connection to the target port (typically from
> another print client), then the comm server can simple refuse the
> connection.  It would then be up to the client daemon periodically 
> to retry establishing the TCP connection, say every 30 seconds or
> so.  

  Having the server reconnect (or telling the host when to reconnect)
is a much better solution overall.

> I believe that most TCP-capable comm servers already support direct
> TCP connections to a serial port via a mapping from TCP port number to
> physical port id.  In the specific case of the Xylogics Annex, unfortunately
> there are software problems (or have been until very recently, at any case) 
> that prevent "raw TCP connection" printing from working properly.  (The
> Annex forgot flow control state between TCP connections to a port, so that
> if a printer was set offline while there was no TCP connect in effect on it,
> succeeding print jobs would be sent to the bit bucket.)

  Lantronix doesn't have this problem :-)

  If there are other vendors listening in here, would anybody be
interested in defining a standardized format for actually doing this
such that it  works across different vendors boxes? I suspect that the
user community would probably appretiate this. 
  Send mail to mike@gordian.com if you interested in standardizing
this problem. We (Lantronix) are fairly flexible, are you?

-- 

		Michael Thomas	(mike@gordian.com)
	"I don't think Bambi Eyes will get you that flame thrower..."  
		-- Hobbes to Calvin
		USnail: 20361 Irvine Ave Santa Ana Heights, Ca,	92707-5637
		PaBell: (714) 850-0205 (714) 850-0533 (fax)

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 1992 19:29:01 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.dcom.servers,comp.protocols.tcp-ip
Subject:   Re: How to TCP/IP print to a comm server (Was: Re: Annex 3 and lpd)

In article <1992Oct19.183423.406@gordian.com> mike@gordian.com (Michael A. Thomas) writes:
>  If there are other vendors listening in here, would anybody be
>interested in defining a standardized format for actually doing this
>such that it  works across different vendors boxes? I suspect that the
>user community would probably appretiate this. 

We would, we would!  Just make sure there's a way to have a pre-data
dialog and a post-data dialog, so that we can do printer setup and
shutdown.  You don't have to standardize that part of the dialog if
you don't want to -- just make sure it can be done.

The reason is that we need to be able to do things like set mode options
on the printer, if possible, and we need to be able to get information
like a page count, data error info, and paper jam info after the print
job completes.  The page count, in particular, would be helpful.

Even if you don't standardize that part, setting things up so that it
_can_ be implemented and perhaps standardized would be a big help.

-- 
Stephen Trier                                     
Network Services Engineering, IRIS/INS/Telecom    "Dessine-moi un mutton"
Case Western Reserve University                        - Le Prince
trier@ins.cwru.edu

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Oct 1992 19:31:05 GMT
From:      kimmel@nic.umass.edu (Matt Kimmel)
To:        comp.unix.ultrix,comp.protocols.tcp-ip
Subject:   Looking for SLIP/CSLIP/PPP for Ultrix 4.2A

Hi,

In the next couple of weeks, I need to install some kind of serial IP
software on a Decstation 5000 running Ultrix 4.2A, which will act as
a server for high-speed dialups.  I've seen quite a few packages out
there, but most seem to be for SunOS or for older versions of Ultrix.
Can anyone out there tell me which serial IP packages will work with
Ultrix 4.2A?  Has anyone actually gotten dialup IP of any kind working
on a 5000?  Any and all help would be much appreciated.

Thanks!
-Matt
-- 
Matt Kimmel		Networking Assistant		Univ. of Mass.

Personal mail:   kimmel@titan.ucc.umass.edu
Network-related: kimmel@nic.umass.edu

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Oct 1992 20:39:01 GMT
From:      kudzu@netcom.com (Michael Sierchio)
To:        comp.protocols.tcp-ip
Subject:   Re: Beginner question - how do i find my ip addr when telnetting?

In article <1992Oct19.181138.28434@netcom.com> 
  ian@netcom.com (James Ian McGowan) writes:

>Is there any simple way of finding my own IP address when using
>telnet?  Setting an environment variable from .login would be
>optimal for what i'm trying to do.  Any help much appreciated...

grep `hostname` /etc/hosts | awk 'NR == 1 { print $1 }'

gives you the first IP address listed for the current host in the
/etc/hosts file.  You can diddle with this as you please...

On netcom, this gives:

192.100.81.100
-- 
+--------------------------------------------------------------------------+
|  Michael Sierchio                          1563 Solano Avenue, Suite 123 |
|  kudzu@netcom.com                                Berkeley, CA 94707-2116 |
+--------------------------------------------------------------------------+

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Oct 1992 20:47:45 GMT
From:      westes@sti.com (Will Estes)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Looking For SIGCOMM Article Via Anon FTP

Does anyone know of an anonymous ftp source for the following article:

	"Measured Capacity of an Ethernet: Myths and Reality"
David R. Boggs, Jeffrey C. Mogul, Christohper A. Kent.  Proceeedings
of the SIGCOMM '88 Symposium on Communications Architectures and
Protocols, ACM SIGCOMM, Stanford, CA., August 1988, 31 pps.

-- 
Will Estes		Internet: westes@netcom.com

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 92 22:45:27 GMT
From:      bat@dstos3.dsto.gov.au
To:        comp.protocols.tcp-ip
Subject:   AMERICANS and Texas kangaroos.us

I know I am about to raise a hornets nest with this one but the chance to
annoy a whole nation I just can't resist.

	In the interests of internationalism, humility and just plain getting
along with your neighbours can we have a new top level domain called .us under
which .mil .com .edu etc are located ?   The rest of the planet all have to
route our mail via our own countries so  why not the Yanks ? 

I can understand the historical development and I am not attempting to 
understate American achievements in infotech but it bugs me.  

It sort of reminds me of the anecdote about the floral shirted American tourist
on the Indian Pacific who upon seeing some kangaroos out of the window could 
not resist informing the rest of the carriage that 

 " That ain't nothing. We've got bigger kangaroos than that back in Texas. "

				 
			
				Kick arse till you die  !


				Brenton Thomas.

		
							

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 1992 14:10:16 -0700
From:      jamin@caldera.usc.edu (Sugih Jamin)
To:        comp.protocols.tcp-ip
Subject:   Re: Bug fix for tcplib, a TCP/IP workload model


Hello,

This is yet another bug fix for tcplib, a library of TCP/IP workload model.
A few days ago I posted a note announcing a new version of two tcplib data
files.  Unfortunately the wrong files were copied to the ftp directory.
This has been corrected and all the files in the ftp directory have been
updated.  We sincerely apologize for any inconvenience this causes you.
And we thank Poul E. Heegaard of SINTEF DELAB, Norway for pointing out
our mistakes.  Following is the original announcement.

==========================================================================
Vern Paxson of LBL noticed that "there's a rather huge spike in the UCB 
ftp-data connections [of the trace data used in tcplib].  During that 
particular day [when the traces was collected,] there were 2312 
connections of 74 bytes each between the same two UCB and remote hosts.  
[Ninety five percent] of these connections came between 30 and 45 seconds
apart.  None of the other datasets showed this sort of traffic so it
clearly appears to be anomalous."

Fortunately for us...the anomaly did not show up in either our SIGCOMM or 
Journal of Internetworking papers because of the way we grouped multiple 
ftp-data connections into one conversation.

We have taken out the anomalous data from the two data files:
  ftp.nitems
  ftp.itemsize.
Both are available on jerico.usc.edu (128.125.11.6) for anonymous ftp,
in the directory pub/jamin/tcplib.  These files are meant to replace 
their namesakes in the tcplib/data.  To update your libtcp.a, remember 
to do a make in your tcplib directory after you replaced the two files.

Alternatively, you can get the new library or the whole set of sources 
from jerico.usc.edu:pub/jamin/tcplib as described below.  The papers 
[Caceres91] and [Danzig92] cited in the tech report are also available
for anonymous ftp from jerico.usc.edu:~ftp/pub/jamin/traffic. The file
traffic.ps.Z is for [Caceres91] and the files journal.part[1-4].ps.Z 
are for [Danzig92].
=======================================================================
The following technical report and the source library it describes are
available for anonymous ftp from jerico.usc.edu:~ftp/pub/jamin/tcplib.
(Jerico's IP address is 128.125.51.6.) The directory contains the 
following files:

  README
  libtcp_ds31_ultrix41.a.Z
  libtcp_hp90_hpux847.a.Z   /* not supported anymore because we 
                               lost access to our hp machine. */
  libtcp_sun3_sunos411.a.Z
  libtcp_sun4_sunos411.a.Z
  brkdn_dist.h
  tcpapps.h
  tcplib.1
  tcplib.tar.Z
  tcplibtr.ps.Z

All you need to transfer to use the library are: README, brkdn_dist.h, 
tcpapps.h, tcplib.1, and one of libtcp* that matches your setup.  You
need tcplib.tar.Z only if you must generate the library yourself.  
The file tcplibtr.ps.Z is the PostScript version of the tech. report 
which is introduced below:


    tcplib: A Library of TCP Internetwork Traffic Characteristics

                 Peter B. Danzig       Sugih Jamin

                    Computer Science Department, 
                 University of Southern California,
                 Los Angeles, California 90089-0781

                     traffic@excalibur.usc.edu

                            USC-CS-91-495

1. Introduction
  When simulating computer networks, it is necessary to specify the 
traffic between network nodes.  Typically, simulation studies of 
wide-area tcp/ip networks model traffic as a combination of Poisson 
processes and maximal rate streams--corresponding to telnet traffic 
and large file transfers respectively.  Such traffic models are 
justified when the modeler wants to show, for example, that his flow 
control or gateway scheduling algorithm responds well to worst case 
traffic or when essentially nothing is known about the real network
traffic.  However, such models do not reveal how similarly robust 
algorithms respond to the common case load.
  This paper describes tcplib, a library to help generate realistic 
tcp/ip network traffic.  Tcplib is motivated by our observation that 
present-day wide-area tcp/ip traffic cannot be accurately modeled with 
simple analytical expressions, but instead requires a combination of 
detailed knowledge of the end-user applications responsible for the 
traffic and certain measured probability distributions [Caceres91].  
We collected three-day traces of wide-area Internet traffic at UC 
Berkeley, University of Southern California, and Bell Communications 
Research.  Our study identified that out of more than 35 different 
application programs, ftp, smtp, nntp, vmnet, telnet, and rlogin are
responsible for 96% of wide-area tcp/ip bytes.  Two related studies, 
one at University College London and the other at Lawrence Berkeley 
Laboratory, identified a subset of these six applications as 
responsible for most of their wide-area tcp traffic [Crowcroft91] 
[Paxson91]. Tcplib models five of these six applications.  It excluded 
vmnet, an IBM mail exchange application , because it was absent from 
three of the five traces.  Furthermore, since telnet and rlogin have 
essentially the same characteristics, we have included in tcplib only 
routines describing telnetUs.  Additionally, we included characteristics 
of phone conversations based on the study reported in [Brady65] and a 
distribution of conversations composition breakdown derived from several 
stub-network traces.
-- 
sugih                                              Use email, save a tree.

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Oct 1992 08:56:18 GMT
From:      lr@cs.brown.edu (Luigi Rizzo)
To:        comp.protocols.tcp-ip
Subject:   Bad TTL from Ultrix 2.2


We have an old Microvax running Ultrix 2.2 which has problems in
being reached from the outside. We can ping the machine, but not
open a connection to it from nodes which are several hops far
away. traceroute output is as follows:

- from another local host:
traceroute to mv3500 (131.114.9.1), 30 hops max, 40 byte packets
 1  mv3500 (131.114.9.1)  8 ms !  8 ms !  4 ms !

- from a remote host to a working local host:
traceroute to 131.114.9.9 (131.114.9.9), 30 hops max, 40 byte packets
 1  131.114.1.9 (131.114.1.9)  4 ms  4 ms  4 ms
 2  131.114.245.2 (131.114.245.2)  27 ms  23 ms  23 ms
 3  131.114.9.9 (131.114.9.9)  35 ms  35 ms  27 ms

- from a remote host to the Microvax:
traceroute to 131.114.9.1 (131.114.9.1), 30 hops max, 40 byte packets
 1  131.114.1.9 (131.114.1.9)  4 ms  4 ms  4 ms
 2  131.114.245.2 (131.114.245.2)  23 ms  23 ms  27 ms
 3  * * *
 4  * * *
 5  131.114.9.1 (131.114.9.1)  35 ms !  27 ms !  31 ms !

From what I have read, the ! means problems with TTL on the
Microvax. Is there an easy fix ?

	Thanks
	Luigi
==================================================================
Luigi Rizzo                Brown University & Univ. di Pisa
e-mail: lr@cs.brown.edu, luigi@iet.unipi.it
==================================================================

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 92 12:30:56 GMT
From:      bob@pharaoh.cyborg.bt.co.uk (Bob the Nob)
To:        alt.unix.wizards,comp.unix.wizards,comp.protocols.tcp-ip
Subject:   IGP monitor


I am on a Pyramid MI/server running both sysV and BSD4.3 and trying to
monitor for IGP (port 9) broadcast packets and derive the address of the
gateway/router generating them.
I have a copy of Unix Network Programming by W. Richard Stevens but I can't
see how to apply any or part of the examples in solving this problem.
Any ideas on how to write a program to accomplish this task ?

Do I have to remove the tcp/9 udp/9 entries from the services file to stop
inetd "discard"ing them.
-- 
Success and failure mean simply  |     Bob Wood    (The nob)
the satisfaction and frustration |     Local Mail: bob@pharaoh
of desire. --- Luke Rhinehart    |     Usenet    : bob@cyborg.bt.co.uk

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 92 11:12:33 +0100
From:      halgas@mvax.uakom.cs
To:        comp.protocols.tcp-ip
Subject:   Re: PPP over Sync lines (Any Implementations??)

In article <1992Oct13.214449.17017@PA.dec.com>, mohanram@wsl.dec.com (Narayan Mohanram) writes:
> <line-eater-bait>
> Does anybody have PPP implementations over Sync lines. I am looking for
> details. The RFC 1134 mainly deals with Async line formats. I am not sure
> if this is what needs to be done over sync lines.
>
> I would like to talk to some-body who has implemented this.
Hello,
My friends from Brno have developed a card to PC and packet driver under KA9Q,
which are able to run synchronous PPP 64kb/s.
If you are interesting in this, you can contact them:

novotny@arwen.ics.muni.cs


-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Oct 1992 13:48:04 GMT
From:      markus@edfd.uucp (Markus Gruenkorn (MAGIC))
To:        comp.protocols.tcp-ip
Subject:   AS400/OPEN Connect TN5250 !


Hi !
I followed the discussion about communication to an AS400 and
Open Connect TN5250. Now I would like to know if you can use TN5250 
from Open Connect on TOP of PCNFS (with packet drivers or NDIS). Is it
running without adding a new driver (at the moment we use
PC-Support) and we managed to configure a MS-DOS PC running
PCNFS (with NDIS-drivers), mounting drives and using PC-Support, but the 
lack of memory is a problem) . Further more I would like to know
the price of the product and if anybody knows the address of a
german distributor ?
Thanks in advance !
-- 
------ < MAGIC > ------

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 92 16:32:25 GMT
From:      allen@mr.med.ge.com (Phil Allen 4-6086 MRCE)
To:        comp.protocols.tcp-ip
Subject:   Need FTP protocal docs

I need to get a copy of the docs for the FTP protocol for file transfer.
If it is online that would be great. Can anyone out there tell me where
to find it?

I could not find the FAQ for this newgroup so if this info is in there 
sorry about that.

Phil Allen

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 92 16:55:55 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: AMERICANS and Texas kangaroos.us

In article <1992Oct19.164527.164803@dstos3.dsto.gov.au>, bat@dstos3.dsto.gov.au writes:
> I know I am about to raise a hornets nest with this one but the chance to
> annoy a whole nation I just can't resist.
> 
> 	In the interests of internationalism, humility and just plain getting
> along with your neighbours can we have a new top level domain called .us under
> which .mil .com .edu etc are located ?   The rest of the planet all have to
> route our mail via our own countries so  why not the Yanks ? 
 
Testy this morning, arn't we. Ah, well. I have day like that, too.

You don't understand the problem. Hence you propose bad solutions.

.COM, .EDU, .GOV, etc. were never restricted to US organizations. The real
history is that some countries insisted that they have their own domains at the
top level. ther are many Canadian and European nodes in the .EDU and .COM
domain. Probably others that I am not aware of. Some Canadian sites maintain
dual identities in CA and EDU.

There is also a .US domain. But the Internet folks in this country were never
really keen on the idea of country domains and normally only private systems
are registered in it (like well.sf.ca.us) (the WELL in San Francisco,
CAliforinia, USA.)

And what the heck does any of this have to do with routing? That is done by IP
address of the system or gateway without regard to such trivia as the FQDN.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov		(510) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Oct 1992 17:09:56 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: AMERICANS and Texas kangaroos.us

In article <1992Oct20.085555.1@ptavv.llnl.gov> oberman@ptavv.llnl.gov writes:
>In article <1992Oct19.164527.164803@dstos3.dsto.gov.au>, bat@dstos3.dsto.gov.au writes:
>> I know I am about to raise a hornets nest with this one but the chance to
>> annoy a whole nation I just can't resist.
>> 
>> 	In the interests of internationalism, humility and just plain getting
>> along with your neighbours can we have a new top level domain called .us under
>> which .mil .com .edu etc are located ?   The rest of the planet all have to
>> route our mail via our own countries so  why not the Yanks ? 
> 
>Testy this morning, arn't we. Ah, well. I have day like that, too.
>
>You don't understand the problem. Hence you propose bad solutions.
>
>.COM, .EDU, .GOV, etc. were never restricted to US organizations. The real
>history is that some countries insisted that they have their own domains at the
>top level. ther are many Canadian and European nodes in the .EDU and .COM
>domain. Probably others that I am not aware of. Some Canadian sites maintain
>dual identities in CA and EDU.

There are also some Australian sites in the .COM (et. al.) shared top level domains.

Mr. Oberman is quite correct.

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 92 17:14:47 GMT
From:      elogan@hp835.mitek.com (Ernie Logan)
To:        comp.protocols.tcp-ip
Subject:   Re: AS400/OPEN Connect TN5250 !


Markus:
I tried to email, but your address bounced.....


To: markus@edfd.uucp
Subject: Re: AS400/OPEN Connect TN5250 !
Newsgroups: comp.protocols.tcp-ip
References: <1992Oct20.134804.28293@edfd.uucp>

In comp.protocols.tcp-ip you write:
>Hi !
>I followed the discussion about communication to an AS400 and
>Open Connect TN5250. Now I would like to know if you can use TN5250 
>from Open Connect on TOP of PCNFS (with packet drivers or NDIS). Is it
>running without adding a new driver (at the moment we use
>PC-Support) and we managed to configure a MS-DOS PC running
>PCNFS (with NDIS-drivers), mounting drives and using PC-Support, but the 
>lack of memory is a problem) . Further more I would like to know
>the price of the product and if anybody knows the address of a
>german distributor ?
>Thanks in advance !
>-- 
>------ < MAGIC > ------

Markus, OC/TN5250 is ported to Sun PC-NFS 3.01 and 3.5. It does not
require either packet drivers or NDIS to my knowledge. I have forwared
your note to info@oc.com so you should be hearing from someone more
knowledgeable about such requirements shortly. Also, I copied our
international group, so you should hear from them about who your
distributor in Germany is. I believe it is ServoComp AG, but I am not
certain.

-- 
Ernie Logan, Jr.                                      |My opinions are mine
Product Manager                                       |alone. No one else
AS/400 Host TCP/IP Products                           |would want them!!
elogan@oc.com  OpenConnect Systems   +1 214 888-0493  +1 214 484-5200
-- 
Ernie Logan, Jr.                                      |My opinions are mine
Product Manager                                       |alone. No one else
AS/400 Host TCP/IP Products                           |would want them!!
elogan@oc.com  OpenConnect Systems   +1 214 888-0493  +1 214 484-5200

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 92 17:36:32 GMT
From:      paul@frcs.Alt.ZA (Paul Nash)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet server that runs on a PC?

Someone asked, long, long ago:

   > I am looking for a telnet server that will run on a PC and that is 
   > capable of running Dos applications simultaneously.  If you have 

Maybe you've been pointed this way already, but WATTCP has a telnetd
that works quite well -- a sort of TCP/IP pc-anywhere clone.  It's
free, and there's probably source code for it (I haven't looked closely,
just grabbed the .exe and saw that it worked).
 
 ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---
 Paul Nash                                         paul@frcs.Alt.ZA
 Box 12475, Onderstepoort, 0110 South Africa         +27-12-5611879

 "Standards are great -- everyone should have one" (Kent Landfield)

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Oct 1992 18:43:49 GMT
From:      Donald E. Eastlake, III <dee@ranger.enet.dec.com>
To:        comp.protocols.tcp-ip
Subject:   Re: AMERICANS and Texas kangaroos.us

In article <1992Oct19.164527.164803@dstos3.dsto.gov.au> ,
bat@dstos3.dsto.gov.au writes:
>	In the interests of internationalism, humility and just plain getting
>along with your neighbours can we have a new top level domain called
 .us under
>which .mil .com .edu etc are located ?   The rest of the planet all
 have to
>route our mail via our own countries so  why not the Yanks ? 

First of all, domain names have absolutely nothing to do with routing.
 When you look up a name, you get an IP address and it could be
anywhere.  I have heard there are some hosts within the United States
with names under .jp.  Certainly their is a computer in New Zealand
registered under .aq and I know of a machine registered under
.sf.ca.us, which you would think implies it is in San Francisco,
California, USA, which is actually in Boston, Massachusetts.  If the
entity managing a DNS lets you, any IP address in the world can be
registered there.

Second, of the three letter top level names, only .mil and .gov are US
specific.  Why do all these organizations in other countries insist on
being chauvinistic and registering under their country code instead of
"edu" for educational, "com" for commerical, "org" for non-profit,
"net" for network management, or "int" for international?  I'm
particularly puzzled as to why so many international organizations,
including the ITU, branches of the United Nations, etc., register
under the country where their HQ is instead of under the provided
"int" top level domain.  (ie, itu.ch, .etc.).

> " That ain't nothing. We've got bigger kangaroos than that back in
Texas. "

Sure,	Donald

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 92 18:45:30 GMT
From:      rolf@saans.north.de (Rolf Nerstheimer)
To:        comp.protocols.tcp-ip
Subject:   rlogin protocol, just a question ...

Hi Netters,

just one question about the protocol rlogin uses:

IMHO, the client has to send:

\0user\0user\0terminal/speed\0    ( if my memory serves me well )

and the server answers with \0, when accepting the connection.

But _when_ has the server to answer ?
Has he to reply to the first \0 or must he wait until he got the whole
string ?
Or are both cases allowed ?

-- 
Rolf Nerstheimer, Surwisch 20, 2856 Sandstedt, Germany   | a private 
E-Mail: rolf@saans.north.de    Voice: +49 4702 1285      |   node           
"Contrariwise," continued Tweedledee, "if it was so, it might be; and if it
were so, it would be; but as it isn't, it ain't. That's logic." Lewis Carroll

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Oct 1992 19:47:59 GMT
From:      gaitan@hurricane.ih.att.com (45262-Gaitan)
To:        comp.protocols.tcp-ip
Subject:   SonOS Dynamic Retransmission Algorithm


1)
Is anyone familiar with, or knows about any documentation on the 
specifics of SunOS' algorithm for the dymanic retransmission feature?

I understand it looks at timeouts and response times, but for modeling 
purposes, I need to get some information on the criteria it uses to decide 
what block size to use.


2)
I think with SonOS4.1.1 the algorithm had a problem that the NFS block
size would go down to a minimum size and never go back to larger sizes.
I haven't noticed this problem with 4.1.2.  Was the problem fixed in
4.1.2?

-- 
Cesar Gaitan.                 |       Computing and Networking
c.gaitan@att.com              |       Technology Department,
                              |       AT&T Bell Laboratories.

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Oct 1992 20:05:03 GMT
From:      ssideek@uncc.edu (Sinnathambi M Sideek)
To:        comp.protocols.tcp-ip
Subject:   nfs-afs bridge


 
  Is there any bridge available to connect NFS and AFS.
i.e If I want to connect a system( group of systems) having NFS 
to access files in another group of systems having AFS, I guess
somewhere there is a bridge? Is it available in public domain or
commercially.

Thanking you in advance,

S.M.Sideek
CIM Lab,
UNCC, Charlotte

Email: ssideek@mosaic.uncc.edu



-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Oct 1992 21:24:40 GMT
From:      qmhansen@orion.arc.nasa.gov (Q Marion Hansen)
To:        comp.protocols.tcp-ip
Subject:   FCC dockets for Networking

This may be a bit off the subject, but I can`t seem to find a newsgroup
for federal regulations about network communications. Has anyone seen
such a group? Does anyone know of a FTP site which handles FCC dockets?

Thanks- Quince 



-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Oct 1992 21:33:23 GMT
From:      hughes@sde.mdso.vf.ge.com (Hughes Doug)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   now you see it, now you don't


Why does this section of code work with sun's C compiler but core dump
in inet_ntoa with gcc 1.40?

    while ( (read_ret = recvfrom( sock, buf, sizeof buf,
                  0, (struct sockaddr *) &caller,
                  &callsize)) > 0 ) {
        printf( "%s: read (from caller (%s, %d)) socket\n",
            argv[0],
            inet_ntoa(caller.sin_addr),
            ntohs(caller.sin_port));
        fflush(stdout);

Assume the bind is succesful and as I said, it works when I compile with
Sun's default (albeit substandard) C compiler.
  What gives?
Doug Hughes				hughes@sde.mdso.vf.ge.com

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Oct 1992 23:15:19 GMT
From:      kudzu@netcom.com (Michael Sierchio)
To:        comp.protocols.tcp-ip
Subject:   Re: Need FTP protocal docs

In article <1992Oct20.163225.1687@mr.med.ge.com> 
	allen@mr.med.ge.com (Phil Allen 4-6086 MRCE) writes:

>I need to get a copy of the docs for the FTP protocol for file transfer.
>If it is online that would be great. Can anyone out there tell me where
>to find it?

nic.ddn.mil:/rfc/rfc959.txt

Network Working Group                                          J. Postel
Request for Comments: 959                                    J. Reynolds
                                                                     ISI
Obsoletes RFC: 765 (IEN 149)                                October 1985

                      FILE TRANSFER PROTOCOL (FTP)


And while you're there, get the index...
-- 
+--------------------------------------------------------------------------+
|  Michael Sierchio                          1563 Solano Avenue, Suite 123 |
|  kudzu@netcom.com                                Berkeley, CA 94707-2116 |
+--------------------------------------------------------------------------+

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Oct 1992 06:29:00 -0400
From:      Pat_Barron@transarc.com
To:        comp.protocols.tcp-ip
Subject:   Re: nfs-afs bridge

ssideek@uncc.edu (Sinnathambi M Sideek) writes:
>   Is there any bridge available to connect NFS and AFS.
> i.e If I want to connect a system( group of systems) having NFS 
> to access files in another group of systems having AFS, I guess
> somewhere there is a bridge? Is it available in public domain or
> commercially.

Sure; there is the "AFS/NFS Translator", which you can optionally get
with AFS.  It lets you export an AFS filesystem to clients that only
speak NFS.  Of course, unless you're on a system type that AFS
supports natively, you won't be able to do AFS-specific operations
(like examining/modifying ACLs) from the NFS client (you *can* do this
from an NFS-only client that happens to be one of the system types
supported under "native" AFS, but in that case, it's better to just
run a native AFS cache manager, unless there is some compelling reason
not to).

You might want to ask on the INFO-AFS mailing list
(info-afs@transarc.com) to see how people are using the Translator, or
to ask specific technical questions about AFS (which probably don't
belong on the TCP-IP mailing list/newsgroup).  Mail to
"afs-sales@transarc.com" for sales-type info.

--Pat.

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 92 02:47:43 GMT
From:      westes@sti.com (Will Estes)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Semantics Of Send()?

I'm debugging an application that has been working fine over ethernet,
but does not work over SLIP.  I've identified where the application is
failing, and I need some help to understand the semantics of the send()
call.  

The way I read my sockets documentation, send() is supposed to either
send all of the bytes that you give it or return an error message.  The
part of the documentation that (sort of) implies this is as follows:
	"If the message is too long to pass atomically to through the
	underlying protocol, then the error EMSGSIZE is returned, and
	the message is not transmitted."

Under SLIP, we are sending 401 bytes, but the send() call is returning
256 bytes.  Is that a proper return value for send()?  Assuming that
this is a semantically meaningful return for send(), what are the
possible causes for it happening? 

Second, what is a typical SLIPMTU for a PC SLIP implementation?  I'm
using NetManage Chameleon, and I have a call into them to find what they
use for their maximum transmission unit (MTU).  Is there a call to
determine the SLIPMTU?  The getsockopt(,NSPROTO_SPP,SO_MTU,,) call looked
promising, but it also looks like it might be XNS-specific (I can't tell
from the documentation I have).   NetManage doesn't support the call in
any case.  Is there another call I can make?

Third, I am confused by the wording of the send() documentation: "If the
message is too long to pass *atomically* to through the underlying
protocol..."  I thought that any call made to TCP can deal with packet
sizes that are larger than the underlying media...in other words, IP
will fragment as appropriate to the media's packet size limitations.  So
is the reference to "atomic" in the quoted documentation a reference to
the TCP maximum segment size?  If so, I can't understand why send() is
not working on a 401 byte send!

Any help in understanding what is going on here is appreciated.

-- 
Will Estes		Internet: westes@netcom.com

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 92 12:56:18 GMT
From:      mckenzie@bbn.com (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re: AMERICANS and Texas kangaroos.us

In article <1992Oct19.164527.164803@dstos3.dsto.gov.au>
bat@dstos3.dsto.gov.au writes:

[stuff deleted]

}It sort of reminds me of the anecdote about the floral shirted American tourist
}on the Indian Pacific who upon seeing some kangaroos out of the window could 
}not resist informing the rest of the carriage that 
}
} " That ain't nothing. We've got bigger kangaroos than that back in Texas. "

I think that in the anecdote the tourist said:
" That ain't nothing. We've got bigger jackrabbits than that back in Texas. "
				       ===========

    __   
   /  | /\                  Alex McKenzie
  /   | \/                  mckenzie@bbn.com
  \__/|_/\_&_/~X_           617/873-2962
  

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Oct 1992 13:06:00 GMT
From:      koelman@cuby.stc.nl (Ton Koelman)
To:        comp.protocols.tcp-ip
Subject:   users of .int ( was Re: AMERICANS and Texas kangaroos.us)

In article <1992Oct20.184725.4695@nntpd.lkg.dec.com> Donald E. Eastlake,  
III <dee@ranger.enet.dec.com> writes:
> 
> Second, of the three letter top level names, only .mil and .gov are US
> specific.  Why do all these organizations in other countries insist on
> being chauvinistic and registering under their country code instead of
> "edu" for educational, "com" for commerical, "org" for non-profit,
> "net" for network management, or "int" for international?  I'm
> particularly puzzled as to why so many international organizations,
> including the ITU, branches of the United Nations, etc., register
> under the country where their HQ is instead of under the provided
> "int" top level domain.  (ie, itu.ch, .etc.).

We were blessed to use .int only recently. As fas as I'm 
aware we are still the only organization there.
All 50 hosts under .int are ours...

--
Ton Koelman   e-mail: koelman@stc.nato.int (NeXT Mail Welcome!)
SHAPE Technical Centre, P.O. Box 174, 2501 CD  The Hague
The Netherlands  (voice: 31-70-3142429, fax: 31-70-3142111)

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 92 13:39:06 GMT
From:      Lyle_Seaman@TRANSARC.COM
To:        comp.protocols.tcp-ip
Subject:   Re: nfs-afs bridge

Transarc sells an NFS-AFS translator, which runs on an AFS client and
exports AFS.  The translator manages authentication, ACLs, caching,
etc, on behalf of NFS clients.  To the best of my knowledge, there are
no competing competing commercial products or freely-redistributable
solutions. 

The sales email address is afssales@transarc.com.
There is a mailing list for discussion of AFS topics.  To be added to 
or removed from the list, send mail to info-afs-request@transarc.com.

Lyle		Transarc		707 Grant Street
412 338 4400	The Gulf Tower		Pittsburgh 15219

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 92 13:50:00 GMT
From:      Lyle_Seaman@transarc.com
To:        comp.protocols.tcp-ip
Subject:   Re: AMERICANS and Texas kangaroos.us

bat@dstos3.dsto.gov.au writes:
>  " That ain't nothing. We've got bigger kangaroos than that back in Texas. "

See, here in Texas, we don't let people shoot our kangaroos, and the
ones in the zoos get fed real well, so they live long enough to get
big...   And we've got a selective breeding experiment going on,
trying to raise world's largest kangaroo.  So you can't go discounting
offhand remarks as arrogance when you just don't know all the facts.  

I've heard rumours that a secret MITI project has been started to
overtake our selective kangaroo breeding project.  What's more,
they're making real progess using genetic engineering.  But they've
had to declare a brief hiatus while building a new facility -- seems
they've run out of room -- so they're moving the project to Korea.  
Yeah, that's it, Korea...

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Oct 1992 15:04:37 GMT
From:      scoggin@opus.ee.udel.edu (John K Scoggin)
To:        comp.protocols.tcp-ip
Subject:   New discussion mailing list for Raptor's Eagle Firewalls


		Raptor Systems Mailing List

This is an announcement of a mailing list for users and prospective users of
network security products manufactured by Raptor Systems.  These include the
Eagle and Eaglet systems.       

To be added or removed from this list, send mail to :
		raptor-request@delmarva.com 

Mail to the mailing list should be directed to:
		raptor@delmarva.com

	- John

+---------------------------------------------------------------------+    
|  John K. Scoggin, Jr.			Email: scoggin@delmarva.com   |
|  Supervisor, Network Operations       Phone: (302) 451-5200         |
|  Delmarva Power & Light Company       Fax:   (302) 451-5321         |
|  500 N. Wakefield Drive                                             |
|  Newark, DE 19714-6066		                              |
+---------------------------------------------------------------------+

P.S. - I have no financial interest in Raptor Systems.  Simply a happy
user...


-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 92 15:51:53 GMT
From:      chrisp@slc.com (Chris Pinkham)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem in getting the client machine's IP address, Urgent!

>I am writing a client/server program in (TCP) socket and want to catch the 
>IP address of the clent machine in server. I think I could catch the address
>after the accept(), but all I got is 0.0.0.0. It is really a simple program.
>I hope somebody could help me found the problem at cs000hf@selway.umt.edu. 

You are not telling accept() how much room it has to write the client
address structure. You need to add

  address_len = sizeof(pin);

before you call accept().

Chris

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Oct 1992 15:54:21 GMT
From:      billp@ncsa.uiuc.edu (Bill Pottenger)
To:        comp.protocols.tcp-ip
Subject:   SLIP capable terminal servers

Hello folks.  I'm not a regular reader of this newsgroup so I'm not certain
I can get an answer to my question here, but I'll give it a try.  Basically
I'm looking for a source for an inexpensive SLIP capable terminal server.
If anyone knows of such or of a better newsgroup to post such a question,
please advise me via email.
Thank you!
Bill

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Oct 1992 17:09:21 GMT
From:      A.Grant@ucs.cam.ac.uk (Alasdair Grant)
To:        comp.protocols.tcp-ip
Subject:   Re: AMERICANS and Texas kangaroos.us

In article <1992Oct20.085555.1@ptavv.llnl.gov> oberman@ptavv.llnl.gov writes:
>.COM, .EDU, .GOV, etc. were never restricted to US organizations. The real
>history is that some countries insisted that they have their own domains at the
>top level. ther are many Canadian and European nodes in the .EDU and .COM
>domain. Probably others that I am not aware of. Some Canadian sites maintain
>dual identities in CA and EDU.

"Many" is surely an overstatement?  The percentage of European education
sites registered under .edu is surely below 1% (can you name _any_?), and
the percentage of .com sites is not much higher (and they are mostly 
European branches of American companies).

Ditto for Japan, Australia, in fact the rest of the world.

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 1992 16:17:27 +0100
From:      Christophe.Wolfhugel@grasp.insa-lyon.fr (Christophe Wolfhugel)
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   3.2 telnet client

While studying the IBM AIX telnet client I have following options
negotiated:

telnet> open xxxx
Trying...
Connected to xxxx
Escape character is '^]'.
SENT do ECHO
SENT do SUPPRESS GO AHEAD
SENT will TERMINAL TYPE (reply)
SENT do SUPPORT SAK
SENT will SUPPORT SAK (reply)
SENT suboption TELOPT_NAWS Width 0, Height 0
RCVD will ECHO (don't reply)

login:

Is it legal to have the TELOP_NAWS suboption negotiated at this point ?
Shouldn't the client wait for the server to answer to the TERMINAL TYPE
request first ?

-- 
Christophe Wolfhugel    |    Email: Christophe.Wolfhugel@grasp.insa-lyon.fr
   "No keyboard, press F1 to continue"

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Oct 92 18:48:04 GMT
From:      david@monymsys.mony.com (David Kozinn)
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone using OpenConnect software?

My company (Mutual of New York) is making substantial use of OCS products.
We're running about 60 OCS "boxes" (eventually 80) which connect our remote
agencies with our corporate data center over an SNA network consisting of
multi-dropped 9600 baud (yes, ugh) leased lines. We also use their FTP server
on our corporation mainframe to send data to, and get data from, those
agencies.


It hasn't been the smoothest process in the world, but it does work. If there
is anything in particular that you need help with, drop me a line.
-- 
David Kozinn                  | UUCP:   uupsi!monymsys!david
Mutual of New York  MD 75-14  | Domain: david@mony.com
Glenpointe Centre West        | GEnie:  D.KOZINN 
Teaneck, NJ 07666-6888        | Phone:  +1-201-907-6990

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 92 20:00:21 GMT
From:      pstevens@Metaphor.COM (Paul Stevens)
To:        comp.protocols.tcp-ip
Subject:   Receiving your own broadcasts

Is there any defined standard as to whether a *process* should
receive the broadcast datagrams that it sends.  For example, if
a process uses a well-known port to communicate with other hosts
by means of broadcasting should it expect to receive this same
datagram?  Is this implementation specific or is there a defined
standard to govern this behavior?

+------------------------------------------------------------------------+

   Paul Stevens                        {apple|decwrl}!metaphor!pstevens
   Metaphor Computer Systems           pstevens@metaphor.com
   Mountain View, CA

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Oct 1992 21:00:20 GMT
From:      roy@mchip00.med.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   multiple addresses on one interface?

	Is there any fundamental reason why a host can't have more than one
IP address on a single network interface?  Assume that I can hack my
system's kernel to do whatever needs to be done.  The question is more from
the external view; would this produce any outside-visible problems?  The
only thing I can think of that sort of depends on a one-to-one mapping of IP
to ethernet addresses is rarp, and it's not clear in my mind what you need
rarp for if you're not doing something like using it to auto-configure your
IP address.  The same for bootp, I guess.

	I'm sure the lack of software support would make this impractical to
do, but it's an interesting question anyway (at least to me).


-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Oct 1992 22:52:49 GMT
From:      kre@cs.mu.oz.au (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Re: AMERICANS and Texas kangaroos.us

In <1992Oct20.184725.4695@nntpd.lkg.dec.com>
Donald E. Eastlake, III <dee@ranger.enet.dec.com> writes:

| Second, of the three letter top level names, only .mil and .gov are US
| specific.

I believe this is true, but if the three letter domains are really
going to be used for the world, and the country domains didn't exist,
where would non-US military and government sites be registered?

Even if (the largely unstated) restrictions on those two domains
were to vanish, where would sites that fit none of the three letter
domains be registered?  (Ie: not commercial, or organisations, or
educational, or international, or government, or military, or
whatever else I forgot) - as in personal hosts at home, for example.
I doubt that its possible to register an Australian home PC in
the .US domain (which wouldn't exist anyway).

| Why do all these organizations in other countries insist on
| being chauvinistic and registering under their country code

Its not necessarily chauvinistic, though that can sometimes be it.

Two other possible reasons ... first the NIC is funded (essentially)
by the US taxpayers, as a good, moral, ethical, non-US type of
person, its not exactly fair for me to burden the US taxpayer with
the adminstrative costs of handling my domain registration, now is it?

Ok - well, perhaps that isn't often the real reason...

But apart from that, and for good reasons, registering under
country domains is often much faster that registering in the
TLD's, with much less bureaucracy - in AU typically if you need
some change made to your DNS registration (including needed to be
added) and its urgent, the update can normally be done within
hours - if the request had to be sent to the NIC they wouldn't
even see it that quickly, as time differences would mean that
the people who do this work would be home somewhere...  I'd expect
the same is probably true of many of the other country domains.

This isn't to denigratrate the NIC at all - they have far more to
do than we do - and further, (at least here in AU) we have the
country divided up into sub-domains (com.au edu.au ... not original
but effective..) and those domains are then managed by different
people, so the workload is even lower.

kre

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Oct 1992 01:57:05 GMT
From:      mstrong@cactus.org (Michael J. Strong)
To:        comp.protocols.tcp-ip
Subject:   Multiple RPC Servers on a single host

I'm trying to understand the execution model of an RPC server.

Only one instance of an RPC program can be registered in the portmapper
for a given version of the program, right?

Furthermore, each remote procedure call has to go through the port
mapping process, right?, or does the client do it only once (during
handling of the clnt_create (or its equivalent) function)?

Here's the bottom line:

I want inetd fire off a separate RPC server for each client that tries
to rendevouz with a server.  I would like these to run concurrently on
one server host.  How can I do this?  Can this be done?

It is easy to have inetd fire off multiple instances of a non-rpc
server with a known port number... but the portmapper seems to
constrain me to only ONE server process on a host at a time.

I need some quick replies, folks.

Thanks in advance.

Mike


P.S. I will gladly pay for any long distance calls with anyone who
would like to discuss this with me.


=======================
Mike Strong			
strong@trilogy.com or mstrong@cactus.org
Day (CDT) phone: 512/794-5900 ext 190
-- 
=======================
Mike Strong			
mstrong@cactus.org or strong@trilogy.com
Day phone: 512/794-5900 ext 190

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 92 02:32:28 GMT
From:      ev002b@uhura.cc.rochester.edu (Eric Volpe)
To:        comp.protocols.tcp-ip,comp.unix.ultrix
Subject:   putting 4.3 TCP code into ultrix?


Has anyone had any experience getting the modern BSD TCP code to work in
Ultrix 4.1?  It looks like its going to take a lot of fiddling to get it to
compile. I've started (with Ultrix 4.1 on a decstation 3100), but if anyone 
has done this already I'd sure like to have something to work from.

Failing that, has anyone gotten PPP running on ultrix 4.1?

				eric volpe
				(eric@lancelot.cif.rochester.edu)

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Oct 1992 02:42:06 GMT
From:      westes@sti.com (Will Estes)
To:        comp.protocols.tcp-ip
Subject:   Want To Buy DEC's Network Troubleshooting Guide

I recently read about a book named the Network Troubleshooting Guide by
DEC (Digital part number EK-339AB-GD-002).  If anyone has an extra copy
that they no longer need and would like to sell, please contact me by
mail.

-- 
Will Estes		Internet: westes@netcom.com

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 92 03:49:00 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: AMERICANS and Texas kangaroos.us

bat@dstos3.dsto.gov.au writes:

> 	In the interests of internationalism, humility and just plain getting
> along with your neighbours can we have a new top level domain called .us
> under which .mil .com .edu etc are located ?   The rest of the planet all
> have to route our mail via our own countries so  why not the Yanks ? 

You know, I can't wait for the eventual Lunar and Martian colonies to get
on the net.  I'm going to love reading postings from the astronauts
demanding that .us, .uk, .au, etc. rename themselves to be under the
".earth" root domain.  And I'm going to laugh myself sick reading followups
from you Aussies protesting about how much work it would be, and how all
your mailing addresses would have to change, and root domains were assigned
before anyone really thought about interplanetary net links, and we were
here first, anyway....

-- 
Tom Fitzgerald   Wang Labs       fitz@wang.com   "I went to the universe today;
1-508-967-5278   Lowell MA, USA                   It was closed...."

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 92 04:16:35 GMT
From:      fhl@milton.u.washington.edu (Dean Pentcheff)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Reading DOS (/pcfs) floppy disks without root privilege?

Is there a way to read DOS-formatted disks on a SPARCStation running
SunOS 4.1.1 _without_ needing root privileges?

My procedure at present is:
    1) stick in DOS floppy disk
    2) su to root
    3) mount /pcfs
    4) un-su back to original uid
    5) do things with the disk
    6) su to root
    7) umount and eject the disk

Sure, it works, but either I have to go over and mount the disk
whenever anyone wants to read a DOS disk, or I have to post the root
password on the console monitor.  Neither of these options thrills me.

Is there some tricky bit I'm missing that will allow me to mount a DOS
disk without needing to be a root user?

Many thanks for your help.

-Dean
P.S. Please use signature or Reply-To address.  I'm not actually at
the login from which I read/write netnews.

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 92 12:05:09 CST
From:      bennett@dstos3.dsto.gov.au
To:        comp.protocols.tcp-ip
Subject:   Re: AMERICANS and Texas kangaroos.us

In article <1992Oct19.130044.3141@ericsson.se>, etxmesa@eos.ericsson.se (Michael Salmon) writes:
> Flame on.
> One of my pet peeves is postings that are intentionally impolite.
> Having spent far too may years in Australia I understand that it is a
> part of the "Great Australian Kulture" but you might try behaving a

Hey, he doesn't speak for all of us !  We're not all like that.

> little better in international circles.
> Flame off.

Thank you.   Regards,

John Bennett                                E-mail: bennett@dstos3.dsto.gov.au
Head, Networks Group                        Phone : +61 8 259 5292
Corporate Information Systems               FAX   : +61 8 259 5537
DEFENCE SCIENCE AND TECHNOLOGY ORGANISATION Postal: Bld 73 Labs Area
AUSTRALIA                                           PO Box 1500 Salisbury 
            "Lord Warden of the Sync Ports"         South Australia  5108
                (DSTO Network Manager)              AUSTRALIA

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Oct 1992 14:38:34 GMT
From:      dsg@blackbird.mitre.org (David S. Goldberg)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple addresses on one interface?


Though probably not quite what Roy has in mind, there is at least one
box I know of that will respond to multiple IP addresses on the same
interface.  The Annex terminal server has a feature that allows you to
assign a set of ports to an IP address.  This is useful for making a
system that doesn't have it's own ethernet interface available to the
net.  I'm told that other TS's can do this as well, but have no direct
experience.

--
Dave Goldberg                      UNIX Systems Programmer/Administrator
Post: The Mitre Corporation MS B020 202 Burlington Rd. Bedford, MA 01730
Phone: 617-271-2460
Domain: dsg@mbunix.mitre.org  UUCP: {your neighborhood}!linus!mbunix!dsg 


-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 92 14:50:39 GMT
From:      aris@unisup1.uucp (Aris Stathakis)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   SCO TCP/IP + Lan Workplace + telnetd timeouts

I have a problem where multiple users are logging into a SCO UNIX box
running SCO UNIX 3.2v2.0 and SCO TCP/IP 1.1.3f.  Often these users
are just rebooting their PC's which causes the telnet session to
sit idle while the user isn't even logged in.  Apparently SCO TCP/IP
has a two hour keep-alive timer which disconnects sessions if there
has been no network traffic on the line. 

I'd like to know if anyone has come up with a workaround to this problem,
perhaps with some sort of pre-shell that traps some signal or another
and closes the session gracefully when a user drops the connection
rather abruptly.

Please respond by e-mail and I'll summarize.

Thanks

Aris


-- 
Aris Stathakis        Tel +27 11 887 4220 |Gimme a beer and money sandwitch -  
SCO Unix Support      Fax +27 11 887 1141 |Hold the bread. - Waldo D.R. Dobbs
UniNet - A Division of Lasernet (Pty) Ltd |_________________________________
P.O. Box 78446, Sandton, 2146, R.S.A       Internet:   aris@unisup1.UUCP      

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 92 14:55:41 GMT
From:      allen@mr.med.ge.com (Phil Allen 4-6086 MRCE)
To:        comp.protocols.tcp-ip
Subject:   Need FTP protocol help


Greetings,

I need to get a copy of the FTP protocol rfcs but do not have
FTP at my site.  Would someone be kind enough to email me a 
copy of rfc959.txt and rfc1123.txt. 

Thanks in advance.

-----------------------------------------------------------------
Phil Allen                
allen@mr.med.ge.com

Emacs is not an editor it is a lifestyle.
-----------------------------------------------------------------

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Oct 1992 17:58:00 GMT
From:      sblair@upurbmw.dell.com ()
To:        comp.protocols.tcp-ip
Subject:   Re: name servers & bootp servers on 486

[ remember I do work at  a PC company ]

All DNS hosts, as well as email hubs here inside of DELL are
PC's. Heck, our internet gateways are 16Mhz 386's.

All run SVR4 -- we're a USL licensee. I have about 4100 IP hosts
assigned, with over 4500 email aliases maintained on these machines.

I'm just ordering 486's as I want more disk space, and the internet
g/w's also have quite a bit of PD srcs, for anonymous FTP.

Only complaint I have is only having a SLIP connection from home.


-- 
Steve Blair	DELL NETWORK SERVICES	sblair@dell.com	hostmaster@dell.com
===========================================================================
they weebles-they wobles-they weebles-they wobles.........  the FDDI family

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Oct 1992 18:49:29 GMT
From:      kfl@access.digex.com (Keith F. Lynch)
To:        comp.protocols.tcp-ip
Subject:   Class B network

Our company has a class B tcp-ip license.  I've recently been told that
this means we can connect to the Internet at only one point.  This would
not be good, since we plan to install about 20 nodes at each of about 100
very widely scattered sites, and eventually to link some or all of them
into the Internet (probably the DDN) via a host at each site.

Should we start over and get a hundred class C licenses instead?

Our addresses are 159.227.x.y

Thanks.

Keith Lynch, kfl@access.digex.com


-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Oct 1992 19:27:56 GMT
From:      pae@blackcat.stortek.com (Phil Earnhardt)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple RPC Servers on a single host

In article <1992Oct22.015705.7412@cactus.org> mstrong@cactus.org (Michael J. Strong) writes:
>I want inetd fire off a separate RPC server for each client that tries
>to rendevouz with a server.  I would like these to run concurrently on
>one server host.  How can I do this?  Can this be done?

You're only talking about one RPC service, right? You just want to fire
off an instaniation (sp?) of that RPC service on the server platform
for each client which wants to make a connection?

This is a dispatcher/server issue and has nothing to do with the
naming/addressing scheme that you're using (in your case, RPCBIND).

The top-level process that is accepting the connections is a
dispatcher. It will create the child processes that actually service the
child requests. This is standard stuff in RPC land.

Once the TCP/IP connection is established to the client machine, you
can achieve the behavior you want by forking off the server process.
The child process will process the client request; the parent process
will go back to dispatching new client requests.

The main thing I'm unsure about is if standard ONC RPC has the hooks
for letting you do this on your own.

One thing I do know is that the Netwise RPC tool does have such hooks.
Netwise's RPC Compiler is available as a front end to ONC RPC these
days; you may want to ask your local Sun salesman how one acquires
this beast. Under Netwise's technology, what you want is just a
multi-processing dispatcher (contrasted with a single-threaded or a
multi-threaded dispatcher).

>It is easy to have inetd fire off multiple instances of a non-rpc
>server with a known port number... but the portmapper seems to
>constrain me to only ONE server process on a host at a time.

You only need one *listener*. Or call it a dispatcher. That doesn't
limit you to servicing more than one simultaneous request.

>I need some quick replies, folks.

The other way to go, if you're using UDP, is to do the NFS fiat: fork
off a whole bunch of workers who are all listening on the same UDP
port. Typically, the O/S will round-robin between the servers....

>Mike

--phil

Disclaimer: I used to work for Netwise; I like their stuff. My opinions
are not necessarily those of STK.


-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 92 19:58:05 GMT
From:      merlin@lerami.lerctr.org (David Hayes)
To:        comp.protocols.tcp-ip,alt.bbs.internet
Subject:   Looking for document: Internet 2000

One of our business contacts referred me to a paper called "Internet 2000".
They provided no other information, and I've never heard of this.

Does anyone know where to find this thing? Is it FTP-able? If it's short,
could someone e-mail me?

If this isn't available online, please let me know who publishes it, and
their phone number.

Grateful for any help,

    David Hayes    214-714-2604    merlin@lerami.lerctr.org

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Oct 92 20:21:30 GMT
From:      lbelan@fert1.fe.psu.edu (Lawrence Belan ][/40960)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   CMU's bootp server and broadcasting?

I'm working on the CMU bootp server and after looking at the code
i found out that it dosen't use the limited broadcast for
the replies (addr of 255.255.255.255).

Since I'm setting up a net ove a few gateways I need to send the
reply via the broadcasting method.  Setting an arp table entry for        
a workstation on another subnet gives me a message that the network
is unreachable.

Any one out there re code the server to do that?
-- 
 Lawrence (Larry) Belan ][                       lbelan@fert1.fe.psu.edu
 Computer/Telecommunications Specialist             bp3@psuvm.psu.edu (or)
 PennState - Fayette Campus                         bp3@psuvm.bitnet
 Route 119 North  Box 519                     75745.242@compuserve.com        
 Uniontown, PA  15041-0519                         (412) 430-4163

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Oct 1992 21:20:39 GMT
From:      dhesi@cirrus.com (Rahul Dhesi)
To:        comp.protocols.tcp-ip,comp.unix.admin,comp.sys.sun.admin
Subject:   gated SIOCDELRT message -- why?

The "gated" routing program running on a SS1+ (SunOS 4.1) sometimes
syslogs the following error message, shown below folded to 80-character
width:

     Oct 21 21:26:12 bolero in.gated[68]: KERNEL DELETE 192.160.13.2    \
     mask 255.255.255.255 gateway 192.160.13.2    flags <GW HOST DYN>   \
     SIOCDELRT: No such process

The gated source code doesn't really explain what is happening.  Does
anybody know?  I will post a summary of emailed and posted responses.
-- 
Rahul Dhesi <dhesi@cirrus.com>
also: dhesi@rahul.net

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Oct 1992 21:38:13 GMT
From:      flog@open.ch (Florian Gutzwiller)
To:        comp.protocols.tcp-ip
Subject:   DEC Mailgate/Gatekeeper Concept ...

Can anybody comment on DEC's concepts for firewall and mailgatewaying concept  
(gatekeeper, mailgate, ...) for Internet sites. (performance, reliability,  
..).

thanks

--
Florian A. Gutzwiller	Phone:  +41-61-281-8600 
Open Systems AG		Fax:    +41-61-281-8603
Basel/Switzerland	E-Mail: flog@open.ch (NeXT)

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Oct 1992 00:09:16 GMT
From:      ffuentes@tolten.puc.cl (Fernando Fuentes SCC)
To:        comp.protocols.tcp-ip
Subject:   TELNET priority?

I would like to know if there is a priority to telnet over ftp
applications when you are running a lot of them in a UNIX machine.
I have that doubt, because, if I have a link (56 kbps for example), it
will considered satured under certain response time criterias ( I
suppose). Then, in order to extend the life of the channel, if I can
priorize TELNET, I will perform a better response time for interactive
users.
I don't know what happens when all the pakkets go through a router. It
only send them, and doesn't care about the application? 


Fernando Fuentes
SECICO 
Pontificia Universidad Catolica de Chile
Vicuna Mackenna 4860, Santiago, Chile 
ffuentes@tolten.puc.cl 

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 92 00:12:57 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: TELNET priority?

In article <1992Oct23.000916.14406@tolten.puc.cl>, ffuentes@tolten.puc.cl (Fernando Fuentes SCC)
writes:
| 
| I would like to know if there is a priority to telnet over ftp
| applications when you are running a lot of them in a UNIX machine.
| I have that doubt, because, if I have a link (56 kbps for example), it
| will considered satured under certain response time criterias ( I
| suppose). Then, in order to extend the life of the channel, if I can
| priorize TELNET, I will perform a better response time for interactive
| users.
| I don't know what happens when all the pakkets go through a router. It
| only send them, and doesn't care about the application? 

Ordinarily, routers simply forward IP packets onto a wire on a first-come,
first-served basis.  There are several ways to improve response time
of interactive applications, such as TELNET, over bulk data transfers,
such as FTP:

- some routers can look inside the packet and prioritize queueing 
  on the basis of priority type.  So, for example, you could specify 
  that IP traffic to/from the TELNET port (TCP port 23) would get 
  higher priority.  I believe that cisco routers, for example, can do
  this.

- you can reduce the IP MTU (maximum transmission unit) on 
  the serial line.  If the MTU (max packet size) is 1500 bytes, then
  a TELNET keystroke will be forced to wait (even with priority
  queueing) behind a big packet.  You can shrink MTU to, say,
  300 bytes, and this will provide perceived improved interactive
  response, at the expense of worse overall throughput.

- some routers can prioritize on the basis of the TOS (type of 
  service) field in the IP packet header.  If TELNET sets this field,
  then this can cause TELNET to enjoy improved priority, if the
  router honors TOS.  I don't believe this is too widely implemented,
  though.

- the router can have a policy to forward small packets ahead of
  big ones, for example by maintaining separate queues for different
  packet sizes.

- you also may be able to turn on header compression on the line.
  This will shrink the amount of header data needed to transmit a 
  packet, which will provide improved throughput, particularly for
  applications such as TELNET that generate packets with a high
  header/data ratio.

You will need to examine the documentation on your router (or
contact your vendor) to determine whether you may take advantage 
of any of these tactics.

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
  "It's not a bug, it's a form of flow control."
  - Jerry Leichter on why crash-prone Unix is a suitable
    platform for NSFNET core routers

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Oct 1992 05:10:28 GMT
From:      npngps@solomon.technet.sg (Ng Pheng Siong)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: CMU's bootp server and broadcasting?

In article <a1*vHx?3ca@atlantis.psu.edu> lbelan@fert1.fe.psu.edu (Lawrence Belan ][/40960) writes:
>I'm working on the CMU bootp server ...

Speaking of which: is there source code out there that dishes out IP addresses
from a given range without reference to the clients' MAC addresses?

E.g., addresses from the range 153.20.25.50 to 153.20.25.100 will be handed
out to clients; said clients' MAC addresses need not be in bootptab. 
Addresses no longer in use will be reclaimed.

I have a version of KA9Q over Dos that does this. I'm looking for source
to incorporate into CMU's bootpd code.

TIA.

- PhengSiong


-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 92 05:35:31 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple addresses on one interface?

roy@mchip00.med.nyu.edu (Roy Smith) writes:
+---------------
| 	Is there any fundamental reason why a host can't have more than one
| IP address on a single network interface?  Assume that I can hack my
| system's kernel to do whatever needs to be done.  The question is more from
| the external view; would this produce any outside-visible problems?
+---------------

Nope. In fact, it's often done to facilitate a gradual partitioning of a
network (though usually with multiple interfaces). That is, first you set
up a router with both addresses, then as you migrate individual hosts to
the new IP net, they use the router to talk to hosts which haven't moved yet
(or which aren't moving). Then you split the nets, and no one cares. [Yes,
for a while traffic on the single LAN may be almost doubled, since packets
from one IP net to the other have to bounce through the router, but that's
temporary.]


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 92 09:04:01 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: AMERICANS and Texas kangaroos.us



of course, there's always .int. and .nato.
maybe there should be a .red. as well...:-)

jon

one thing about texas and size that cannot compete with the UK is the
who large the idiocy of the british government is - by the way,
according to a open letter from the Provost of UCL, this DOES represent
the views of my employer!

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Oct 1992 09:50:31 GMT
From:      markus@edfd.uucp (Markus Gruenkorn (MAGIC))
To:        comp.sys.sun.misc,de.comp.os.unix,comp.protocols.tcp-ip
Subject:   Bridging (ISO/OSI layer 2) and a unix workstation ?


Hi !
Is it possible to get a sparc to bridge frames from one interface to
another (frames which are not IP) ? Is there a soft (PD ?) or hardware available. 
The sparc has to do the same thing as a router in our net which is equipped with a bridging-modul.
The bridging modul simply is forwarding frames (on layer 2 ISO/OSI) which are not from the typ IP.
I hope someone can help me !
Any information would be appreciated !





-- 
------ < MAGIC > ------

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 92 11:07:49 GMT
From:      jamesm@procor.dialogic.com (Mark James)
To:        comp.protocols.tcp-ip
Subject:   Re: AMERICANS and Texas kangaroos.us

In article <1992Oct19.164527.164803@dstos3.dsto.gov.au> bat@dstos3.dsto.gov.au writes:
>
>	In the interests of internationalism, humility and just plain getting
>along with your neighbours can we have a new top level domain called .us under
>which .mil .com .edu etc are located ? 

There is a domain called .us, under which you find a number of local public
access networks whose addresses look like:

        <user>.<netname>.<state-abbr>.us

>The rest of the planet all have to
>route our mail via our own countries so  why not the Yanks ? 

There is nothing particularly American about .com and .edu.  My Internet
address ends in .com, but I live in New Zealand.  The .com and .edu
domains are intended to be international; .com in particular caters to
multinational corporations.  (Under what country would you place IBM 
France, or Fujitsu Australia?)  The fact that Australian universities 
have chosen to align themselves under a national domain (.au) rather
than an international one (.edu) is a political decision on their part,
and has nothing to do with the Internet.

You might have a better point with the .mil and .gov domains.  These, as
I understand it, are the core of the old DARPAnet and might therefore be
entirely American.  But even here, the reasons for the separate domains
are historical and not imperialistic, so you haven't got any real basis
for being upset about it.

-- Mark.


-- 
Mark James  <jamesm@procor.dialogic.com> or <tmarkj@kcbbs.gen.nz>
Dialogic (N.Z.) Ltd.                Voice:  +64 9 302 1794 ext 27
Auckland, New Zealand               Fax:    +64 9 302 1793


-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 1992 11:47:59 GMT
From:      mjo@slee01.srl.ford.com (Mike O'Connor)
To:        comp.protocols.tcp-ip,comp.sys.dec
Subject:   Re: DEC Mailgate/Gatekeeper Concept ...

comp.sys.dec added to the distribution for obvious reasons.

In article <1992Oct22.213813.11286@bernina.ethz.ch> flog@open.ch writes:

:Can anybody comment on DEC's concepts for firewall and mailgatewaying concept  
:(gatekeeper, mailgate, ...) for Internet sites. (performance, reliability,  
:..).

I presume you're talking about DEC's SEAL.  I like their ideas and
their implementation, for the most part.  Most of what DEC's SEAL is
capable of can be implemented with PD packages, but I gather that a
lot of what you buy when you buy DEC's SEAL is competent minds from
DEC that know security and have "done this sort of thing before".

						...Mike

--
 Michael J. O'Connor           |  Internet:  mjo@fmsrl7.srl.ford.com
 Ford Motor Company, OPEO      |  UUCP:      ...!{backbone}!fmsrl7!mjo
 20000 Rotunda, Bldg. 1-3001   |  Phone:     +1 (313) 248-1260
 Dearborn, MI  48121           |  Fax:       +1 (313) 323-6277

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 92 12:07:18 GMT
From:      rob@wzv.win.tue.nl (Rob J. Nauta)
To:        comp.binaries.ibm.pc.wanted,comp.sources.wanted,alt.sources.wanted,comp.protocols.tcp-ip,comp.os.msdos.misc,comp.dcom.lans.ethernet
Subject:   TCPdump for MS-DOS ?



Hello

Has anyone ever ported TCPdump to MS-DOS with packet driver ?
I'd be interested in a copy, binary or source code. Other similar
programs are also always welcome.

Please reply by mail.

Rob
-- 
/-----------------------------------------------\	Never		   ,==.
| Rob J. Nauta, UNIX computer security expert.	| 	 Apologize,	  /@  |
| rob@wzv.win.tue.nl, Phone: +31-40-837549	| 	  Never		 /_  <
| Feel free to email me for free advice		|	   Explain.	=" `g'

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Oct 1992 13:34:48 GMT
From:      andy@homebase.vistachrome.com (Andy Finkenstadt)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Subject:   X.25 to TCP/IP PAD/Gateway

In order to gain the most connectivity and keep development costs
to their lowest, I am looking for a HARDWARE or SOFTWARE device 
which has on one end an X.25 line and on the other end an Ethernet
cable.

In effect I want someone who connects through our X.25 line to 
generate a connect to a specific TCP/IP port here on our
local ethernet.

Do such devices exist?  How much are they?  What is their reliability?

I invite any manufacturers or OEM or VARs to mail me with product
info or inquiries.

-Andy

-- 
Andrew Finkenstadt, Vista-Chrome, Inc., Homes & Land Publishing Corporation
GEnie Unix RoundTable Manager, andy@vistachrome.com, andy@genie.geis.com.
  Send mail to ora-request@vistachrome.com to join Unix, CASE, and 
  Desktop Oracle RDBMS Database discussions.

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 92 14:03:47 GMT
From:      system@condor.navsses.navy.mil
To:        comp.protocols.tcp-ip
Subject:   MHS to SMTP gateway?

Please forgive me if this is a FAQ for these groups, but I just started to read
them.  Is there a PD utility that can act as a gateway between MHS mail on a
NOVELL NETware lan, and a network of mini-computers (VAXes, SUNs, etc) running
TCP/IP (SMTP)?

thanks!

-- 
Mike Jacobi
NAVSSES VAXCluster system manager
System@Eagle.Navsses.Navy.Mil
System@Condor.Navsses.Navy.Mil

Disclaimer - I speak for myself.  No-one else.

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Oct 1992 14:56:18 GMT
From:      drichard@magnus.acs.ohio-state.edu (Darren R Richardson)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   5250 Emulator

Does anyone know of a shareware 5250 emulator for DOS that will use telnet and 
run on an ethernet card instead of a twin-axial adapter?  I am mainly looking 
for a TCP/IP package that will emulate this terminal.
-- 
 Darren Richardson
 Ohio State University
 College of Engineering
 CIS Consultant

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 92 15:07:53 GMT
From:      kismet@trantor.cc.umb.edu (Ted Corning)
To:        comp.protocols.tcp-ip
Subject:   Changing from Class C to Class B

Hi,

   Someone on comp.lans.ethernet suggested that this might be a better place
for this question.

   We currently have a Class C Internet address, and have been granted a
Class B Internet address. Our last network person left before we made the
change, and I find that the project now falls to me (of course).

   My first (and most important) question is: Who do I have to contact to
get our new network number into the proper routing tables? I'm pretty sure that
if we change our numbers, we'll probably disappear from the face of the planet
and nobody will be able to find us.

   My second question is more for opinions (but also information). I'm trying
to decide whether to subnet using the class C scheme (as mentioned by another
poster) or to subnet using a bitmask. I don't have a clear understanding of
the latter, so if you could point me to any documentation on the subject, it
would help.

Thanks in advance,
Ted Corning
UMass/Boston

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Oct 1992 16:07:34 GMT
From:      Dean.Roth <Dean.Roth@mixcom.mixcom.com>
To:        comp.unix.admin,comp.unix.aix,comp.protocols.tcp-ip
Subject:   inetd configuration questions


I have a network with several UNIX systems, including several
AIX 3.2 systems.  NIS is being used. (I'm not an NIS expert.)

After booting one of the AIX systems, netstat shows that a process
(inetd) is listening on a particular port.  That port is NOT in
the /etc/inetd.conf file. The service is in the /etc/services file.
*I know that no other process is listening on that port.*

Questions:

If inetd uses the /etc/inetd.conf file to know what ports to listen on,
why is it listening on a port not listed in the /etc/inetd.conf file,
but which is listed in the /etc/services file?  

If the NIS master is not running (also an AIX system), this does
not happen. The service is in the NIS master's /etc/services file, 
and *not* in the /etc/inetd.conf file.

Thank you.

Dean

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Oct 1992 17:16:42 GMT
From:      fff@microplex.com (Fred Fierling)
To:        comp.protocols.tcp-ip
Subject:   tftp broadcast packets

Would say, an X terminal, which *broadcasts* a tftp request for a
particular filename cause troubles on a large network?  That is,
could hundreds of hosts responding to such a request choke a network?
-- 
Fred Fierling    fff@microplex.com      Tel: 604 875-1461   Fax: 604 875-9029
Microplex Systems Ltd   265 East 1st Avenue   Vancouver, BC  V5T 1A7,  Canada

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Oct 1992 20:22:53 GMT
From:      Donald E. Eastlake, III <dee@ranger.enet.dec.com>
To:        comp.protocols.tcp-ip
Subject:   Re: AMERICANS and Texas kangaroos.us

In article <9229608.10742@mulga.cs.mu.OZ.AU> Robert Elz,
kre@cs.mu.oz.au writes:
>In <1992Oct20.184725.4695@nntpd.lkg.dec.com>
>Donald E. Eastlake, III <dee@ranger.enet.dec.com> writes:
>| Second, of the three letter top level names, only .mil and .gov are
 US
>| specific.
>I believe this is true, but if the three letter domains are really
>going to be used for the world, and the country domains didn't exist,
>where would non-US military and government sites be registered?

Military is a subset of government so it reduces to where government
sites would be registered.  I think that most governments consider
themselves to be "non-profit" and could thus register in .org if they
wanted.  Note:  the UNDP (United Nations Development Program I
think) is registered under .org.

>Even if (the largely unstated) restrictions on those two domains
>were to vanish, where would sites that fit none of the three letter
>domains be registered?  (Ie: not commercial, or organisations, or
>educational, or international, or government, or military, or
>whatever else I forgot) - as in personal hosts at home, for example.
>I doubt that its possible to register an Australian home PC in
>the .US domain (which wouldn't exist anyway).

I don't know about in .us but, if he was feeling friendly, Erik Fair,
postmaster for Apple Computer and administrator of the .sf.ca.us
domain, would probably be willing to register a few Australian
PCs  :-).   Seriously, you are correct.  There should be a .prs top
level domain for personal computers and the like.  It would be pretty
artificial to stick them into .org or something.

>| Why do all these organizations in other countries insist on
>| being chauvinistic and registering under their country code
>Its not necessarily chauvinistic, though that can sometimes be it.

...

>But apart from that, and for good reasons, registering under
>country domains is often much faster that registering in the
>TLD's, with much less bureaucracy - in AU typically if you need
>some change made to your DNS registration (including needed to be
>added) and its urgent, the update can normally be done within
>hours - if the request had to be sent to the NIC they wouldn't
>even see it that quickly, as time differences would mean that
>the people who do this work would be home somewhere...

This makes some sense but it still seems to me that it would be 
much more appropriate for truly international organizations, like
the ITU, to register in .int or .org than in Switzerland or the like.

Donald

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 92 22:25:28 GMT
From:      bware@slate.mines.colorado.edu (Bob Ware)
To:        comp.unix.admin,comp.unix.aix,comp.protocols.tcp-ip
Subject:   Re: inetd configuration questions

Dean.Roth@mixcom.mixcom.com (Dean.Roth) writes:
: 
 ...
: If the NIS master is not running (also an AIX system), this does
: not happen. The service is in the NIS master's /etc/services file, 
: and *not* in the /etc/inetd.conf file.

Probably a stupid question:

Did you execute "inetimp" and "refresh -s inetd" to make sure the odm
had what was in the inetd.conf file?

-- 
Bob Ware, System Administrator 
Computing and Networking, Colorado School of Mines, Golden, Co 80401, USA
(303) 273-3987
bware@mines.colorado.edu

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 92 00:24:01 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "Will do TCP/IP for clues" Ranum)
To:        comp.protocols.tcp-ip,comp.sys.dec
Subject:   Re: DEC Mailgate/Gatekeeper Concept ...

"Mike O'Connor" <mjo@fmsrl7.srl.ford.com> writes:

>Most of what DEC's SEAL is
>capable of can be implemented with PD packages, but I gather that a
>lot of what you buy when you buy DEC's SEAL is competent minds from
>DEC that know security and have "done this sort of thing before".

	This is exactly correct. Most of SEAL consists of ULTRIX,
with certain components replaced (sendmail, bind, ftpd, etc, etc)
with versions that are in fact available on the net. The only components
of the software that are proprietary are my telnet and FTP gateways,
which (by definition) don't take a lot of brains to write, since I
could do them.
	We're quite open with people that we consider SEAL to be a
consulting offering, not a software product. We're offering expertise,
training (we explain how it works), source code (we build it onsite)
and configurations that we know work for us and have protected us for
quite a while. We also try to price to consulting so that it costs
just about what we think it'd cost to roll your own from scratch,
if you assume that your staff time is reasonably valuable. And we
get it up and running in a day or two, rather than possibly months.
	There are lots of other consultants out there playing the
internet firewall game - we try to act like that, rather than
"here's a product, let's unpack this kit here and install it."

mjr.
-- 
[amended version]
	The universe can be divided neatly into three kinds of things:
		Marketing, Cappucino, and Source Code.
						-notebooks of a heretic

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 92 04:18:39 GMT
From:      benjamin-goldsteen@uokhsc.edu (Benjamin Z. Goldsteen)
To:        comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.unix.aix
Subject:   Re: help with PC-NFS from Sun

grover@ccai.clv.oh.us (grover davidson) writes:

>I have a question that I hope someone can help me with.


>We have installed pcnfs on our 386/486 machines running DOS-5.0. Our server
>is a RS/6000 running AIX version 3.2 and PCNFSD version 2.
 
>1) We are running pcnfslpd on a leading edge xt class machine. The
>drive activity light is on ALOT. 2 to 3 times a second.
>Is this normal? Is the system thrashing the drive?


>2) Am I correct in saying that to print to the leading edge running
>PCNFSLPD, I have to setup the printing to go THROUGH the RS/6000 
>print queue system?

     Sun PC-NFS has a pretty junky printing model (IMHO).  It mounts a
spool drive for each printer behind the scenes (LPT1 = T, LPT2 = U,
etc).  It copies your file to the the NFS drive and then it sends a
request to the PCNFSd to print the file in spool area.  I can't see a PC
running DOS handling these requests.  I am going to try to use 386BSD to
handle this, but I don't see why printing should even require a
386...what was wrong with the lpr stuff? (besides the fact that it
wasn't portable...though common enough that AT&T has support for it in
SVR4). 

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 1992 08:31:32 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Changing from Class C to Class B

In article <1992Oct23.150753.12009@cs.umb.edu> kismet@trantor.cc.umb.edu (Ted Corning) writes:
>   My first (and most important) question is: Who do I have to contact to
>get our new network number into the proper routing tables? I'm pretty sure that
>if we change our numbers, we'll probably disappear from the face of the planet
>and nobody will be able to find us.

You must tell the network you connect to.  In your case that's probably
NEARnet, so you should send mail to nearnet-ops@nic.near.net or call
873-8730.

>   My second question is more for opinions (but also information). I'm trying
>to decide whether to subnet using the class C scheme (as mentioned by another
>poster) or to subnet using a bitmask. I don't have a clear understanding of
>the latter, so if you could point me to any documentation on the subject, it
>would help.

If all TCP/IP implementations were done correctly, it wouldn't make much
difference.  However, there are some implementations that don't handle
subnet masks that don't end on a byte boundary.  So, if it meets your
needs (viz you only need 254 subnets and won't have more than 254 hosts on
a subnet), you should set your mask to 255.255.255.0.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 1992 08:36:18 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: tftp broadcast packets

In article <1992Oct23.171642.8886@microplex.com> fff@microplex.com (Fred Fierling) writes:
>Would say, an X terminal, which *broadcasts* a tftp request for a
>particular filename cause troubles on a large network?  That is,
>could hundreds of hosts responding to such a request choke a network?

Not likely.  All the hosts should only respond to the first tftp request,
which asks for the first block of the file.  Most of these responses would
be short "file not found" error packets.  The terminal should send all the
requests for the rest of the file only to one of the hosts that responds
successfully to the first packet.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Sat, 24 Oct 1992 16:58:29 GMT
From:      karrer@bernina.ethz.ch (Andreas Karrer)
To:        comp.protocols.tcp-ip
Subject:   Re: Changing from Class C to Class B

barmar@think.com (Barry Margolin) writes:

>If all TCP/IP implementations were done correctly, it wouldn't make much
>difference.  However, there are some implementations that don't handle
>subnet masks that don't end on a byte boundary.  

Please name them.

This was probably true some four or five years ago. We have a Class B net
with a 255.255.255.192 netmask; and i'd have yet to see a machine that
cannot handle our 10-bit-subnet 6-bit-host-part scheme.

Only very few or only very stupid people actually want more than 62
hosts on one subnet.

+-----------
  Andi Karrer, Communication Systems, ETH Zuerich, Switzerland
  karrer@bernina.ethz.ch    - Objects in mirror are closer than they appear

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 92 18:01:27 GMT
From:      shuford@cs.utk.edu (Richard Shuford)
To:        vmsnet.networks.tcp-ip.cmu-tek,comp.sys.dec,comp.protocols.tcp-ip,vmsnet.networks.misc,sub.os.vms
Subject:   Re: contact for obtaining CMU-Tek TCP/IP for VMS


I have received numerous e-mail messages claiming that some part of my
posting about how to obtain CMU-Tek TCP/IP is outdated.

Well, it may be, but the question has been asked in the CMU-Tek forum
(newsgroup/mailing list) several times in the past month with no
answer appearing.  At some time in the past, the information I posted
was correct.  I was trying to help with the best help I had.

OK, so one correspondent alleges that the correct address for general
licensing information is

    tcpip+@andrew.cmu.edu

And another alleges that the discussion mailing list emanates from

    cmu-tek-tcp@cmutek.cc.cmu.edu.

Of course, as is the convention for all major Internet mailing lists,
you subscribe or signoff a subscription to the list by sending a
request to the administrative address

    cmu-tek-tcp-REQUEST@cmutek.cc.cmu.edu,
 
and NOT to the mailing list address.



-- 
 ....Richard S. Shuford  | "It is not good to have zeal without knowledge,
 ....shuford@cs.utk.edu  |  nor to be hasty and miss the way."
 ....BIX: richard        |  Proverbs 19:2 NIV

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Sat, 24 Oct 1992 22:48:20 GMT
From:      bwarner@mentor.cc.purdue.edu (Bill Warner)
To:        comp.protocols.tcp-ip
Subject:   Re: Need FTP protocol help

In article <1992Oct22.145541.12851@mr.med.ge.com>
allen@mr.med.ge.com (Phil Allen 4-6086 MRCE) writes:
>
>I need to get a copy of the FTP protocol rfcs but do not have
>FTP at my site.  Would someone be kind enough to email me a 
>copy of rfc959.txt and rfc1123.txt. 
>

RFCs and other documents are available by email directly from the 
NIC Mail Server.  Here is how to get them:

NIC Mail Services                                          Feb  1992

   This is an automated service provided by the DDN Network Information
Center.  It allows access to NIC documents and information via ordinary
electronic mail.  This is especially useful for people who do not have
access to the NIC via a direct Internet link, such as BITNET, CSNET
and UUCP sites. 

   To use the mail service, send a mail message to SERVICE@NIC.DDN.MIL.
In the SUBJECT field, request the type of service you wish followed by
any needed arguments.  The message body is normally ignored; however, if the
SUBJECT field is empty, the first line of the message body will be used
as the request.  Large files will be broken into smaller separate messages.
However, a few files are too large to be sent through the mail system.
Requests are processed automatically once a day.

The following services are currently available:

HELP            This message; a list of current services.
HOST xxx        Returns information about host xxx.  WHOIS xxx can
                also be used to get more details about a host.
IEN nnn         nnn is the IEN number or the word INDEX.
IETF xxx        xxx is a file name
INDEX		Returns the master list of available index files.
INTERNET-DRAFTS xxx	xxx is a file name
NETINFO xxx     xxx is a file name or the word INDEX.
RFC nnn         nnn is the RFC number or the word INDEX.
RFC nnn.PS      to retrieve an available Postscript RFC. Check RFC INDEX for
                form of RFC. 
FYI nnn         nnn is the FYI number or the word INDEX.
FYI nnn.PS      to retrieve postscript versions of FYI files.
SEND xxx        xxx is a fully specified file name.
WHOIS xxx       Returns information about xxx from the WHOIS service.
                Use "WHOIS HELP" for information on how to use WHOIS.

Example SUBJECT lines:

    HELP
    RFC 822
    RFC INDEX
    RFC 1119.PS
    FYI 1
    IETF 1IETF-DESCRIPTION.TXT
    INTERNET-DRAFTS 1ID-ABSTRACTS.TXT
    NETINFO DOMAIN-TEMPLATE.TXT
    SEND RFC: RFC-BY-AUTHOR.TXT
    SEND IETF/1WG-SUMMARY.TXT
    SEND INTERNET-DRAFTS/DRAFT-IETF-NETDATA-NETDATA-00.TXT
    HOST DIIS
    WHOIS KOSTERS, MARK

Send comments or suggestions to SUGGESTIONS@NIC.DDN.MIL.  Send questions
and bug reports to BUG-SERVICE@NIC.DDN.MIL.

-- 
Bill Warner						(317)494-1787
General Consulting					bwarner@cc.purdue.edu
Purdue University Computing Center			bwarner@PURCCVM.BITNET

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Sun, 25 Oct 92 10:54:46 GMT
From:      clyde@hitech.com.au (Clyde Smith-Stubbs)
To:        comp.protocols.tcp-ip
Subject:   Re: AMERICANS and Texas kangaroos.us

fitz@wang.com (Tom Fitzgerald) writes:

>And I'm going to laugh myself sick reading followups
>from you Aussies protesting about how much work it would be, and how all
>your mailing addresses would have to change, and root domains were assigned
>before anyone really thought about interplanetary net links, and we were
>here first, anyway....

Well, in the views of some American net.administrators, we aren't here now
anyway. I quote from some recent e-mail communications with the admininistrator
of a certain US Internet site:

   [Referring to our registered domain, hitech.com.AU]

   >First of all, using hitech is a bit risky and maybe improper given
   >that as far as I can tell hitech is a registered domain of a company in
   >Los Angeles.
 
   >As far as I know there is no root server for .au . Is hitech.com.au something
   >you made up?
 
   >Lastly I would encourage you to register a domain name sometime in the future.

Remember this is an internet site, with access to nslookup!


--
 Clyde Smith-Stubbs       | HI-TECH Software,       | Voice: +61 7 300 5011
 clyde@hitech.com.au      | P.O. Box 103, Alderley, | Fax:   +61 7 300 5246
 ...!nwnexus!hitech!clyde | QLD, 4051, AUSTRALIA.   | BBS:   +61 7 300 5235
 HI-TECH Software: C Compilers for all manner of machines

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Sun, 25 Oct 1992 15:09:03 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Changing from Class C to Class B

karrer@bernina.ethz.ch (Andreas Karrer) writes:
}barmar@think.com (Barry Margolin) writes:
}>If all TCP/IP implementations were done correctly, it wouldn't make much
}>difference.  However, there are some implementations that don't handle
}>subnet masks that don't end on a byte boundary.  
 
}This was probably true some four or five years ago. We have a Class B net
}with a 255.255.255.192 netmask; and i'd have yet to see a machine that
}cannot handle our 10-bit-subnet 6-bit-host-part scheme.
 
}Only very few or only very stupid people actually want more than 62
}hosts on one subnet.

    Well, I hope we are "very few", rather than "very stupid".  In looking
    through our namedb I found subnets of: 114, 75, 80, 81, 100, 137, and
    240 hosts (and this was just looking at 129.186.1.x through 129.186.23.x,
    I got tired of looking after that).  We also have subnets with a single
    machine.  It all depends on what that/those machine(s) are and it's/their
    use.  Also your logical setup does not necessarily map exactly to your
    physical setup.

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 92 19:40:11 GMT
From:      benjamin-goldsteen@uokhsc.edu (Benjamin Z. Goldsteen)
To:        comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.unix.aix
Subject:   Re: help with PC-NFS from Sun

geoff@tyger.Eng.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:

>Quoth benjamin-goldsteen@uokhsc.edu (Benjamin Z. Goldsteen) (in <1992Oct24.041839.18999@constellation.ecn.uoknor.edu>):
>#     Sun PC-NFS has a pretty junky printing model (IMHO).  It mounts a
>#spool drive for each printer behind the scenes (LPT1 = T, LPT2 = U,
>#etc).  It copies your file to the the NFS drive and then it sends a
>#request to the PCNFSd to print the file in spool area.  I can't see a PC
>#running DOS handling these requests.  I am going to try to use 386BSD to
>#handle this, but I don't see why printing should even require a
>#386...what was wrong with the lpr stuff? (besides the fact that it
>#wasn't portable...though common enough that AT&T has support for it in
>#SVR4). 


>You may find it "junky", but this is an extremely thorny problem
>area. There are DOS reentrancy issues to deal with, and any
>mechanism has to be able to cope with the possibility of a low-level
>64K byte write which is mapped into 64K individual BIOS calls at
>a time when DOS is not re-entrant! Do you really want 64K buffers,
>or full-blown TCP operations taking place in this context? The only
>fastpath that we can really control is the NFS write, so that's
>what we use.

     My apologies to Mr. Arnold; I should have said, "it is a junky
printing model, but an effective one for DOS."

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Oct 92 10:50:14 GMT
From:      rvdm@oce.nl (Ruurd van der Meer)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Looking for box talking TCP/IP for Token Ring to connect printer

We are looking for a "printer"-box talking TCP/IP which can be connected 
directly to a Token Ring environment, a la "Intel Netport" or Castelles
"LanPress". 

Does anybody know if there is such a product.

Please send your remarks to :

pen@oce.nl
---------------------------------------------------------------------------
piet engels                       |  tel.  : 077-592536
oce nederland bv                  |
communicatie & netwerken          |  fax.  : 077 - 592536
postbus 101                       |
5900 ma  venlo                    |  email : pen@cnn@oce.nl
---------------------------------------------------------------------------

      ###########################################################
      #  This note does not necessarily represent the position  #
      #     of Oce-Nederland B.V. Therefore no liability or     #
      #      responsibility for whatever will be accepted.      #
      ###########################################################

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Oct 1992 12:49:39 GMT
From:      doug@happy.dab.ge.com (Doug Hughes)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   RE: Now you see it now you don't


THanks to all who responded to my question.  It appears that the
answer was that gcc < 2 and CC have different conventions for
structure passing which are not compatible.  I have changed to
gcc 2.2.2 and the problem is no more.
		Doug
--
_____________________________________________________________
Doug Hughes
Software Developer - GE Aerospace (M&DSO), Valley Forge, PA
doug@happy.vf.ge.com	or	hughes@sde.mdso.vf.ge.com

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Oct 92 18:19:39 EST
From:      cliff@engin.umich.edu (clifford  kaminsky)
To:        comp.protocols.tcp-ip
Subject:   NNTP server

Hi there. Can someone please give me the name of an NNTP server that
I can connect to which carries the alt.binaries.pictures.erotica
newsgroup?

Don't look so shocked.  You know it's the most popular newsgroup.

-Cliff


-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Oct 1992 14:28:44 GMT
From:      vharten@prl.philips.nl (Peter R. van Harten)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   PKTMUX 1.2 Slooows down Windows 3.1/PC-NFS 4.0a

Hello,

I'm trying to use the Trumpet newsreader 1.05g together with PC-NFS 4.0a
under Windows 3.1 using PKTMUX, but when I have minimized Trumpet and try to
run an application under windows, it will load much slower than without 
Trumpet active. I've got the same problem with WinQVT 2.7 alongside PC-NFS. 
I hoped this problem was solved in PKTMUX 1.2 but i noticed no difference. 
Maybe someone can help me?

System: Dell 450 SE with 3C507 using packet driver + PKTD.SYS (Philips 
                         P3348SX with D-Link DE-200+ has same problem )

Thanks in advance, Peter van Harten
------------------------------------------------------------------ 
P.R. van Harten                      Philips Research Laboratories
tel. +31 40 742209                   Prof. Holstlaan 4
fax. +31 40 744810                   5656 AA  Eindhoven
email: vharten@prl.philips.nl        The Netherlands



-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 92 14:40:00 GMT
From:      bvs@nrc.com (Bill Versteeg)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple addresses on one interface?

The need to have many IP addresses on one interface is actaully quite common.
Terminal servers do it to support more than one host 
in the "milking machine"  mode.  Routers (and some hosts) do it to
allow one to have more than one IP network on a single cable.
Certain (brain-dead) SNMP proxy agents do it to field SNMP 
requests for devices that do not speak SNMP (NOTE- this is a bad idea, but some 
people used to do it anyway).

The modifications to support multiple IP addresses per
interface are quite straightforward. I have done it for B43 Tahoe
and a couple of proprietary implementations. The IP receive and
transmit code is very easy to modify. Don't forget to
modify the arp code to know about the multiple addresses.



Bill VerSteeg

bvs@ver.com


-- 
Bill VerSteeg
VerSteeg CodeWorks
bvs@nrc.com

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 92 15:44:20 GMT
From:      esiewick@pbs.org
To:        comp.protocols.tcp-ip
Subject:   Looking for RFC 1055 (SLIP)

Hi,

I'm looking for a copy of RFC 1055 (SLIP).  Does anybody have the file
or know where to look for it on the Internet?

Thank you,

Edward Siewick

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Oct 92 17:15:56 GMT
From:      allen@mr.med.ge.com (Phil Allen 4-6086 MRCE)
To:        comp.protocols.tcp-ip
Subject:   FTP client source


I would like to thank everyone who supplied information on getting
the RFC data I needed on FTP.

Now the next obvious question.  Is there anywhere I can get public
domain, gnu, etc. source for a FTP client? (I learn so much better
by example ;-) ).  

Thanks

-----------------------------------------------------------------
Phil Allen                
allen@mr.med.ge.com

Emacs is not an editor it is a lifestyle.
-----------------------------------------------------------------

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 92 18:21:10 GMT
From:      mark@verdix.com (Mark Lundquist)
To:        comp.protocols.tcp-ip
Subject:   4.3bsd keepalive timer

Maybe someone can help me with this question...

Does anybody know why the 4.3BSD TCP implementation sets the keepalive
timer on connections that are being established?  Then in the
'slowtimo' code there's a little something that sends a reset if the
keepalive timer expires on an embryionic connection.

(There's a special keepalive interval for this, KEEP_INIT in
tcp_timer.h).

I don't get it.  Why would you want a keepalive timer to abort a
connection that is in the process of being set up?

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Oct 1992 20:03:40 GMT
From:      fff@microplex.com (Fred Fierling)
To:        comp.dcom.servers,comp.protocols.tcp-ip
Subject:   Re: How to TCP/IP print to a comm server (Was: Re: Annex 3 and lpd)

In article <1992Oct19.102528.3863@arizona.edu> Leonard@Arizona.EDU writes:

>A nice (but not essential) feature that the comm server could implement 
>(a feature found in MultiNet) would be to maintain a per-TCP-port queue 
>of connections to service.  (This queue should be of finite depth, say 3 to 
>10 connections.)  If there is already data flowing to a port, then the comm 
>server could accept incoming TCP connects to that port, but hold off on 
>accepting data from that connection.  When the active connection closes,
>the comm server would then begin accepting data on the next TCP connection
>to service.  (If the TCP connection queue fills up, then of course the comm
>server would refuse new TCP connects.)

This is exactly what our M200 TCP/IP printer adapter does.  In addition to
providing a subset of LPD functionality (as befits a diskless host) it
services raw TCP connections on a first come first serve basis. It works
quite well. :-)
-- 
Fred Fierling    fff@microplex.com      Tel: 604 875-1461   Fax: 604 875-9029
Microplex Systems Ltd   265 East 1st Avenue   Vancouver, BC  V5T 1A7,  Canada

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Oct 92 20:34:30 GMT
From:      jharvey@csulx.weber.edu (Just me)
To:        comp.protocols.tcp-ip
Subject:   Internet Q & A

     Dear readers,
 
     My name is Justin Harvey and I am the TCP/IP Project Coordinator
for the City & Borough of Juneau here in Alaska.  With only one Internet 
supplier being the University limiting connections and accounts to faculty,
staff or students, I have found a potential network market niche.  I'd
like to purchase a Unix/OS computer being a 486 or actual Unix machine an
setup dialin lines with SLIP connections available as well.  
     
     I have spoken with UUNET in Virginia and they have high prices for what
I would like to do, and that is to get a supplier of IP in the lower 48 and
get it into Juneau.  UUNET offers a 56k line for $1,000 a month.  A 56k lin
can support up to 50 users ftping and telneting.  I'm not sure I need that 
large a connection.  What kind of connection do I need for 25-35 people
and what would be the best way to transport it to Juneau?  Leased line?
Through which long distance company?  How fast?  Who would I connect into
at the other end?
 
     I would appreciate the your help and advice on these issues, as I am
very confused.  If you'd like, I would also appreciate your opinion on which
Unix multi-user OS I could purchase for a 486 platform that would support
TCP/IP, X-windows, user accounting etc. etc, the whole bit.
 
     Thanks,
 
     Justin Harvey
     Northnet
     6734-a Marguerite
     Juneau, AK 99801
     jharvey@csulx.weber.edu 

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 92 21:14:58 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: 4.3bsd keepalive timer

mark@verdix.com (Mark Lundquist) writes:

>Maybe someone can help me with this question...
 
>Does anybody know why the 4.3BSD TCP implementation sets the keepalive
>timer on connections that are being established?  Then in the
>'slowtimo' code there's a little something that sends a reset if the
>keepalive timer expires on an embryionic connection.
 
>(There's a special keepalive interval for this, KEEP_INIT in
>tcp_timer.h).
 
>I don't get it.  Why would you want a keepalive timer to abort a
>connection that is in the process of being set up?

Is the keepalive timer set during a inbound connection establishment or   
outbound connection establishment?   

                                      Randy

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 92 04:09:35 GMT
From:      ignasiak@netsun..cl.msu.edu (Todd Ignasiak)
To:        comp.protocols.tcp-ip
Subject:   Collision Detection in UNIX

I am trying to write a small network performance monitor, and one thing
I wanted to check was the amount of collisions on our network at different
times and under different conditions.   I have been checking around, but have
been unable to find much information about collision detection under SunOS.
So, if some kind soul could point me in the right direction, maybe a magazine
article, good book, or even source code.  I'd really appreciate it.

Thanks,

Todd Ignasiak
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Todd Ignasiak		   Network Services  	       Michigan State University
ignasiak@netsun.cl.msu.edu						  (OS/2)

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Oct 1992 04:15:17 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "Will do TCP/IP for clues" Ranum)
To:        comp.sys.sun.misc,comp.sys.sun.apps,comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Please read, RPC related ...

>	I am thinking of using SUN-RPC for developing a
>network application. I know about SUN-RPC well and have done a prototype
>using it and XDR. I am not sure if I am can get any performance
>benefit by directly using the XDR layer, bypassing the RPC. Of
>course this would mean a bit more coding, but is this justified ?

	This is what is known as "pre optimizing" and is generally
considered to be a bad idea.

	In short, what you are saying is "I think that if I take
all this time to develop this code, I will get it right on the
first try, so that it outperforms the existing code." There are
always times when this is correct, but you have to keep in mind
what your tradeoffs are. Basically, you're betting your effort
that you'll do better than the existing RPC library. Now - why
is this a loss? It's a loss because there's really *NO* reason
to make that gamble. Why not write your code to use RPC, and
then see how it runs? If it's too slow, then you'll at least
know where the bottlenecks in your application are, and then
you can apply your coding skills where you know they do some
good.

	Another way of looking at it is that if you wind up
essentially re-writing RPC, you've increased the size of the
code you need to maintain, and can no longer take advantage
of any improvements that someone may make to the RPC library.
This is a drag. Many vendors seem to think this is smart and
call it "value added" - real programmers call it "shit stupid."

	This issue of pre-optimizing is one of the most
common mistakes I see destroying otherwise reasonable code,
and making projects late. For some reason, basic computer
science courses neglect to teach the virtues of laziness,
by encouraging students to write their own class libraries,
heap managers, etc, etc, etc. This is a terrible mistake, but
then what do you want for your $20,000/year anyhow?

	Another issue in this case, specific to RPC, is that
the RPC library (last time I looked) is actually pretty
darn nicely layered. There are fairly good mechanisms down
inside for inserting application specific hacks (without
touching the library source) - surely much easier than
rolling your own.

	Before you make any kind of major design decision
like the one you're embarking on, you should do some rough
back-of-an-envelope estimates. Always, first, and foremost,
figure out what your program is going to spend MOST of its
time doing. Is RPC it? If not, then worry about getting
what it's spending most of its time doing fast and let
the RPC wait 'till later! If RPC is it, then write some
test harnesses and see how RPC performs for the type of
programming you're doing. If you're doing big streams,
does a TCP work better? If you're really doing something
like a function call, is RPC adequate?

	In making a major design decision such as deciding
to write your own transaction layer, think of it in terms
of what the decision costs to you in code effort. If it
will take you 3 weeks of coding to write your own RPC,
will that 3 weeks make your program that much faster than
using RPC and then tuning the bottlenecks? Experience
leads me to predict it won't but your actual mileage may
vary.

	Think before you cut. Good Luck!

mjr.
-- 
	You can't fix stupidity with software.
						-notebooks of a heretic

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 92 05:08:06 GMT
From:      ssanbeg@visual.spk.wa.us (Scott Sanbeg)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: Changing from Class C to Class B

In article <1992Oct21.174734.3874@arizona.edu> Leonard@Arizona.EDU writes:
>...
>of an Internet-based Local Network_ (in [networks.internet]tcp-ip-admin.doc
>on Arizona.EDU, for example) and also Doug Comer's _Internetworking with
>TCP/IP_, 2nd Ed, Vol. I (which I would offer you more info on but my copy always
>seems to be out on loan.)

Internetworking with TCP/IP Volume I, II and III, by Comer. -- 2nd ed.
ISBN 0-13-468505-9 (Vol. I)  (C) 1991 by Prentice-Hall, Inc. N.J.

>|>   If it ain't broke, break it.

'Tis a fact.
Scott

 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Scott Sanbeg     UNIX Systems Administrator       (509)535-2561
ssanbeg@visual.spk.wa.us (or) ...!uunet!tau-ceti!visual!ssanbeg

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 1992 08:06:41 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Changing from Class C to Class B

In article <1992Oct24.165829.3243@bernina.ethz.ch> karrer@bernina.ethz.ch (Andreas Karrer) writes:
>barmar@think.com (Barry Margolin) writes:
>>If all TCP/IP implementations were done correctly, it wouldn't make much
>>difference.  However, there are some implementations that don't handle
>>subnet masks that don't end on a byte boundary.  
>
>Please name them.

I don't know them offhand.  However, this question comes up every couple of
months in this group, and a few people always manage to point out problems
they've had.

Another problem with non-octet subnets is with reverse resolution, i.e. the
IN-ADDR.ARPA domain.  If your subnets correspond to organizational
boundaries, and you want to delegate name management to organizations, then
you'll need to be able to delegate zones within your xxx.yyy.IN-ADDR.ARPA
domain, and this can only be done on octet boudaries.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Oct 1992 14:51:59 GMT
From:      koelman@cuby.stc.nl (Ton Koelman)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Transport Provider Interface for UNIX STREAMS


Can anybody please point me to the:
    Transport Provider Interface for UNIX STREAMS

This defines the STREAMS based interface between
the TLI and a Transport Provider.
Since I'm working on the latter I really
need the TPI (is that the official name?) spec

thanks

--
Ton Koelman   e-mail: koelman@stc.nato.int (NeXT Mail Welcome!)
SHAPE Technical Centre, P.O. Box 174, 2501 CD  The Hague
The Netherlands  (voice: 31-70-3142429, fax: 31-70-3142111)

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 92 15:15:23 GMT
From:      martelli@cadlab.sublink.org (Alex Martelli)
To:        comp.protocols.tcp-ip
Subject:   Re: AMERICANS and Texas kangaroos.us

dee@ranger.enet.dec.com (Donald E. Eastlake, III) writes:
	...
:specific.  Why do all these organizations in other countries insist on
                ^^^
:being chauvinistic and registering under their country code instead of
:"edu" for educational, "com" for commerical, "org" for non-profit,
:"net" for network management, or "int" for international?  I'm

Please note that not ALL of us are that chauvinistic!  The .sublink.org
domain, for example, is currently located within Italy, but it's properly
registered under the toplevel .ORG domain for nonprofit organizations
(then I get lots of mail from US people asking why my .sig gives Italian
address and phones while my domain-address is "in a U.S. domain", but
that's maybe OTHER people being chauvinistic, no?-).
-- 
Email: martelli@cadlab.sublink.org                   Phone: ++39 (51) 6130360
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: ++39 (51) 6130294 

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 92 15:27:43 GMT
From:      martelli@cadlab.sublink.org (Alex Martelli)
To:        comp.protocols.tcp-ip
Subject:   Re: AMERICANS and Texas kangaroos.us

kre@cs.mu.oz.au (Robert Elz) writes:
	...
:But apart from that, and for good reasons, registering under
:country domains is often much faster that registering in the
:TLD's, with much less bureaucracy 

Not in Italy it isn't!  If you aren't a University or other
governmental site, it seems, you can only have a .IT domain
address if you buy your connection services from some privileged
supplier who itself has a domain below .IT (I only know of
IUnet, the Italian Unix Users group, but maybe there are others),
and in turn said supplier may pratice whatever commercial policy
it will (such as ONLY accepting "leaf" sites under it and not
sites who want to further subdivide mail/news flow via UUCP).

Which is why, besides .sublink.org, you see such domain addresses
as nervous.com, and so on, for small outfits in Italy - MUCH
cheaper and faster to pay for direct connection to some U.S.A.
MX site via transatlantic UUCP with Telebit modems, than to
get entangled in the endless mire of Italian bureaucracy, or
pay through the nose for the kind of all-sorts-of-strings-attached
"service" you might, or might not, get (but WILL have to pay
for anyway) through a supplier allowed to bestow on you the
"supreme" .IT suffix...:-)
-- 
Email: martelli@cadlab.sublink.org                   Phone: ++39 (51) 6130360
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: ++39 (51) 6130294 

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 92 15:34:04 GMT
From:      martelli@cadlab.sublink.org (Alex Martelli)
To:        comp.protocols.tcp-ip
Subject:   Re: AMERICANS and Texas kangaroos.us

dee@ranger.enet.dec.com (Donald E. Eastlake, III) writes:
	...
:PCs  :-).   Seriously, you are correct.  There should be a .prs top
:level domain for personal computers and the like.  It would be pretty
:artificial to stick them into .org or something.

What about .FAM for FAMily instead?  Hey, the meager old 386 box I run
Unix on at home is a FAMILY computer, not a personal one, and it does
have 3 or 4 of us on at once often (although my soon-to-be-8-years-old
daughter prefers doodling to e-mail, as she doesn't feel to familiar
with English yet:-) through terminals (hmm, are we an .ORG'anization
instead...?  I do put "Premiata Famiglia Martelli & Figli" in the
Organization: header for posts from home:-).
-- 
Email: martelli@cadlab.sublink.org                   Phone: ++39 (51) 6130360
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: ++39 (51) 6130294 

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 92 15:39:24 GMT
From:      mark@verdix.com (Mark Lundquist)
To:        comp.protocols.tcp-ip
Subject:   Re: 4.3bsd keepalive timer

In article <rturner.720134098@imagen> rturner@imagen.com (Randy Turner) writes:
>mark@verdix.com (Mark Lundquist) writes:
>
>>
[[all of my question deleted, because my stupid-ass mailer rejects
  articles with "more lines of included text than new text" &$%^&$^!]]

>Is the keepalive timer set during a inbound connection establishment or   
>outbound connection establishment?   
>
>                                      Randy

It's
set
for
both
inbound
and
outbound
connection
establishment.

*sheesh*...

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Oct 92 18:31:36 GMT
From:      larry@turing.abbott.com (Larry Pajakowski)
To:        comp.protocols.tcp-ip,comp.protocols.appletalk
Subject:   appletalk over FDDI, rfc, ietf's, papers, references ??

Perhaps someone can help.

We heard, and are trying to get some specifics, that there was an internet
document (maybe mailing list) which suggests the best way to to apple talk
over FDDI is by encapsulating it in ip packets rather than using ethertalk
directly.  This may be the result of the 802.3 error in the ethertalk header
which was discussed a year or so ago.

If anyone has any insight to any documents or mailing lists or perhaps who I
might contact I would appreciate your help.  Our Apple MAC population is
growing at a rapid rate and we are attempting to decide how to deal with
this in some sort of controlled manner rather than patching problems on the
fly.  Currently we use only ethertalk.


TNX

Larry Pajakowski
larry@turing.abbott.com
1-708-937-1153

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Oct 1992 19:01:19 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   5250 Emulator


In article <1992Oct23.145618.18084@magnus.acs.ohio-state.edu> drichard@magnus.acs.ohio-state.edu writes:

>Does anyone know of a shareware 5250 emulator for DOS that will use telnet and> 
>run on an ethernet card instead of a twin-axial adapter?  I am mainly looking 
>-- 
> Darren Richardson

I have a similar requirement for a client.  They have an AS/400, IBM is
suggesting they should use "PC Support", which I believe is a 5250 emulator
running over TCP/IP.  It runs in DOS and can support Ethernet and Token Ring
adapters.

Does anyone know whether this is the best solution?   (yes, I know, I didn't
state the problem....  it is to allow 30 to 40 Ethernet connected PCs
on the same site, to access the AS/400 in normal terminal mode).

What is the AS/400's TCP/IP like?  Does it support all the other
protocols and functions one can expect from a normal UNIX system?



Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      |         (OSI & GOSIP specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Oct 1992 19:07:50 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Changing from Class C to Class B


In article <1992Oct24.165829.3243@bernina.ethz.ch> karrer@bernina.ethz.ch writes:

>
>Only very few or only very stupid people actually want more than 62
>hosts on one subnet.
>
>+-----------
>  Andi Karrer, Communication Systems, ETH Zuerich, Switzerland
>  karrer@bernina.ethz.ch    - Objects in mirror are closer than they appear

Strongly disagree!!!    Sure, if "host" is intended to mean "minicomputer"
like in the olden days....  but now, a typical site LAN could have 
three or four UNIX boxes,  hundreds of PCs, several bridges, tens of 
terminal servers, several intelligent 10baseT hubs, etc.
(all managed by an SNMP network manager), without congesting the LAN.  
As each of these needs an IP address (i.e is technically a "host")  it 
is quite feasible to have hundreds (more than 253) of hosts on a subnet...


Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      |         (OSI & GOSIP specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 92 20:34:58 GMT
From:      rri!tim@vtserf.cc.vt.edu (Tim Buck)
To:        comp.sys.novell,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Novell/Unix bridge software?

I'm looking for a package to make an Interactive Unix box a client on a 
Novell network.  Can somebody name a few and give me some pointers to info
on them?

Timothy Buck   --   rri!tim@vtserf.cc.vt.edu OR timbuck@borg.lib.vt.edu
 Recognition Research, Inc. (703) 231-6500	++ NeXTmail accepted ++
------------------------------------------------------------------------
 Hate Blacksburg's weather? Wait an hour.  Hate the season? Wait a day.  

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 92 21:00:42 GMT
From:      ko@toadflax.UCDavis.EDU (Chenk Wang Ko)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   TCPdump on NeXT

HI,

     Does anyone have a TCPdump which can capture all the packet from
the ethernet, (or somethings similiar) which can run on NeXT OS. 
Please send me e-mail if you has any information about that.

Many Thanks

Calvin
ko@cs.ucdavis.edu

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 92 21:11:57 GMT
From:      paul@tantrum.csir.co.za (Paul Nash)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   LPD for DOS found!


A while back, in <1992Oct19.144410.6627@nuustak.csir.co.za> I asked:

>Does anyone know of an LPD for DOS?  

I got lots and lots of responses, which pointed me at:

! try tacky.cs.olemiss.edu (130.74.96.13) in ~ftp/pub/lpd.

! FTP make a DOS LPD. It supports Multiple printers and will run on

! PC-NFS includes a TSR LPD of over 100k, Very

! 40 meg drive running OS/2 and PC/TCP for OS2. This box is now
! our main printer server and can also run versions of routed,

! Check tacky.cs.olemiss.edu in pub/lpd. I'd suggest the NOS package.

! There are two that I am aware of. One is a bootpd/lpd combo,
! based on the wattcp package. Ka9q/NOS is rumoured to do it
! too. FTP Inc do a commercial one. I dunno where the free stuff is

! We have use the PC-LPD package from FTP Associates here and it worked
! fine.  (Still in use as a matter of fact.)

! Check the lpd in tacky.cs.olemiss.edu in pub/lpd (I think, check the

I have not tried any of these yet, but will post the results once I
have -- this will probably take a few more weeks, though.

A few kind souls also pointed me at Charon (which I already wot of), 
which will give an LPD interface into Novell print queues.  This is
great if you want to use Novell aswell :-).  Charon will also gate
RFC822 mail from the LAN to SMTP, and is widely used with Pegasus
Mail.

! Also charon (charon40.zip) on many archive sites (simtel20,
! wuarchive.wustl.edu, oak.oakland.edu).

Those who were kind enought to respond were, in no special order:

>> alan@alans.scf.lmsc.lockheed.com
>> steven@unipalm.co.uk  (Steven Vincent)
>> tom@piassun1.joanneum.ac.at (Tom Leitner)
>> Alejandro <rivero@cc.unizar.es>
>> chrisp@slc.com (Chris Pinkham)
>> tom@piassun1.joanneum.ac.at (Tom Leitner)
>> bill@cs.uofs.edu  (Bill Gunshannon)
>> cslee@pds (Lee Chee Siong)
>> catone@dmark.wharton.upenn.edu (Tony Catone)
>> paul@frcs.alt.za (Paul Nash)
>> frdeinl@afterlife.ncsc.mil (Fred Deinlein)

Thanks, all!
--
 ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---
 Paul Nash                                   (voice) +27-12-8413050
 Network Services, CSIR Infotek                (fax) +27-12-8414109
 PO Box 395, Pretoria, 0001 South Africa

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 92 21:19:59 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: 4.3bsd keepalive timer

mark@verdix.com (Mark Lundquist) writes:

>In article <rturner.720134098@imagen> rturner@imagen.com (Randy Turner) writes:
>>mark@verdix.com (Mark Lundquist) writes:
>>
>>>
>[[all of my question deleted, because my stupid-ass mailer rejects
>  articles with "more lines of included text than new text" &$%^&$^!]]
 
>>Is the keepalive timer set during a inbound connection establishment or   
>>outbound connection establishment?   
>>
>>                                      Randy
 
>It's
>set
>for
>both
>inbound
>and
>outbound
>connection
>establishment.
 
>*sheesh*...

Under 4.3BSD the keepalive timer is set to 45 seconds for embryonic 
connections so that connection establishment that fails does not tie up
network resources...(TCB allocation,mbufs, etc...).  This is because, like
TCP acknowledgement packets, the 3-way handshake establishment is not using
last-ack packet retransmissions and time outs.  Connection establishment is
a special case for TCP so other methods have to be used to ensure that 
connections  are established in a timely fashion.  The keepalive timer
expiration code I believe checks the current connection state and if it is
SYN-SENT or SYN-RECVD, it will reset the connection. (In other words, I
don't think the keepalive packet (ACK packet) is actually sent out...but I
could be wrong about that...)

			Randy

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 92 23:31:47 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Raw socket programming


  I am trying to find a reference on how to do raw socket programming
under SUNOS 4.1.1.  What I would like to do is open a socket to the ethernet
and turn on promiscuous mode and trap certain types of packets.  I have root
privilege so I should be able to access the network at this level.  Does 
anyone know where I can obtain an example of how to do this OR could someone
shed some light on the appropriate steps for doing this??

                                        Thanks in advance,
							Randy Turner

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 92 01:02:33 GMT
From:      ric@updike.sri.com (Richard Steinberger)
To:        comp.protocols.tcp-ip
Subject:   Need help with write to a socket


	I have been porting a TCP/IP client from C to C++ on a Sun
running SunOS 4.1.2.  The server ported fine but there is an annoying
bug with the client:  When I write to a socket using code I lifted
from Stevens' Netwoking book:

	nwritten = write(fd, ptr, nleft);

where fd = socket fd, ptr = pointer to a C string, and nleft is the # of bytes,

the write doesn't seem to happen, although there is a valid return from the
write statement.  Only when I type ^C to force an exit does the server,
which is logging incoming messages, register that it received the string.
In other words, it's as if the program exit process forces a flush of the
socket that had been taking place with each write when it was running under
C.  This is hard for me to understand.  Does anyone have any ideas?  Thanks
in advance.

ric steinberger
ric@updike.sri.com

[BTW - The server also uses the function writen() from which the above line
is lifted, and it works fine.]

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Oct 1992 02:46:42 GMT
From:      mju@mudos.ann-arbor.mi.us (Marc Unangst)
To:        news.admin,alt.internet.access.wanted,news.newsites,news.config,comp.protocols.tcp-ip
Subject:   Re: UUCP newss access wanted over Telnet (default port)

In article <bwrmtp.8z9@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
>Mr Bradley seems to be looking for a server on port 23 that doesn't try to
>use any real telnet protocol messages; and I don't know of such a thing.

It's pretty easy, actually, assuming you have a BSD-like TCP/IP.  The
servers that run on various ports are all configured in
/etc/inetd.conf.  Nowhere is it written that /usr/etc/in.telnetd has
to run on port 23.  (Well, okay, it's probably written in an RFC
somewhere.)  Feel free to run /usr/etc/in.uucpd or something similar
on port 23.  (With the realization, of course, that you will probably
confuse the hell out of anyone who happens to telnet to your machine.)

This discussion should probably be moved to comp.protocols.tcp-ip.

-- 
Marc Unangst, N8VRH         | "There are two ways to solve this problem:
mju@mudos.ann-arbor.mi.us   | the hard way, and the easy way.  Let's start
                            | with the hard way."
                            |   - W. Scheider, from a Physics lecture

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Oct 1992 04:34:05 GMT
From:      djmolny@evolving.com (DJ Molny)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Detecting Dropped Sockets (Why is this hard on PC's?)

In the last two months, I've worked on three different projects interfacing
PC's to a UNIX server (IBM RS/6000) via TCP/IP.  Two projects used Novell
LAN Workplace for DOS, and one used FTP's TCP/IP package.

In all three cases, it seems that the RS/6000 doesn't detect a "rude"
disconnect (e.g. powering off the PC).  The only workaround I've found
is to transmit a "heartbeat" periodically and close the socket if the
transmit fails.

Two questions:

	- Why is this a problem?  UNIX-to-UNIX connections, Xstations,
	  mainframes, etc. all support a clean tear-down.  Why not PC's?

	- Is there a less kludgy workaround?  The heartbeat logic works
	  OK, but it screws up some otherwise clean applications.

Thanks.

-----------------------------------------------------------------------------
DJ Molny
djmolny@evolving.com		"It's supposed to be automatic, but
Evolving Systems, Inc.             actually you have to push this button."
-- 

DJ Molny
djmolny@evolving.com
Evolving Systems, Inc.

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 92 11:10:31
From:      zpope@osf.org (William Pope)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: Transport Provider Interface for UNIX STREAMS


In article <Bwu048.73F@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
>In article <1992Oct27.145159.7217@stc.nato.int> koelman@stc.nato.int writes:
>>
>>Can anybody please point me to the:
>>    Transport Provider Interface for UNIX STREAMS
>>
>>This defines the STREAMS based interface between
>>the TLI and a Transport Provider.
>>Since I'm working on the latter I really
>>need the TPI (is that the official name?) spec
>
>  Never heard of a TPI or a TPI spec.  It ain't in the SVID 2 Issue 2,
>which has both the TLI and STREAMS definitions.

The TPI definition is only available from USL (perhaps AT&T too).  I've only
seen it in the SysV.3 documentation that comes with a source license.  It
was not in a spec by itself but was part of some other document, whose name
I can't seem to dredge out of the wreckage of my memory.  The spec also had
information on the internals of RFS and NFS, "Network Services support
guide" or something like that.

The spec does exist, I've worked from it in the past.
Hope this helps,
=bill
--
============================================================================
William Z. Pope                                     Phone: +1 (617) 621-8889 
Open Software Foundation                              Fax: +1 (617) 621-0584
11 Cambridge Center                                     Email: zpope@osf.org
Cambridge, MA  02142                             OSF DME Integration Project




-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 92 06:27:09 GMT
From:      romkey@asylum.UUCP (John Romkey)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Detecting Dropped Sockets (Why is this hard on PC's?)

djmolny@evolving.com (DJ Molny) writes:
>In the last two months, I've worked on three different projects interfacing
>PC's to a UNIX server (IBM RS/6000) via TCP/IP.  Two projects used Novell
>LAN Workplace for DOS, and one used FTP's TCP/IP package.
 
>In all three cases, it seems that the RS/6000 doesn't detect a "rude"
>disconnect (e.g. powering off the PC).  The only workaround I've found
>is to transmit a "heartbeat" periodically and close the socket if the
>transmit fails.
 
>Two questions:
 
>	- Why is this a problem?  UNIX-to-UNIX connections, Xstations,
>	  mainframes, etc. all support a clean tear-down.  Why not PC's?

There's a difference between, say, powering down a PC, and killing a process
on a UNIX box. Comparing powering down a PC and powering down a UNIX box would
be a much more accurate thing, and would likely lead to the same results.

When you power down the PC, there's *nothing* there anymore to respond to
packets. If the process on the other end sends data, it goes into the bit
bucket. It will get no response.

If you've killed a UNIX process, the UNIX TCP is still around. The next time
the other application sends data to it, the UNIX TCP can send a TCP reset
packet, indicating the connection is gone away. It's possible that some UNIX's
will also automatically initiate a graceful close when the process die - I'm
unsure about this.

The main difference is that when you kill a UNIX process, there's still
something there to do some talking. When you power off a PC, there's not.


4BSD's TCP has a notion of a "keepalive", which is handled at the TCP layer,
transparently to the process. TCP will periodically send out a keepalive
packet and if there's no response after too long, it will shut down the
connection.
-- 
	- john romkey	  ELF Communications	 romkey@ELF.com

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Oct 1992 10:14:38 GMT
From:      markus@edfd.uucp (Markus Gruenkorn (MAGIC))
To:        comp.mail.misc,comp.protocols.tcp-ip
Subject:   X400 mailing over TCP/IP to AS400's Office Vision ?


Our As400 has the TCP/IP implementation installed and Office Vision too.
With Office Vision X400 mailing is possible. Now we want communicate from a Unix X400 mailer PPP over TCP/IP to the AS400 to use the X400 features. At this point it is possible to  send and receive mail between the two systems with 
SMTP. Is there any chance to do X400 mailing between the unix-ws and AS400's office vision over TCP/IP. 
Any information would be appreciated.

-- 
------ < MAGIC > ------

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 92 11:36:05 GMT
From:      J.G.Bryan@bham.ac.uk (Graham Bryan)
To:        comp.protocols.tcp-ip
Subject:   archie

I'm thinking of writing an 'archie' client for our VM/CMS system. Does
anyone know of either

 (a) an existing VM/CMS archie client, or
 (b) where I can get the necessary protocol information to write
     the client myself.

+--------------------------------------------------------------------+
| Graham Bryan                      Voice:    (UK) 021-414-3990      |
| Systems Support Group             Fax:      (UK) 021-414-3952      |
| Computing Service (Elms Road),    Janet:    J.G.Bryan @ UK.AC.BHAM |
| The University of Birmingham,     Internet: J.G.Bryan @ bham.ac.uk |
| PO Box 363, Edgbaston,                                             |
| Birmingham (B15 2TT),                                              |
| England                                                            |
 +--------------------------------------------------------------------+

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Oct 1992 12:27:10 GMT
From:      stein@sionext.uio.no (Stein Onsrud)
To:        comp.protocols.tcp-ip
Subject:   Sharing of CD ROM

Our company resells CD ROM sharing solutions for IPX and netbios based  
networks. Is there anyone out there who knows of any CD ROM sharing system  
over TCPIP NFS ?

Stein Onsrud
SiO Data

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Oct 1992 12:31:19 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: Transport Provider Interface for UNIX STREAMS

In article <1992Oct27.145159.7217@stc.nato.int> koelman@stc.nato.int writes:
>
>Can anybody please point me to the:
>    Transport Provider Interface for UNIX STREAMS
>
>This defines the STREAMS based interface between
>the TLI and a Transport Provider.
>Since I'm working on the latter I really
>need the TPI (is that the official name?) spec

  Never heard of a TPI or a TPI spec.  It ain't in the SVID 2 Issue 2,
which has both the TLI and STREAMS definitions.


-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Oct 1992 15:48:11 GMT
From:      reg@regpcSanDiego.NCR.com (Reg Nielsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for RFC 1055 (SLIP)

In article <1992Oct26.104420.18562@pbs.org>, esiewick@pbs.org writes:
> 
> I'm looking for a copy of RFC 1055 (SLIP).  Does anybody have the file
> or know where to look for it on the Internet?
> 
> Thank you,
> 
> Edward Siewick
> 
At the USENIX LISA VI conference it was mentioned that the RFC can
be obtained on ftp.uu.net in the inet/rfc directory (rfc1055.Z)

-------------------------------------------------------------------------
						NCR Corporation
EMAIL Reg.Nielsen@SanDiegoCA.NCR.COM		Reg Nielsen MS#1250
PHONE 619-485-2479, FAX 619-485-3010		16550 West Bernardo Drive
						San Diego, CA 92127
-------------------------------------------------------------------------

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 92 16:41:14 GMT
From:      markb@spock.dis.cccd.edu (Mark Bixby)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for RFC 1055 (SLIP)

All RFCs are available via anonymous FTP from nic.ddn.mil.
-- 
Mark Bixby                         Internet: markb@spock.dis.cccd.edu
Coast Community College District   1370 Adams Avenue
District Information Services      Costa Mesa, CA, USA  92626
Technical Support                  (714) 432-5064
"You can tune a file system, but you can't tune a fish." - tunefs(1M)

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Oct 92 16:54:51 GMT
From:      jason@hal.eel.ufl.edu (Jason Nadrowski)
To:        comp.protocols.tcp-ip
Subject:   FAQ --> Where is it???


Is there a FAQ for this group?


-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Oct 1992 17:31:00 GMT
From:      csjjlay@knuth.mtsu.edu (JJ Lay)
To:        comp.protocols.tcp-ip
Subject:   Dial up TCP-IP, is it possible?

Does anyone know of a product (shareware/freeware/commercial) that would
allow a system to become a node on a TCP-IP network using modems?  The
reason: I want to link my home computer to the network here at the
Computer Science department at Middle Tennessee State U.
Please e-mail and I'll summarize to the net. 

							------
							JJ LAY

------------------------------------------------------------------------
JJ LAY                                  CENTER FOR HISTORIC PRESERVATION
COMPUTER SPECIALIST                    MIDDLE TENNESSEE STATE UNIVERSITY
csjjlay@mtsu.edu                                             MTSU BOX 80
(615) 898-2658                                   Murfreesboro, TN  37132
------------------------------------------------------------------------
"I used to think that the idea of space probes was to answer questions.
That's hopeless.  You invariably raise more questions than you answer."
	-Andrew Ingersoll, Caltech, member of the Voyager 2 imaging team


-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Oct 1992 17:55:03 GMT
From:      VAAGA@gribb.hsr.no (Vaaga, Hans Egil       7-93)
To:        comp.protocols.tcp-ip
Subject:   Problem reading all packets

Hi!

First of all, thanks to all who answered our first question on how we read 
all packets from the network.

Now we have another question. We tried out the nettl-program. But it didn't 
read all the packets. It just read the packets conserning that particular 
machine we where logged on. We know that it should work, but on this machine 
here at the school it didn't work. Fortunatly it will work on the computer 
at the company which we are doing this for.

Does anybody have an idea of why it isn't working?


Hans Egil Vaaga

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Oct 1992 18:23:25 GMT
From:      johnr@pacdata.com (John Reed)
To:        comp.protocols.tcp-ip
Subject:   System V Print Service - Remote Printing

I have written an lpd server than runs in an embedded environment.
I would like to do the same for System V remote printing.

My 1st question is: where can I find the Protocol definition for
System V remote printing?  rfc1179 is the spec for lpd, but I have
been unable to find one for System V.  Perhaps I've been overlooking
the obvious?

I have just read the description of the new "Print Service" for Solaris
2.0 in the September issue of the "Sun Technical Bulletin".  It says
that the print server daemon in 2.0 will be able to handle both the
lpd protocol and the System V remote printing protocol.

What I would like verification of (if anybody knows), is this new
Sun print server compatible with the HP-UX print client?  That is, can an
HP machine using its standard OS and standard line printing system, use
the Solaris 2.0 server for remote printing?

I have a new HP 705 running HP-UX version ??, but no Solaris 2.0 yet.  I
figure that I can use an analyzer to discover what the remote printing
protocol is.  I just need to know if the HP-UX remote printing protocol
is the same one that will be used by Solaris 2.0.

(As you can probably tell, I know virtually nothing about System V,
especially nothing about the System V line printing system)


JR



-- 


   /------------------------------------------------------------------\
  |  John Reed                           {ucsd,uunet}!pacdata!johnr    |
  |  Pacific Data Products               johnr@pacdata.com             |
  |                    ---------------------                           |
  |  George Herbert Walker Bush, with the letters re-arranged spells:  |
  |                                                                    |
  |                 Huge Berserk Rebel Warthog                         |
  |                                     -- From Cosmic Trigger II      |
   \------------------------------------------------------------------/

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 92 18:27:01 GMT
From:      joshua@Veritas.COM (Joshua Levy)
To:        comp.sys.sun.misc,comp.sys.sun.apps,comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Please read, RPC related ...

In article <1992Oct27.032013.29311@vaxeline.ftp.com> nirmal@vaxeline.ftp.com (Nirmal K. Samuel) writes:
>	I am thinking of using SUN-RPC for developing a
>network application. I know about SUN-RPC well and have done a prototype
>using it and XDR. I am not sure if I am can get any performance
>benefit by directly using the XDR layer, bypassing the RPC. Of
>course this would mean a bit more coding, but is this justified ?

It is very unlikely that you would get any speed up at all.  I did
a paper on RPC speeds.  The summary was this: most of the time is
spend in the transport protocol (UDP or TCP).  Some is spent in
packaging up the data (XDR), almost none is spent in the "RPC" part of
the code, which you are trying to optimize.  You might want to
look at a paper in INTERNETWORKING vol. 1, #2 (I think) about
optimizing XDR for numerical applications, if you are passing 
around huge arrays of numbers (this is not my paper).

As someone else said: measure first, optimize second (if at all).
If you measure where your time is spent, I think you will find
that the non-transport, non-XDR time is very small.

>Are there any studies on the performance Vs. gain in development time ?

I looked into this a previous company (about 3 years ago).  The best
I could do was spending 3 months of time to getting 5% speed up at
most.  More likely, getting no speed up at all.  Porting a maintence
costs would be much higher.  Reliability would be much lower.

>I am wondering about this, because there does not seem to be any
>serious products based on RPC. Do you know why?

This is not true.  NFS is built on RPC, and it is run by a huge number
of workstations all over the place.  YP (or NIS) is less used, but
still a serious product.  I believe that Frame uses SUN RPC, also.

Personally, I think that RPC is not well suited for communicating 
between a user interface (especially a GUI) and the rest of a program.
It is much better at communicating between client and server parts
of a program, when neither is a user interface.  But most interprocess
communications seems to happen between a UI and an "engine" which
is why RPC is not used all that much.  Message passing seems to work
much better between a UI and an "engine".  I'm not sure why, but
I think because it is async.

Joshua Levy  (joshua@veritas.com)

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 92 18:27:04 GMT
From:      magma@nic.cerf.net (Ed Romascan)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: Transport Provider Interface for UNIX STREAMS

The TPI spec can be found in the ATT sys V docs. It is appendix 2
in the volume about "Porting Rules", I don't remember which volume
that is (and I no longer have access to them to find out). 

I have a xerox of the spec (and only the spec) so if you can't
find a copy let me know, we no doubt can work something out.

regards,
bruce schoenleber
(619) 457-0750


-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Oct 1992 19:12:15 GMT
From:      rivero <rivero@cc.unizar.es>
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: LPD for DOS found!

In article <paul.720220317@tantrum.csir.co.za> Paul Nash,
paul@tantrum.csir.co.za writes:
>A while back, in <1992Oct19.144410.6627@nuustak.csir.co.za> I asked:
>
>>Does anyone know of an LPD for DOS?  
>
>I got lots and lots of responses, which pointed me at:

Yes, but which ones are capable of running under Windows 3,
and to coexist with nicer things as QVT NET in the same machine?

A. Rivero

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 92 20:21:07 GMT
From:      gsa@easyaspi.udev.cdc.com (gary s anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: Raw socket programming

In article <rturner.720228707@imagen>, rturner@imagen.com (Randy Turner) writes:
|> 
|>   I am trying to find a reference on how to do raw socket programming
|> under SUNOS 4.1.1.  What I would like to do is open a socket to the ethernet
|> and turn on promiscuous mode and trap certain types of packets.  I have root
|> privilege so I should be able to access the network at this level.  Does 
|> anyone know where I can obtain an example of how to do this OR could someone
|> shed some light on the appropriate steps for doing this??
|> 
|>                                         Thanks in advance,
|> 							Randy Turner

Try "etherfind"....

to roll your own, look at the NIT documentation....

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 92 20:30:22 GMT
From:      gsa@easyaspi.udev.cdc.com (gary s anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: Detecting Dropped Sockets (Why is this hard on PC's?)

In article <500@asylum.UUCP>, romkey@asylum.UUCP (John Romkey) writes:
|> djmolny@evolving.com (DJ Molny) writes:
|> >In the last two months, I've worked on three different projects interfacing
|> >PC's to a UNIX server (IBM RS/6000) via TCP/IP.  Two projects used Novell
|> >LAN Workplace for DOS, and one used FTP's TCP/IP package.
 
|> >In all three cases, it seems that the RS/6000 doesn't detect a "rude"
|> >disconnect (e.g. powering off the PC).  The only workaround I've found
|> >is to transmit a "heartbeat" periodically and close the socket if the
|> >transmit fails.
 
|> >Two questions:
 
|> >	- Why is this a problem?  UNIX-to-UNIX connections, Xstations,
|> >	  mainframes, etc. all support a clean tear-down.  Why not PC's?
|> 
|> There's a difference between, say, powering down a PC, and killing a process
|> on a UNIX box. Comparing powering down a PC and powering down a UNIX box would
|> be a much more accurate thing, and would likely lead to the same results.
|> 
|> When you power down the PC, there's *nothing* there anymore to respond to
|> packets. If the process on the other end sends data, it goes into the bit
|> bucket. It will get no response.
|> 
|> If you've killed a UNIX process, the UNIX TCP is still around. The next time
|> the other application sends data to it, the UNIX TCP can send a TCP reset
|> packet, indicating the connection is gone away. It's possible that some UNIX's
|> will also automatically initiate a graceful close when the process die - I'm
|> unsure about this.
|> 
|> The main difference is that when you kill a UNIX process, there's still
|> something there to do some talking. When you power off a PC, there's not.
|> 
|> 
|> 4BSD's TCP has a notion of a "keepalive", which is handled at the TCP layer,
|> transparently to the process. TCP will periodically send out a keepalive
|> packet and if there's no response after too long, it will shut down the
|> connection.
|> -- 
|> 	- john romkey	  ELF Communications	 romkey@ELF.com

If you plan to use the "keepalive" there are a few caveats in many
BSD-derived systems.  First, "keepalive" is off by default (see RFC 1122
if you want to know why).  You need to set a socket option to enable
this feature (SO_KEEPALIVE).  Second, the nominal timeout value for
established connections is 2 hours (and usually can only be changed
through kernel modifications).

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 92 21:17:54 GMT
From:      jcrowder@morse.cns.vt.edu (Jeff Crowder)
To:        comp.protocols.tcp-ip
Subject:   using a NExT for a router?


I'm thinking of ways to put together a wan on an *extremely* limited
budget.  Each site will most likely have a NExT installed to handle
stuff already planned by the user group in question.  I assume it is
possible to use the NExT as a router with a serial interface on one side
plugged into a dsu/csu and ethernet on the other and gated or something
sitting on either slip or ppp. 

Has anyone actually done something like this?  Wild-ass guessing (above)
aside, how does it actually work?  Are there other low cost
alternatives (like maybe something which could utilize switched 56;
there used to be a box called a Netblazer or something???).

Any help would be appreciated.

- Jeff Crowder


-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Oct 1992 21:40:34 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Detecting Dropped Sockets (Why is this hard on PC's?)

In article <1992Oct28.043405.76827@evolving.com> djmolny@evolving.com (DJ Molny) writes:
>	- Why is this a problem?  UNIX-to-UNIX connections, Xstations,
>	  mainframes, etc. all support a clean tear-down.  Why not PC's?

Amazing!  You mean if you drop a small nuclear device on a UNIX
machine, it goes through a graceful shutdown on all it's TCP
connections before it incinerates?  Gee, and i thought my 486/50 was
pretty fast, but obviously UNIX is functioning in a completely
different level of reality.

>	- Is there a less kludgy workaround?  The heartbeat logic works
>	  OK, but it screws up some otherwise clean applications.

Depending on the application, you might consider just timing out *any*
idle connection.  A perfectly functional connection takes up as many
of your resources as the broken one.  If those resources are precious,
it's reasonable to recover them regardless of whether the problem is
in the TCP pipe itself or somewhere above the TCP layer.  If your
resources aren't that precious, perhaps the broken connections aren't
as much of a problem as you think they are.
						don provan
						donp@novell.com

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Oct 1992 21:55:26 GMT
From:      du4@mace.cc.purdue.edu (Ted Goldstein)
To:        comp.protocols.tcp-ip
Subject:   Re: 5250 Emulator

In article <720212479snx@peeras.demon.co.uk> proyse@peeras.demon.co.uk (Phil Royse) writes:
>I have a similar requirement for a client.  They have an AS/400, IBM is
>suggesting they should use "PC Support", which I believe is a 5250 emulator
>running over TCP/IP.  It runs in DOS and can support Ethernet and Token Ring
>adapters.
>
>Does anyone know whether this is the best solution?   (yes, I know, I didn't
>state the problem....  it is to allow 30 to 40 Ethernet connected PCs
>on the same site, to access the AS/400 in normal terminal mode).
>
>What is the AS/400's TCP/IP like?  Does it support all the other
>protocols and functions one can expect from a normal UNIX system?
>

I can not tell you what the "best" solution is because I am still
trying to find it myself. I can however tell you that IBM's PC Support
does _not_ use TCP/IP. It has its own protocol. It provides 5250
emulation (multiple sessions), virtual printer support (PC can use
AS400 printer and vice versa), and virtual drive support (PC can use
AS400 disk).  It can use ethernet or token ring, but it is definetly
much nicer on token ring. On ethernet you need to use NDIS drivers and
kind of fool the software into thinking it is on token ring.  Overall
it works quite well, but the cost in RAM is high. We are still working
with IBM who tells us we should be able to get PC Support trimmed
down, but for now we have to reboot with different CONFIG.SYS files
when we switch from PC support to CAD use. As far as TCP/IP goes, the
AS/400 does support it, but it is a bit crude. I can TELNET and FTP
into/out of our AS/400, but the is no IP routing, and no LPD. It does
have SMTP, but the addressing is a little wierd because it has to
convert from SNADS addresses to internet addresses.
I am by no means an expert on all this, but I hope this information
is useful.


-- 
Ted Goldstein                            E-mail: du4@mace.cc.purdue.edu
Network and Systems Administrator        Phone : (317) 494-9070
Purdue University School of Technology   Office: Knoy Hall, Rm G009


-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Oct 1992 22:29:43 GMT
From:      merce@xenitec.on.ca (Jim Mercer)
To:        comp.protocols.tcp-ip
Subject:   Re: 5250 Emulator

In article <720212479snx@peeras.demon.co.uk> proyse@peeras.demon.co.uk (Phil Royse) writes:
>In article <1992Oct23.145618.18084@magnus.acs.ohio-state.edu> drichard@magnus.acs.ohio-state.edu writes:
>>Does anyone know of a shareware 5250 emulator for DOS that will use telnet
>>and run on an ethernet card instead of a twin-axial adapter?  I am mainly
>>looking 
>
>I have a similar requirement for a client.  They have an AS/400, IBM is
>suggesting they should use "PC Support", which I believe is a 5250 emulator
>running over TCP/IP.  It runs in DOS and can support Ethernet and Token Ring
>adapters.

PC Support runs over APPN/SNA/icky ibm stuff.  it supports token ring, it
totally abuses and breaks on ethernet.  (at least in a novell environment)

if you are running a bunch of PC's on ethernet, connected to an AS/400,
it will probably work ok.  if you want to use novell, sell all your ethernet
and buy tokenring, as IBM don't grok ethernet real good.

(see my upcoming posting to comp.sys.novell,comp.dcom.lans, Re: MSIPX/NDIS)

it seems that when IBM decided to do PC Support, the decided on NDIS (Microsoft)
as the stack of choice..  unfortunately, in novell environments, this
don't mesh to well.  you need to have ODI and NDIS co-resident in
your drivers, using ODINSUP or another wedge.

if anyone out there has a stable ethernet novell/PC Support configuration,
please send me email.

>Does anyone know whether this is the best solution?   (yes, I know, I didn't
>state the problem....  it is to allow 30 to 40 Ethernet connected PCs
>on the same site, to access the AS/400 in normal terminal mode).
>
>What is the AS/400's TCP/IP like?  Does it support all the other
>protocols and functions one can expect from a normal UNIX system?

it has support for FTP, Telnet, and and SMTP gateway into SNADS/OfficeVision.
it's kinda rough, but generally works.

-- 
[ Jim Mercer   Reptilian Research  merce@iguana.reptiles.org  +1 519 893-6085 ]
[             I don't want to work for a company that has a CIO.              ]
[              Disclaimer! I don't need no stinking Disclaimer!               ]

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Oct 1992 22:33:38 GMT
From:      merce@xenitec.on.ca (Jim Mercer)
To:        comp.mail.misc,comp.protocols.tcp-ip
Subject:   Re: X400 mailing over TCP/IP to AS400's Office Vision ?

In article <1992Oct28.101438.7799@edfd.uucp> markus@edfd.uucp (Markus Gruenkorn (MAGIC)) writes:
>Our As400 has the TCP/IP implementation installed and Office Vision too.
>With Office Vision X400 mailing is possible. Now we want communicate from a
>Unix X400 mailer PPP over TCP/IP to the AS400 to use the X400 features. At
>this point it is possible to  send and receive mail between the two systems
>with SMTP. Is there any chance to do X400 mailing between the unix-ws and
>AS400's office vision over TCP/IP. 

i beleive if you ask your IBM rep, you will find there is an OSI messaging
subsystem available for the AS/400.  i'm not sure if it works, but i did
see it referenced in the latest upgrade docs.

-- 
[ Jim Mercer   Reptilian Research  merce@iguana.reptiles.org  +1 519 893-6085 ]
[             I don't want to work for a company that has a CIO.              ]
[              Disclaimer! I don't need no stinking Disclaimer!               ]

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Oct 1992 22:44:47 GMT
From:      Dermot.Bradley@bbs.oit.unc.edu (Dermot Bradley)
To:        comp.protocols.tcp-ip
Subject:   Re: UUCP newss access wanted over Telnet (default port)

Well, my original query was about getting access not about the technical
tcp/ip aspect of it.

I'm still looking by the way

Dermot

bradley.d@mgvax.ulster.ac.uk **** Preferred
dermot.bradley@bbs.oit.unc.edu
--
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  bbs.oit.unc.edu or 152.2.22.80

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 92 01:06:30 GMT
From:      phil@venus.engr.ucdavis.edu (Phillip W. Wong)
To:        comp.protocols.tcp-ip
Subject:   Slip for AIX2.2

Hi everyone,

anybody got slip for aix2.2 (ibm rt pc)?

thanks in advance!

-phil
(phil@venus.engr.ucdavis.edu)

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Oct 92 02:53:13 GMT
From:      glowell@leland.Stanford.EDU (gary lowell)
To:        comp.protocols.tcp-ip
Subject:   Performance question

Hello -

I need to evaluate ways of improving the performace of a TCP/IP link
that is now running on top of X.25 at 19.2K.  The most likely
alternative is a leased line at 19.2K or 56K between two routers.

But I'm in unfamiliar territory.  Can anyone point me to literature
on this subject ?  Of particular interest would be any comparisons
of throughput and latency of various alternatives.

Thanks,
Gary Lowell
glowell@allegro.com

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Oct 1992 08:21:12 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   5250 Emulator

Ted,  thanx for your reply (also to Jim Mercer on the same newsgroup)...

In article <Bwuq8F.5nz@mentor.cc.purdue.edu> du4@mace.cc.purdue.edu writes:

>I can not tell you what the "best" solution is because I am still
>trying to find it myself. I can however tell you that IBM's PC Support
>does _not_ use TCP/IP. It has its own protocol.
Ah Ha... now I see...

>It can use ethernet or token ring, but it is definetly
>much nicer on token ring. On ethernet you need to use NDIS drivers and
>kind of fool the software into thinking it is on token ring.

The client's problem is that the Ethernet (fibre & UTP) covers this very
extensive site, and therefore cannot be replaced by token ring.
As we're stuck with needing to use Ethernet, the choice for attaching at 
the AS/400 end is:

	1. to use the token ring adapter (already on AS/400) and connect
	   a bridge (TR <--> Ethernet) into the Ethernet which comes
	   into the computer room.

or..	2. to buy the Ethernet controller for the AS/400 and connect
	   that into the Ethernet.

Is it just a question of cost (bridge vs. Ethernet adapter) or could
either of these solutions give us more grief than the other...

Thanks very much for your reply ... much more useful than the IBM rep..
who had difficulty understanding my questions, said he'd look into
it...said he'd ring me back.. etc.

Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      |         (OSI & GOSIP specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Oct 1992 10:46:04 GMT
From:      bbuess@chx400.switch.ch (Jeroen Houttuin)
To:        comp.protocols.tcp-ip
Subject:   Info broadcast


Hi,

I'm having a problem with what appears to be "broadcast storms"
on an large LAN/WAN. I have not yet put the SNIFFER on the LAN
but some initial exploration indicats some sort of IP protocol 
based problem.

I'm trying to better understand the situation before diving in.
I was hoping someone could help, where can I get detailed 
information to answer the following questions?


1. What types of IP-broadcasts are possible?

2. Why do applications (protocols) use broadcasts?

3. Which applications (protocols) are using broadcasts
   in a (router-) network?

4. How can I reduce broadcasts in a (router-) network?

5. What are the reasons for broadcast storms?

6. What kind of fire walls are possible against 
   broadcast storms?


Could you send a list of books, addresses or any 
information to the following address:

bbuess@cosine-mhs.swith.ch

NetConsult AG, Mettlenwaldweg 20a, 3037 Herrenschwanden, Switzerland.
Tel: +41 31 235 750, Fax: +41 31 235 792

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Oct 92 11:08:48 GMT
From:      taeha@mani.kaist.ac.kr (Taeha Park)
To:        comp.protocols.tcp-ip
Subject:   Help: Using subnet #0 in B class address space

I know that it's not allowed to use subnet #0 in B class addresses to avoid
confusion, but is it really harmful to use that subnet address space in any
cases ?

The story is as follows:
We have a B class address 143.248.0.0 and have used it for our FDDI campus
backbone WITHOUT subnet masking (i.e. 0xffff0000). Now we need some subnet
addresses so we are going to change the network mask to 0xfffff000, resulting
16 subnetworks each capable of 4096 hosts as follow:

	subnet #0:	143.248.0   - 143.248.15
	subnet #1:	143.248.16  - 143.248.32
	   . . .	 
	subnet #15:	143.248.240 - 143.248.255

As many system managers do, we carelessly have allocated host addresses from
the beginning of the address space (most in subnet #0 zone). Thus if we cannot
use subnet #0 after the new subnet masking, we should change IP addresses of 
about 600 hosts in subnet #0 !

I tested routed of the Sun workstation to check if routing entry for subnet#0 
(143.248.0.0) spoils routing entries of other subnets, but it does not seem
to cause any problem (I think netmasks are saved and applied in the routed 
algorithm). We are using a Cisco router for the connection to the outside
world, and again there seems no problem in the routing algorithm.

Could anyone tell me if I am missing some important point ?

Thanks,

-- Taeha Park
-- Computer Science Department, KAIST, Korea

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 92 19:43:21 EST
From:      21modak@gw.wmich.edu
To:        comp.protocols.tcp-ip
Subject:   request for Ethernet references

Hi 

Could someone give me references for some good introductory material
on ETHERNET?

I am also looking for some literature on CAMPUS NETWORKING.

I will appreciate any help. Thanks.

	-Aslam Modak
	 1940 Howard Street, #507
	 Kalamazoo, MI 49008
	 (616) 387-7608

	 modak@cs.wmich.edu

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 92 15:29:14 GMT
From:      brama@ncratl.AtlantaGA.NCR.COM (Bhyravabho Rama)
To:        comp.protocols.tcp-ip
Subject:   Wollongong and Trumpet.

I have a Western Digital Board 8003E, Ethernet/Micro Channel, and we are running
Banyan Vines as our Local area network.  We are also using FTP Inc. software
for telnet, etc.  I have been able to have Wollongong coexist with Banyan by
using the NDIS Driver.  Now what I want to be able to do is use the Trumpet
program with the Wollongong Pathway software.  When we want to run FTP Inc.'s
application in our Banyan Vines network, we have to first load the ethernet
driver called "ebanyan".  With Wollongong's Pathway NDIS drivers loaded, when-
ever I tried to load the "ebanyan" driver, I get the following error:
	Vines sordaddr() failed.

Could anybody tell me what this error means, and what can I do to get Trumpet 
News reader, and Wollongong's Pathway software, and Banyan Vines all to work
together?  Thanks in advance. 

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Oct 1992 16:03:47 GMT
From:      distsys@sol.cs.wmich.edu (Distributed Systems)
To:        comp.protocols.tcp-ip
Subject:   Server-less client communication

Hi there,

I was wondering if anybody can give me ideas / lead me to 
references which describe how to implement a connection 
between 2 clients without any server, using TCP/IP protocol.

This is what I have right now:
1> Both clients establish connection with a server.
2> The server passes the socket fd of each client to the other client.
3> The server terminates.
4> The clients continue to communicate using the fd's received.

Basically, I mean, can one socket fd be used by the server as well
as client (after the server terminates)?

Any ideas/suggestions/information on papers, journals, 
ftp sites, etc references, will be greatly appreciated! 

Thanks in advance!

--
Eric 

--------------------------------------
Eric Rustomji
System Developer

Distributed Systems Group
Department of Computer Sciences
Western Michigan University
		
Phone: (616) 387-5645 (CS Office)
		
Email: distsys@cs.wmich.edu		 
--------------------------------------
-- 

 
--------------------------------------
Distributed Systems Group

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 92 16:27:00 GMT
From:      heberlei@cs.ucdavis.edu (Louis Todd Heberlei)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Re: now you see it, now you don't

(My server complained the first time.  I hope this one gets through)

In article 25274@knight.vf.ge.com, hughes@sde.mdso.vf.ge.com (Hughes Doug) writes:
------------------- INCLUDED MESSAGE ------------------
Why does this section of code work with sun's C compiler but core dump
in inet_ntoa with gcc 1.40?

    while ( (read_ret = recvfrom( sock, buf, sizeof buf,
                  0, (struct sockaddr *) &caller,
                  &callsize)) > 0 ) {
        printf( "%s: read (from caller (%s, %d)) socket\n",
            argv[0],
            inet_ntoa(caller.sin_addr),
            ntohs(caller.sin_port));
        fflush(stdout);

Assume the bind is succesful and as I said, it works when I compile with
Sun's default (albeit substandard) C compiler.
  What gives?
Doug Hughes				hughes@sde.mdso.vf.ge.com
------------------- END OF MESSAGE ---------------------


I know this is going to sound like a strange suggestion, but try passing
a pointer in instead of the value.  

	inet_ntoa(&(caller.sin_addr)),

I have had troubles porting code using inet_ntoa(): sometimes I have to pass
a pointer, sometimes I have to pass a value.

I don't fully understand why, but it has worked for me in the past.  It
might work for you.

Good luck,

Todd			heberlei@cs.ucdavis.edu

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 92 23:12:40 CST
From:      bruins@hal9000.apana.org.au (Mike J. Bruins)
To:        comp.protocols.tcp-ip,comp.sys.amiga
Subject:   WANTED TCP/IP SLIP AMIGA

Hi there,
   Has anyone heard of a set of programs that will let an amiga

talk SLIP to other machines?  I want to be able to run news,

mail and ftp over a serial line and have heard that SLIP is

the best way to do this.  I've got fish disk 225 that has

all the basics on it like telnet etc, but believe I need to

add programs to work news and mail.  Any help would be apreciated.


      Mike Bruins

        bruins@hal9000.apana.org.au

   (08) 4144828 [bh]

Please excuse any problems in my wording of this request, I am in 
unfamiliar teritory.

-----------------------------------------------------------------------------
     bruins@hal9000.apana.org.au     H   H   AA  L    999   000   000   000
       (08) 371-2343 (DATA)          H   H  A  A L   9   9 0  00 0  00 0  00
                                     HHHHH  AAAA L    9999 0 0 0 0 0 0 0 0 0
                                     H   H  A  A L       9 00  0 00  0 00  0
                                     H   H  A  A LLLL 999   000   000   000
-----------------------------------------------------------------------------




-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 1992 17:38:33 GMT
From:      krishnan@pms240.pms.ford.com (Hare Krishnan)
To:        comp.protocols.tcp-ip
Subject:   Re: System V Print Service - Remote Printing

If you are concerned about HPs alone, there is a solution provided by HP.

HP systems has a daemoncalled "rlpdaemon". This is similar to lpd.
Unlike lpd this is invoked from "inetd.conf". From your HP client, you can 
setup your print job as to print to a remote printer and remote printer of 
type BSD. This should take care of your problem. Even if your print server
is HP-UX, configure your HP-UX clients to print to a BSD remote printer.

All you have to do on your server is to uncomment the printer line from 
the "/etc/inetd.conf" file and restart inetd.


 

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 92 21:45:11 EDT
From:      mbs@adastra.cvl.va.us (Michael B. Smith)
To:        comp.protocols.tcp-ip,comp.sys.amiga
Subject:   Re: WANTED TCP/IP SLIP AMIGA

In article <bruins.0cb7@hal9000.apana.org.au> bruins@hal9000.apana.org.au (Mike J. Bruins) writes:
> the best way to do this.  I've got fish disk 225 that has
> all the basics on it like telnet etc, but believe I need to
> add programs to work news and mail.  Any help would be apreciated.

GRn 1.16f and later has NNTP built-in (assuming that you have CBM's AS225).
It is a fully Intuitionized newsreader for the Amiga.

When using NNTP, AmigaUUCP is not required.
--
  //   Michael B. Smith
\X/    mbs@adastra.cvl.va.us  -or-  uunet.uu.net!virginia.edu!adastra!mbs

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Oct 1992 17:46:01 GMT
From:      mdw@cbnewsg.cb.att.com (mark.d.wuest)
To:        comp.protocols.tcp-ip
Subject:   Re: now you see it, now you don't

In article <18621@ucdavis.ucdavis.edu> heberlei@cs.ucdavis.edu writes:
>In article 25274@knight.vf.ge.com, hughes@sde.mdso.vf.ge.com (Hughes Doug) writes:
>>Why does this section of code work with sun's C compiler but core dump
>>in inet_ntoa with gcc 1.40?
>>            inet_ntoa(caller.sin_addr),
 
>I know this is going to sound like a strange suggestion, but try passing
>a pointer in instead of the value.  
 
>	inet_ntoa(&(caller.sin_addr)),
 
>I don't fully understand why, but it has worked for me in the past.  It
>might work for you.

A combination of RTFM and looking in netinet/in.h shows that inet_ntoa()
asks for a pointer and, of course sockaddr_in.sin_addr is a struct,
not a pointer to one.

I have other examples of code I wrote that shouldn't have worked,
but it did work on a Sun.  I don't know whether to ;-) or ;-(.

Mark
-- 
Mark Wuest                              |     *MY* opinions, not AT&T's!!
mark.wuest@att.com                      |
mdw@cheshire.att.com (NeXT Mail)        |

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Oct 1992 18:17:40 GMT
From:      shane@utdallas.edu (Shane Davis)
To:        comp.protocols.tcp-ip
Subject:   Re: rpc process chewing up resources

In article <bvs.719265213@nrc.com>, bvs@nrc.com (Bill Versteeg) writes:
|> 
|> I have a process somewhere that is continually opening
|> up SUN RPC connections, and then leaving them
|> in TIME_WAIT. I want to shut him
|> down, but I can't figure which process is doing it.
|> Here is a netstat output
|> 
|> Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
|> tcp        0      0  127.0.0.1.2544         127.0.0.1.sunrpc       TIME_WAIT
|> tcp        0      0  127.0.0.1.2543         127.0.0.1.sunrpc       TIME_WAIT
|> tcp        0      0  127.0.0.1.2542         127.0.0.1.sunrpc       TIME_WAIT
|> tcp        0      0  127.0.0.1.2541         127.0.0.1.sunrpc       TIME_WAIT
|> ?
|> 

These are the result of netstat. Watch how a new one is created each time
you run netstat. I'm not sure why netstat uses RPC.

--Shane

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Oct 1992 19:31:50 GMT
From:      Donald E. Eastlake, III <dee@ranger.enet.dec.com>
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Q & A

In article <1992Oct26.203430.3720@fcom.cc.utah.edu> Just me,
jharvey@csulx.weber.edu writes:
>     Dear readers,
> 
>     My name is Justin Harvey and I am the TCP/IP Project Coordinator
>for the City & Borough of Juneau here in Alaska.  With only one
 Internet 
>supplier being the University limiting connections and accounts to
 faculty,
>staff or students, I have found a potential network market niche.  I'd
>like to purchase a Unix/OS computer being a 486 or actual Unix
 machine an
>setup dialin lines with SLIP connections available as well.  

Seems to me that rather than looking for your own connection, maybe
you should look into sharing whatever connection(s) Weber has with the
outside world.  Even if their connection  (or one of them if they had
multiple) needed to be upgraded because of your load, it might be
cheaper.  You should also contact other commercial Internet providers
instead of just UUNET.

Donald

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 92 21:26:04 GMT
From:      gsa@easyaspi.udev.cdc.com (gary s anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: rpc process chewing up resources

In article <1992Oct29.181740.22223@utdallas.edu>, shane@utdallas.edu (Shane Davis) writes:
|> In article <bvs.719265213@nrc.com>, bvs@nrc.com (Bill Versteeg) writes:
|> |> 
|> |> I have a process somewhere that is continually opening
|> |> up SUN RPC connections, and then leaving them
|> |> in TIME_WAIT. I want to shut him
|> |> down, but I can't figure which process is doing it.
|> |> Here is a netstat output
|> |> 
|> |> Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
|> |> tcp        0      0  127.0.0.1.2544         127.0.0.1.sunrpc       TIME_WAIT
|> |> tcp        0      0  127.0.0.1.2543         127.0.0.1.sunrpc       TIME_WAIT
|> |> tcp        0      0  127.0.0.1.2542         127.0.0.1.sunrpc       TIME_WAIT
|> |> tcp        0      0  127.0.0.1.2541         127.0.0.1.sunrpc       TIME_WAIT
|> |> ?
|> |> 
|> 
|> These are the result of netstat. Watch how a new one is created each time
|> you run netstat. I'm not sure why netstat uses RPC.
|> 
|> --Shane

I sent this reply directly to the originator before.  My assumption was that
he was using yellow pages (a.k.a. NIS) for various "number to name"
translations (e.g. netstat, ls, etc.).

Here goes:

Last I looked "sunrpc" was the port number for the portmapper (111).
There used to be some "questionable" code in the "ONC suite" which
would logically "ping" the portmapper by attempting to create a
connection to the portmapper daemon.  As I recall, the code actually
sits within the "yp" library code (you need to ask SUN why "pinging"
the portmapper from within "yp" is useful).  This has the wonderful
side-effect of leaving connections in a TIME_WAIT state.  The
frequency of "pings" is usually once per process.  Consequently,
when you use multi-process applications or write iterative
scripts (large iteration count and short duration processes)
you exacerbate the problem.

The best answer is to ask SUN for a software upgrade.

In the short term, you could avoid using "names" (e.g. netstat -rn)
or you could stop using yellow pages (a.k.a. NIS) or you could
place frequently referenced names in the local files (e.g. /etc/hosts).

NOTE - there maybe a thousand other reasons for this behavior, however,
this looks awfully similar to locally observed symptoms.

Hope this helps.......


-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 92 21:53:55 GMT
From:      kent@loral.cts.com (Kent Yang)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Request info on broadcast

I have recently been put on a project to do broadcast to a network of
machines that consist of DEC stations, and DEC PCs.  I was wondering if
anyone is familiar with a product named pathworks for the DEC PCs and
how I can send broadcast packets to it?  Also, is there a public domain
library somewhere that support broadcast?  If you know or have any
information on broadcast and or any information on pathworks, I would
appreciate a response from you through E-mail.  Any information you can
send me would be greatly appreciated.  Thanks in advance.

--
Kent Yang -  Design Engineer -  kent@loral.cts.com
Engineering, Loral Instrumentation (San Diego, CA)
Phone: (619)674-5100 ext 4180 Fax:   (619)674-5145

--
Kent Yang -  Design Engineer -  kent@loral.cts.com
Engineering, Loral Instrumentation (San Diego, CA)
Phone: (619)674-5100 ext 4180 Fax:   (619)674-5145

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Oct 1992 23:14:25 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Detecting Dropped Sockets (Why is this hard on PC's?)

>If you've killed a UNIX process, the UNIX TCP is still around. The next time
>the other application sends data to it, the UNIX TCP can send a TCP reset
>packet, indicating the connection is gone away. It's possible that some UNIX's
>will also automatically initiate a graceful close when the process die - I'm
>unsure about this.

The ones I've seen send a FIN out on the connection when the process
dies.  (Since all open descriptors are closed by the kernel when the
process terminates, and a socket is just an open descriptor, so TCP
doesn't know whether the process voluntatily exited or was killed.)
This lets the other end know immediately when the process dies, if
it's coded correctly (e.g., uses select or poll so that's it's not
blocked on some other form of I/O).

I've also seen most systems send out a FIN on each connection when
the host is "shutdown" (as compared to powering off or crashing).

	Rich Stevens

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 92 01:26:01 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Detecting Dropped Sockets (Why is this hard on PC's?)

In article <1992Oct29.231425.4894@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:
>The ones I've seen send a FIN out on the connection when the process dies.

Really?  Yeow!  That would indicate to the other side that the
connection is completing normally.  That's fine for, say, a telnet
connection, but it could mean a half written file being transfered
"successfully" if its done in the middle of an FTP transfer, and
who knows what it might mean for some other TCP application caught
halfway through some critical operation.  "Please set my password
to the-rain-in-spain-falls-mainly-on-the-pl".
						don provan
						donp@novell.com

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 92 04:51:46 GMT
From:      chris@suite.sw.oz.au (Chris Maltby)
To:        comp.protocols.tcp-ip
Subject:   SCO TCP bandwidth problems - experiences sought

I am experiencing some surprising things with a system running
SCO Unix 3.2.2 and SCO TCP 1.1.3f. We have recently upgraded
the hardware from a 25MHz 486DX to 486DX2 (clock doubled) cpus,
extra memory (16+16MB) and a 32bit 3com Ethernet card. The system
is a microchannel box.

First, when sending 1Kb UDP packets the throughput is about 5Mbits
per second of system CPU time (as measured by both time and timex).
One thinks that perhaps SCO TCP isn't very efficient...
Anyway, we expected some improvement with the DX2, but in fact it
got slightly worse. The ether cards made negligible difference except
that the 3com driver causes system crashes under heavy loads (it's
an early release).

So, here are my questions:

Q1. Would upgrading to SCO TCP 1.2 improve the efficiency of this
    system or should we just throw out SCO and try something else?

Q2. Does SCO TCP 1.2 require an upgrade from SCO UNIX 3.2.2?

Q3. Is this sort of behaviour with installing a 486DX2 to be expected?

Q4. Is there a reasonable way to achieve better TCP/IP performance
    on SCO or SCO compatible (say SVR4?) platforms?

Thanks in advance...
Chris
-- 
Chris Maltby - Softway Pty Ltd		Internet: chris@softway.sw.oz.au

PHONE:	+61-2-698-2322	"I'm waiting for X-Windows to become just that;
FAX:	+61-2-699-9174	 Ex-Windows" - A McGrath.

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 92 07:49:28 GMT
From:      poon@jomby.cs.wisc.edu (Ka-Cheong Poon)
To:        comp.protocols.tcp-ip
Subject:   Help: find an old article


In the chapter about performance in Stevens's "UNIX Network Programming",
an old article (Message-ID <8807200426.A01221@helios.ee.lbl.gov>) by
Jacobson is referred.  I'd like to read about it.  But I don't know where
I can get it.  Could someone help me?  Are there other articles about
performance of TCP/IP worth reading?  I just started to study about this,
so I know little about it.  Thanks in advance.

								Poon.

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Oct 1992 08:20:42 GMT
From:      graeme@ccu1.aukuni.ac.nz ( Graeme Moffat)
To:        comp.unix.admin,comp.unix.aix,comp.protocols.tcp-ip
Subject:   Re: inetd configuration questions

bware@slate.mines.colorado.edu (Bob Ware) writes:

>Did you execute "inetimp" and "refresh -s inetd" to make sure the odm
>had what was in the inetd.conf file?

I have noticed in the "Diskless Workstation Management Guide", when
referring to changing inetd.conf, that the command "inetimp" is omitted from
the instructions. Does 3.2 now not use the ODM for inetd? Could this be IBM
listening to people complaining about 'shadow' traditional unix config
files?? Could this be the beginning of the end of them? Could this be a
bad mistake in the manual?

-- 
Graeme Moffat                g.moffat@aukuni.ac.nz \ Time wastes us all, 
Computer Aided Design Centre,  Fax: +64-9-366-0702 /  our bodies & our wits
School of Engineering,    Ph: +64-9-737-999 x8384 /  But we waste time,
University of Auckland, Private Bag, Auckland, NZ \   so time & we are quits

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 92 11:13:55 GMT
From:      aroby@andersen.co.uk (Tony Roby)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP client source

allen@mr.med.ge.com (Phil Allen 4-6086 MRCE) writes:


>Now the next obvious question.  Is there anywhere I can get public
>domain, gnu, etc. source for a FTP client? (I learn so much better
>by example ;-) ).  

Try looking for Phil Karn's KA9Q package.  I know for a fact that it is
on ftp.demon.co.uk in /pub/ibmpc/DIS.  The file is called nos*.zip where *
is the current release.  I also have some source of my own which is VERY basic
(ie log on and get a file) if you're interested.

Tony

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Oct 1992 11:28:22 GMT
From:      roana@cs.utwente.nl (Room 101)
To:        comp.protocols.tcp-ip
Subject:   IP level encryption


Hi,

  I was wondering if anybody out there had done some work on encrypting data
at the IP level. This principle would allow any two hosts to have secure,
authenticated communication using insecure IP-compatible routers, while not
requiring any complex systems like Kerberos or any other system working at
the application layer. It should work on a low-level basis (like a processor
in the transceiver) and use a secure encryption method (about anything besides
DES ;-)

Grtnx,
Ronald

roana@cs.utwente.nl

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Oct 1992 14:33:36 GMT
From:      karl@ddsw1.mcs.com (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   Re: Changing from Class C to Class B

In article <1citahINN66t@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>In article <1992Oct24.165829.3243@bernina.ethz.ch> karrer@bernina.ethz.ch (Andreas Karrer) writes:
>>barmar@think.com (Barry Margolin) writes:
>>>If all TCP/IP implementations were done correctly, it wouldn't make much
>>>difference.  However, there are some implementations that don't handle
>>>subnet masks that don't end on a byte boundary.  
>>
>>Please name them.
>
>I don't know them offhand.  However, this question comes up every couple of
>months in this group, and a few people always manage to point out problems
>they've had.

There aren't many of these left, but I bet the number is non-zero.

>Another problem with non-octet subnets is with reverse resolution, i.e. the
>IN-ADDR.ARPA domain.  If your subnets correspond to organizational
>boundaries, and you want to delegate name management to organizations, then
>you'll need to be able to delegate zones within your xxx.yyy.IN-ADDR.ARPA
>domain, and this can only be done on octet boudaries.

This is the real problem with doing this.  You will need to find some way to
resolve this problem, and its a potentially political hot potato.  The best
way may be an automatic zone transfer from each nameserver to a central
system which then runs all primaries for the IN-ADDR.ARPA domain in your
address range (ie: build the PTR records from the "A" records, and zone
transfer the delegated areas).

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Data Line: [+1 312 248-0900] Anon. arch. (nuucp) 00:00-06:00 C[SD]T
Request file: /u/public/sources/DIRECTORY/README for instructions


-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 92 15:35:51 GMT
From:      paul@ace.acadiau.ca (Paul Steele)
To:        comp.protocols.tcp-ip
Subject:   Setting up an Annex III for SLIP - Help requested

I am trying to set up a simple dial slip line on one of the ports of an
Annex III communications server.  I haven't done much with SLIP but the
description in the manual seems simple enough and I think I've done
everything right.  When I first connect to the port I get into the standard
annex cli.  I then enter the SLIP command and it switches to slip mode.
However, I can't seem to talk to anything.  I am using NCSA Telnet 2.5 on a
Mac and specifying a slip connection at 9600 baud.  When I open a
connection, I get a window, but no login prompt appears.  On the host side a
ping command does not see the Mac at the assigned IP address.  If anyone has
any suggestions as to what I might be doing wrong or omitting, I'd greatly
appreciate hearing from you.

On a similar topic, what is the best program to use on a PC that could be
used to dial up to a slip connection?

___
Paul Steele, Network Services Manager              902-542-2201x660
Acadia University, Computer Centre            FAX: 902-542-4364
Wolfville, Nova Scotia, Canada, B0P 1X0  Internet: Paul.Steele@acadiau.ca

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Oct 1992 16:07:24 GMT
From:      erick@demorgan.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Detecting Dropped Sockets (Why is this hard on PC's?)

rstevens@noao.edu (W. Richard Stevens) writes:
>>If you've killed a UNIX process, the UNIX TCP is still around. The next time
>>the other application sends data to it, the UNIX TCP can send a TCP reset
>>packet, indicating the connection is gone away. It's possible that some UNIX's
>>will also automatically initiate a graceful close when the process die - I'm
>>unsure about this.
>
>The ones I've seen send a FIN out on the connection when the process
>dies.  (Since all open descriptors are closed by the kernel when the
>process terminates, and a socket is just an open descriptor, so TCP
>doesn't know whether the process voluntatily exited or was killed.)
>This lets the other end know immediately when the process dies, if
>it's coded correctly (e.g., uses select or poll so that's it's not
>blocked on some other form of I/O).
>
>I've also seen most systems send out a FIN on each connection when
>the host is "shutdown" (as compared to powering off or crashing).
>

But you are talking about a graceful shutdown.  It is reasonable for 
dying systems or imminently dying systems to TCP RESET.  And when
you do a shutdown, it is reasonable for TCP to do a RESET if the FIN
was not acknowledged and you want to go down.

That may seem like a small point, but microcomputer applications often
include the TCP kernel inside the application binary.  So when that program
ends, the TCP is no longer in memory and it better have made sure that
every attempt has been made to close or reset the connection.

This does not usually apply to Novell's LanWorkPlace, our original topic,
because they load it as a TSR (a pc way of loading an extension to the
operating system - no flames on that description please).  But LWP might
still use this idea since I think Novell includes a function to unload their
TCP system.

Erick
-- 
----------------------------------------------------------------------------
Erick Engelke				 	            WATTCP Architect
erick@development.uwaterloo.ca     TCP/IP was easy but i still can't work VI

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 92 16:26:57 GMT
From:      pstevens@Metaphor.COM (Paul Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: AMERICANS and Texas kangaroos.us

In article <1992Oct19.164527.164803@dstos3.dsto.gov.au>, bat@dstos3.dsto.gov.au writes:
|> I know I am about to raise a hornets nest with this one but the chance to
|> annoy a whole nation I just can't resist.
|> 
|> 	In the interests of internationalism, humility and just plain getting
|> along with your neighbours can we have a new top level domain called .us under
|> which .mil .com .edu etc are located ?   The rest of the planet all have to
|> route our mail via our own countries so  why not the Yanks ? 

The first short answer is that there already *IS* such a domain.  There are
even sub-domains for each state in the U.S.  For example, I have a mail
acount on a system called the WELL that registers itself in the internet 
DNS as well.sf.ca.us.  For more info about the .us domain try doing
a, "whois us-dom"

It is certainly much less used by companies and universities.  From what I know
about the  domains that are created for other countries I think that often 
the whole country's internet access is often controlled (operated) by 
their PTT who then decides what domain(s) will be used by everyone connecting
through them.  They then often insist that only the .<country_code> 
sub-domain will be supported.  
+------------------------------------------------------------------------+

   Paul Stevens                        {apple|decwrl}!metaphor!pstevens
   Metaphor Computer Systems           pstevens@metaphor.com
   Mountain View, CA

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Oct 1992 17:09:19 GMT
From:      steve@ecf.toronto.edu (Steve Kotsopoulos)
To:        comp.protocols.tcp-ip
Subject:   Who supports multicast?

Sorry if this is a FAQ, but I am trying to find out which UNIX
operating systems support multicast (for a project I'm working on).

So far, the only one I have found is SGI's IRIX 4.0.5.

If you want to email responses, I'll post a summary.

Thanks
-- 
Steve Kotsopoulos                   mail:   steve@ecf.toronto.edu
Systems Analyst                     bitnet: steve@ecf.UTORONTO.BITNET
Engineering Computing Facility      uucp:   uunet!utai!ecf!steve
University of Toronto               phone:  (416) 978-5898

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 92 17:39:52 GMT
From:      psampat@picasso.ocis.temple.edu (Pragnesh Sampat)
To:        comp.protocols.tcp-ip
Subject:   SUN RPC vers problem(long)

Hello

	I am trying to run a simple server to test out how to run two
versions of a program. The two machines are : a CDC risc machine running
EP/IX ( sysv and bsd43 ) and a NeXT machine ( mach kernel and bsd ). The
RPC lib is version 4.0 I believe. Here's the problem : The second version
works fine but the call to the first version results in the second version
being executed. I would like to do this with callrpc() and registerrpc()
and not low level ( switch on rq_vers ). Here's the code


			     ***FILE add.h***


#define ADDPROG		((u_long)0x20000100) /* prog number */
#define ADDVERS1  	((u_long)1) /* for vers one */
#define ADDVERS2 	((u_long)2) /* for vers two */
#define ADDPROC      	((u_long)1) /* proc number */
extern int *add_1();		/* proc for vers one */
extern int *add_2();		/* proc for vers two */

struct argtype {		/* args struct for passing */
     int low;
     int high;
     int step;
} ;			

typedef struct argtype argtype;	
				/* declare the xdr routine which will be */
				/* called for args encoding/decoding. See */
				/* add_xdr.c for more comments */
extern bool_t xdr_sumargs(XDR *xdr_handlep, argtype *);


			   ***FILE add_xdr.c***


#include <stdio.h>
#include <rpc/rpc.h>		/* includes other rpc related files like */
				/* types.h and xdr.h */
#include "add.h"
				/* bool_t is TRUE or FALSE and defined as */
				/* int in rpc/types.h */
				/* XDR is the XDR handle defined in rpc/ */
				/* xdr.h. It contains field for operations */
				/* i. e. encode/decode */

bool_t xdr_sumargs(XDR *xdr_handlep, argtype *objp)
{
				/* xdr_int is a builtin filter from which */
				/* we are constructing a custom filter. Some */
				/* of the other builtin filters are xdr_char */
				/* xdr_short, xdr_reference and many others.*/

     return ((xdr_int(xdr_handlep, &objp->low)) &&
	     (xdr_int(xdr_handlep, &objp->high)) &&
	     (xdr_int(xdr_handlep, &objp->step)));

}

			  ***FILE add_clnt.c***


#include <stdio.h>	
#include <rpc/rpc.h>		/* std rpc include file */
#include "add.h"		/* common header file for client and server */

#define STEPSIZE	1

main(int argc, char *argv[])
{

     enum versions {one, two};
     enum versions vers=two;	/* default version */
     int defaultstep=STEPSIZE;
     int status, result1, result2; /* results for vers one and two */
     int localarg;		/* arg for vers one */
     argtype sumargs;		/* argument to be passed for vers two */
				/* defined in the header add.h */

     if (argc == 3) 
	  vers = one;		/* do args processing */
     else {
	  if ((argc != 4) && (argc !=5)) {
	       printf("usage: add_clnt server low high [step] for vers 2\n");
	       printf("       add_clnt server number for vers 1\n");
	       exit(1);
	  }
	  if (argc == 5)
	       defaultstep = atoi(argv[4]);
     }
     if (vers == one) {		/* want vers one */
	  localarg = atoi(argv[2]);
	  status = callrpc(argv[1], ADDPROG, ADDVERS1, ADDPROC , xdr_int,
			   (int *)&localarg, xdr_int, (int *)&result1);
	  if (status == 0) 
	       printf("result is %d\n", result1);
	  else {
	       fprintf(stderr, "Error: callrpc(); %s\n", clnt_sperrno((enum
		       clnt_stat)status));
	       exit(2);
	  }
     }
     else {			/* want vers two */
	  sumargs.low  = atoi(argv[2]);	/* fill in the struct to be sent */
	  sumargs.high = atoi(argv[3]);
	  sumargs.step = defaultstep; 
	  status = callrpc(argv[1], ADDPROG, ADDVERS2, ADDPROC , xdr_sumargs,
			   (argtype *)&sumargs, xdr_int, (int *)&result2);
	  if (status == 0) 
	       printf("result is %d\n", result2);
	  else {
	       fprintf(stderr, "Error: callrpc(); %s\n", clnt_sperrno((enum
		       clnt_stat)status));
	       exit(2);
	  }

     }
     return(0);
}


			   ***FILE add_svc.c***


#include <stdio.h>
#include <rpc/rpc.h>		/* std rpc header file */
#include "add.h"		/* common file to both server and client */

main()
{
     int *add_1(int *);		/* proc for vers one */
     int *add_2(argtype *);	/* proc for vers two */

				/* register vers one */
     if (registerrpc(ADDPROG, ADDVERS1, ADDPROC , add_1, xdr_int, xdr_int)
	 == -1) {
	  fprintf(stderr, "Error : cannot register vers 1\n");
	  exit(1); 
     }
				/* register vers two */
     if (registerrpc(ADDPROG, ADDVERS2, ADDPROC , add_2, xdr_sumargs, xdr_int)
	 == -1) {
	  fprintf(stderr, "Error : cannot register vers 2\n");
	  exit(2); 
     }
     svc_run();
}

int *add_1(int *number)
{
     static int result;		/* must be static */

     result = *number + 1;
     return (&result);
}

int *add_2(argtype *sumptr)
{
     int	i;
     static int	loopsum;	/* must be static */

     loopsum = 0;
     fprintf(stderr, "this is vers two\n");
     for(i = sumptr->low; i <= sumptr->high; i = i + sumptr->step) {
	  loopsum = loopsum + i;
     }
     return (&loopsum); 

}


If I comment out the registration of the second version in the file
add_svc.c the first version is executed. Have used dbx on the client side
to trace through. seems ok. The other possibility considered was that
automatically the highest version is supported in high level and I may
have to use low level. ( BTW this is for a tutorial on using SUN RPC and
any other comment/suggestion would be welcome )

	usage : add_svc & ( on the server )
		and
		add_clnt server 1 10  --> for vers two ( e. g )
		add_clnt server 1     --> for vers one ( e. g )
			  ( on the client )

Any comment is appreciated. Thanks

Pragnesh Sampat		psampat@picasso.ocis.temple.edu		(215)787-6388

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Oct 92 17:59:44 GMT
From:      karwowska@polaris.rtp.dg.com (Joanna Karwowska)
To:        comp.protocols.tcp-ip
Subject:   Re: Transport Provider Interface for UNIX STREAMS

I aslo have a copy of TPI White Paper. It was published In Feb 14, 1989.
The following contact is listed on the front page:
	John S.Chambers
	attunix!jsc XT8142000
	SF-5-229 x201-522-6561

I am not sure what all that means. A paragraph on the same front pages
warns that "No parts of this paper may be reproduced, in any form
or by any means, without permission in writing from AT&T".
Good luck!

		Joanna
-- 

Joanna Karwowska               internet: karwowska@dg-rtp.dg.com
Data General Corporation           uucp: ...!uunet!dg-rtp.dg.com!karwowska
62 T.W. Alexander Drive           voice: 919-248-6065
Research Triangle Park, NC 27709    fax: 919-248-5942

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 92 18:29:50 GMT
From:      mark@verdix.com (Mark Lundquist)
To:        comp.protocols.tcp-ip
Subject:   Re: Detecting Dropped Sockets (Why is this hard on PC's?)

In article <1992Oct30.012601.17570@novell.com> donp@novell.com (don provan) writes:
>In article <1992Oct29.231425.4894@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:
>>The ones I've seen send a FIN out on the connection when the process dies.
>
>Really?  Yeow!  That would indicate to the other side that the
>connection is completing normally.

Right.  FIN indicates that the connection is completing normally.

And you may think normal termination of the connection *should* indicate
that the peer process has terminated normally, but that's clearly not a safe
assumption!

My point is that the interpretation of FIN is non-negotiable, as that
is part of the TCP spec.  The interpretation of "connection completes
normally" is implementation-dependent.

>That's fine for, say, a telnet
>connection, but it could mean a half written file being transfered
>"successfully" if its done in the middle of an FTP transfer, and
>who knows what it might mean for some other TCP application caught
>halfway through some critical operation.  "Please set my password
>to the-rain-in-spain-falls-mainly-on-the-pl".

A good argument for:

1) Application-level protocols that don't "blindly read data until the
   other side closes".  For instance, when an application has an
   arbitrariliy long stream of data to send, it might send a little
   something first that tells the other side how much data it's about to send.

2) Applications that catch signals and arrange for an orderly shutdown
   somehow (orderly in the sense of communicating to the other side in
   some positive way that it is dying).


I'm not familiar with the FTP spec or any implementations, but I'd say
it's a fair bet that they don't rely on connection closing to signal
the end of an arbitrary-length data stream.

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 92 19:05:13 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: Setting up an Annex III for SLIP - Help requested

In article <paul.365.720459351@ace.acadiau.ca>, paul@ace.acadiau.ca (Paul Steele) writes:
| 
| I am trying to set up a simple dial slip line on one of the ports of an
| Annex III communications server.  I haven't done much with SLIP but the
| description in the manual seems simple enough and I think I've done
| everything right.  When I first connect to the port I get into the standard
| annex cli.  I then enter the SLIP command and it switches to slip mode.
| However, I can't seem to talk to anything.  I am using NCSA Telnet 2.5 on a
| Mac and specifying a slip connection at 9600 baud.  When I open a
| connection, I get a window, but no login prompt appears.  On the host side a
| ping command does not see the Mac at the assigned IP address.  If anyone has
| any suggestions as to what I might be doing wrong or omitting, I'd greatly
| appreciate hearing from you.

I've had the same problem in trying to get dialup SLIP going in a similar
configuration.  

What I've seen is this: if I do a "stat -mN 1" on the Annex
(where N is the port number), I see that, before SLIP mode is entered,
all modem leads on the port are high (CTS RTS DTR DCD DSR).  Then,
as soon as SLIP mode is turned on, all the signals that are supposed
to be asserted by the DCE drop (i.e. stat -m goes to "cts RTS DTR dcd dsr"),
just as is seen on a hung-up line.  However, the DCE doesn't hang up
the connection.

I haven't put a breakout box on the line to find out more precisely
what's going on.  I do have a call in to Xylogics tech support to see
if anyone there knows anything about this.  If I find out anything,
I'll post to comp.dcom.servers.

| On a similar topic, what is the best program to use on a PC that could be
| used to dial up to a slip connection?

Well, I don't do PCs, but I've heard good things about FTP Software's
PC/TCP product.  (I'm sure that 3 dozen other DOS IP vendors will pipe
in at this point proffering their wares ...)

Best,

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
  "It's not a bug, it's a form of flow control."
  - Jerry Leichter on why crash-prone Unix is a suitable
    platform for NSFNET core routers

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 1992 19:38:23 GMT
From:      don@bodovipa.cis.brown.edu (Donald Wright)
To:        comp.protocols.tcp-ip
Subject:   ICMP redirects

When doing a 'netstat -rn', redirects often show up with the flags UGHDM. 
I have been unable to find any documentation on what the "M" stands for. 
Does anyone have a clue ? 

Don Wright, Network Systems Specialist    
Brown University, Providence RI
Internet: Donald_Wright@Brown.EDU
Phone:  (401) 863-7405
*** Talk is cheap, words plentiful, and deeds precious - Ross Perot ***

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Oct 1992 21:24:42 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Detecting Dropped Sockets (Why is this hard on PC's?)

In article <9213@verdix.verdix.com> mark@verdix.com (Mark Lundquist) writes:
>My point is that the interpretation of FIN is non-negotiable, as that
>is part of the TCP spec.  The interpretation of "connection completes
>normally" is implementation-dependent.

The interpretation "connection completes normally" is defined by the
application protocol.  Anything that automatically injects a "complete
connection normally" signal into the TCP data stream without the
permission of the application protocol implementation is just plain
broken, since only the application protocol implementation can know
what that means.

>I'm not familiar with the FTP spec or any implementations, but I'd say
>it's a fair bet that they don't rely on connection closing to signal
>the end of an arbitrary-length data stream.

You'd be wrong.  FTP indicates the end of a file being transfered by
closing the TCP connection that was used to transfer the file.
There's nothing wrong with this: it's only a problem because of the
broken TCP implementations we're discussing that inject a graceful
close into a connection they know nothing about.
						don provan
						donp@novell.com

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 92 22:39:24 GMT
From:      mikec@hfglobe.intel.com (Mike Coleman)
To:        comp.protocols.tcp-ip
Subject:   Packet Drivers for NDIS clients?

Just a quick question. 

I know that when I use a 3Com or some other card I can get packet drivers
to use with certain TCP/IP packages (ie QVTNET), however, is it possible
to use NDIS with clients that I can't seem to find a Clarkson driver for?

Thanks,

Mike

PS I am using a packet converter (is that the correct term) to rund PC/TCP
with my NDIS clients.


===========================================================================
Mike G. Coleman,                     i A Mullato, An Albino,
LAN Services, Intel Corporation      i A Mosquito, My Libido! Yeah!
Voice - (503) 696-2984               i            - Nirvana
Internet: mikec@hfglobe.intel.com    i What the bloody hell does that mean?
                                     i            - Me 
===> "the views I express are my own, noone else would ever want them" <===

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 92 02:37:58 GMT
From:      catone@dmark.wharton.upenn.edu (Tony Catone)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP client source

In article <1992Oct30.111355.27732@andersen.co.uk> aroby@andersen.co.uk (Tony Roby) writes:

   allen@mr.med.ge.com (Phil Allen 4-6086 MRCE) writes:

   >Now the next obvious question.  Is there anywhere I can get public
   >domain, gnu, etc. source for a FTP client? (I learn so much better
   >by example ;-) ).  

   Try looking for Phil Karn's KA9Q package.

There is also source provided with NCSA Telnet 2.3.05 for the ftp
client (and everything else).  It's in
zaphod.ncsa.uiuc.edu:PC/Telnet/tel2305s.zip.


- Tony
  catone@dmark.wharton.upenn.edu



-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 92 02:40:17 GMT
From:      catone@dmark.wharton.upenn.edu (Tony Catone)
To:        comp.protocols.tcp-ip
Subject:   Re: Setting up an Annex III for SLIP - Help requested

In article <paul.365.720459351@ace.acadiau.ca> paul@ace.acadiau.ca (Paul Steele) writes:

   On a similar topic, what is the best program to use on a PC that could be
   used to dial up to a slip connection?

The PD slipdial works well, if you are using NCSA Telnet on the PC.


- Tony
  catone@dmark.wharton.upenn.edu


-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      Sat, 31 Oct 1992 02:52:22 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: Who supports multicast?

steve@ecf.toronto.edu (Steve Kotsopoulos) writes:
+---------------
| Sorry if this is a FAQ, but I am trying to find out which UNIX
| operating systems support multicast (for a project I'm working on).
| So far, the only one I have found is SGI's IRIX 4.0.5.
+---------------

Note: We supported IP multicast way back in Irix 3.* [mid-1989]...


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043


-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      Sat, 31 Oct 92 15:11:01 PDT
From:      wjk@Phonogenic.COM (Bill Keenan)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   CSU/DSU w/ RS-232 port connected to system

A company I work for is getting an Internet connection. We would like
to have a 56K leased line to the service provider (cost $142.10 + $275
per month). The service provider charges a large setup fee for this
type of connection because the install a router (Livingston) with the
CSU/DSU.

Does anyone know if I can connect a 56K CSU/DSU with an RS-232
connection to a serial port, which can sustain 56K, on my mail/news
system instead of using a router?

________________________________________________________________________
Bill Keenan
Internet:	wjk@phonogenic.com -or- phngnc!wjk
AppleLink:	wjk@phonogenic.com@INTERNET#
CompuServe:	>INTERNET:wjk@phonogenic.com
Phonogenic Systems Corporation - Phone 415/365-1083 - FAX 415/365-1083
PO Box 3535, Redwood City CA 94064

This country borrows about $4.25 per day per US resident (that is $17/day
for a family of 4) with little hope of paying any of the principal!

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Sat, 31 Oct 1992 22:12:57 -0500
From:      Tod McQuillin <tm8t+@andrew.cmu.edu>
To:        comp.protocols.tcp-ip
Subject:   Re: FTP client source

catone@dmark.wharton.upenn.edu (Tony Catone) writes:
> aroby@andersen.co.uk (Tony Roby) writes:
>    allen@mr.med.ge.com (Phil Allen 4-6086 MRCE) writes:
> 
>    >Now the next obvious question.  Is there anywhere I can get public
>    >domain, gnu, etc. source for a FTP client? (I learn so much better
>    >by example ;-) ).  
> 
>    Try looking for Phil Karn's KA9Q package.
> 
> There is also source provided with NCSA Telnet 2.3.05 for the ftp
> client (and everything else).  It's in
> zaphod.ncsa.uiuc.edu:PC/Telnet/tel2305s.zip.

Or, better yet, get the BSD unix version from
wuarchive.wustl.edu:/mirrors4/4.3bsd-reno/usr.bin/ftp/*

END OF DOCUMENT