HDTenEightyP/NetNews huggingface dataset:
From: lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Why would a Sun take 1.5 seconds to retransmit a missed packet?
Date: 7 Jan 93 20:34:04 GMT
Reply-To: lstowell@pyrnova.pyramid.com.pyramid.com (Lon Stowell)
Organization: Pyramid Technology Corporation

In article <BARNETT.93Jan7091846@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes:
>I am examing some data collected from a medical network, and noticed
>some unusual timings.
>
>A Sun is transmitting large files (3.5Mbytes average) to an archive 
>system while receiving images from a scanner.

   Transmitting using what protocol?   FTP, NFS copy or what?

>
>Packets are missed by the archive system, so the Sun has to retransmit
>the missed packets. I have noticed large delays (0.5 - 1.5 seconds)

   Those are pretty typical numbers for TCP layer time-outs...

>
>Why would there be such a long delay? I would expect the data is in
>mbufs, so the time to resent the missed packets should be small. 
>From the timing it looks like the data was occasionally on a disk.
>If we wanted to remove these conditions, am I correct in assuming the
>sending system needs more RAM or perhaps more buffers?
  
  If this is FTP, you'd probably be better off getting rid of the
  fatal collisions on the net.....unless you can set the time-outs
  to a very small number (very dangerous, but....)
From: G.J.Milne@daresbury.ac.uk (g.j.milne)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: ftp: subcommand error codes
Date: 7 Jan 93 17:59:29 GMT
Reply-To: gjm@gserv1.dl.ac.uk
Organization: Daresbury Laboratory, UK

In article 160@bjcong.bj.co.uk, maf@bjcong.bj.co.uk (AUSTIN FARR) writes:
>What is the meaning of the 3-digit numbers in messages relating to ftp (on AIX)
>subcommands?  In particular, how is a failure signalled?

You should take a look at RFC959. As well as providing a description of
the FTP protocol it describes the reurn codes in a fair amount of
detail.

I have a feeling that there is an RFC that describes the return codes
only but I can't remember which one.

Ciao!

Gordon

     _/_/_/ _/_/_/ _/_/_/  _/_/_/ Gordon J. Milne
    _/     _/     _/   _/ _/      SERC Daresbury Laboratory, Warrington,
   _/_/_/ _/_/_/ _/_/_/  _/       WA4 4AD.
      _/ _/     _/   _/ _/
 _/_/_/ _/_/_/ _/   _/ _/_/_/     e-mail: g.j.milne@dl.ac.uk
Newsgroups: comp.protocols.tcp-ip
From: liza@panix.com (Liza Gouger)
Subject: TCP/IP & SNA on IBM Lan adaptor card, availability of virtual term?
Summary: Have an IBM Token Ring, need to telnet to VMS/Unix boxes
Keywords: TCP/IP SNA LAN IBM Token Ring Telnet
Organization: PANIX Public Access Unix, NYC
Date: Thu, 7 Jan 1993 18:11:48 GMT

Hi, I'm posting this for a friend, Please reply to
alen@crash.cts.com or post here (where he will look).

Alen's request for information...
I have a bunch of 486s running OS/2 connected via an IBM Token Ring
(using a LAN Adaptor card in each). The main node in this net will
be connected to a central machine (via ethernet and TCP/IP). I need
to access terminal sessions on the central machine from any of the 486s.
The central machine is likely to be a VAX w/VMS but may turn out (in some
cases) to be an IBM connected via SNA (LU6.2 capable).

Given these 2 scenarios, can anyone out there in NetLand advise me where
to look for bridging software across the OS/2 (NetBios) -> TCP/IP
VAX and across OS/2 (NetBios) -> SNA?

What kind of hardware requirements are there?

The main interest is in getting live terminal sessions from OS/2
PM windows on each PC node. There is some need for file and/or data
transfer, so leaving these options open would be a plus.

Thanks in advance
--alen (trying to turn a Sparc into a Flame)
alen@crash.cts.com

Newsgroups: comp.protocols.tcp-ip
From: jpc@avdms8.msfc.nasa.gov (J. Porter Clark)
Subject: Who used TNAMED (IEN-116) any more?  And why?
Organization: NASA/MSFC
X-Newsreader: NN version 6.4.19
Distribution: na
Date: 11 Jan 93 18:05:41 GMT

I've noticed (via log_tcp) a few random connections from a couple of
machines to the obsolete (or so I thought) IEN-116 trivial name service
port.

Jan 11 09:42:01 avdms8 in.tnamed[2874]: connect from ...

At the time, I didn't have this service turned off, so I presume the
machines in questions had a successful connect.

Who would want to use trivial name service?

Sun's man page for in.tnamed doesn't mention any clients which use this
service.  There is a nod in the direction of uucp in the SEE ALSO area,
but the man page it refers to doesn't mention any sort of name
service.

Is there a client program to access this service?  I'd be interested in
seeing what these machines got from me, if anything.

Yes, I plan to ask the owners of these machines what they are doing.
--
J. Porter Clark    jpc@avdms8.msfc.nasa.gov or jpc@gaia.msfc.nasa.gov
NASA/MSFC Flight Data Systems Branch
Newsgroups: comp.protocols.tcp-ip
From: imp@boulder.parcplace.com (Warner Losh)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject: Re: TELNET terminal types
Keywords: telnet terminal option rfc1060
Date: 11 Jan 93 22:17:19 GMT
Organization: ParcPlace Boulder

In article <jcmorris.726603002@mwunix> jcmorris@mwunix.mitre.org (Joe
Morris) writes: 
> In particular, in the terminal-type options
>negotiation (per RFC 1091) the Wollongong product is delivering the text
>string:
>
>    DEC-VT100

This is a conforming implementation.

>The trouble is that none of our UNIX boxes (typically running SUN-OS,
>IBM's AIX (RS-6000), or Silicon Graphics' IRIX) have the faintest
>idea what to do with this terminal type; their terminfo files expect
>something like "vt100".  One problem is that RFC 1060 does not include
>any terminal types of the form "VTxxx".

This is not a conforming implementation.

>So...any comments?  Is Wollongong alone in adhering to RFC 1060, or do
>the UNIX vendors say "RFC's aren't legal standards", or have I missed
>some obvious point here?

I've seen other things that adhere to the RFC 1060 standards wrt
terminal type.  I think that Multinet does as does the TOPS-20
implementation, but I could be wrong on either of these.

All that the unix telnet client is doing is pushing across the wire
the setting of TERM.  There is no attempt to map terminals into the
"standard" types and then back again.  In fact, I use this trick to
push across DISPLAY and terminal size information to less than robust
implementations of telnet (that do do terminal type stuff).

Your best bet would be to create aliases for DEC-VTxxx in the termcap
and terminfo databases.  This is a kludge, at best, but would solve
the problem of telnetting to the unix box from the PC.

Warner
-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.
Newsgroups: comp.protocols.tcp-ip
Subject: Re: time outs in FIN-WAIT2??
From: duncan@comp.vuw.ac.nz (Duncan McEwan)
Date: Sun, 10 Jan 1993 22:48:44 GMT
Organization: Comp Sci, Victoria University, Wellington, New Zealand

In article <1993Jan9.164215.20972@jupiter.sun.csd.unb.ca> dedgar@mta.ca writes:
>
>I interpret this problem to mean that the other side has timed out or retried
>out in fin-wait2. Is this a valid assumption. Does tcp-ip software do this?

I'm not sure if this is what you are seeing, but pg 365 of "The Design and
Implementation of the 4.3BSD UNIX Operating System", describes how 4.3
BSD also starts the 2*MSL timer when in FIN_WAIT_2 state if the local
process has closed.

>It sure isn't in the rfc.

It claims this is done as a work around because "certain other TCP
implementations (incorrectly) fail to send a FIN on a receive-only connection.
Connections to such hosts will remain in FIN_WAIT_2 state forever unless the
system times them out".

Duncan
From: heberlei@cs.ucdavis.edu (Louis Todd Heberlei)
Newsgroups: comp.protocols.tcp-ip
Subject: reading what you're writing on Suns
Date: 8 Jan 93 17:41:07 GMT
Reply-To: heberlei@cs.ucdavis.edu
Organization: Computer Science, University of California at Davis.

I have found while using ethernet analyzers on Sun workstations
that they do not report the packets from the same host that they
are running on.  For example, the command:

		etherfind host toadflax

should report all packets TO and FROM toadflax; however, if I am
running the analyzer on toadflax, I only see packets TO toadflax.
None of the packets FROM toadflax are reported.

Apparently a Sun cannot read the packets that it is writing to
the network.  I have two questions regarding this:

    1) Is this common with most/all workstations (non-Suns)?
    2) Is there a patch so the Sun can read it's own packets?

Any help would be appreciated.  Thanks,


Todd				heberlei@cs.ucdavis.edu
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
From: pwb@newt.phys.unsw.edu.au (Paul W. Brooks esq.)
Subject: Re: TELNET terminal types
Summary: It was
Organization: University of New South Wales
Date: Tue, 12 Jan 1993 05:44:03 GMT

In article <jcmorris.726695948@mwunix>, jcmorris@mwunix.mitre.org (Joe Morris) writes:
> trier@odin.ins.cwru.edu (Stephen C. Trier) writes:
> 
> >One solution is to modify the termcap or terminfo files, as appropriate for
> >the system, to accept dec-vt100 as a synonym for vt100.
> 
>  [other options suggested]
> 
> >I strongly recommend the first option, since one should always prefer making
> >a system RFC compliant over making its peer non-compliant.  
> 
> I fully agree with this statement, but...
> 
> The trouble is that we have several hundred hosts, few of which are under
> the control of the central DP operations.  What I would like to see is
> fixes to the default termcap/terminfo tables to be issued by all the
> UNIX vendors to make their systems RFC-compliant.  
> 
> To me, the strangest thing about this is that I can't find anything to
> suggest that the issue has been previously raised.  Perhaps the proper
> solution is to re-open the "Assigned Numbers" list and update it to
> reflect industry practice, but until either the UNIX systems are changed
> or I can convince Wollongong to change, I've got a problem.
> 
> Joe Morris / MITRE

The issue is raised periodically - I believe I posted much the same beef
about 6 months ago, about adding the Telnet termtypes into the
terminfo/termcap files for standard releases. It doesn't do much good
though - users still have to patch their own files. sigh - maybe one
day.

	This was after wrestling with a box which 'required' telnet
term-type negotiation before it would negotiate _anything_ else
- and if the client refused to negotiate termtype, the link
would be left hanging, the box would acknowledge but not act on any data
or commands sent - this from a very well known firm with a TLA for a
name. Sigh.
Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |          paul@abccomp.oz.au
Kensington NSW 2033| 
AUSTRALIA          |           Buy Australian
Xref: sparky comp.protocols.tcp-ip:5934 comp.protocols.snmp:833
From: svl@ktas.dk (Sven Larsen)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.snmp
Subject: source from "internetworking with TCP/IP" ?
Summary: Where to find source code from inetw-tcpip vol II
Keywords: SNMP TCPIP source internetworking
Date: 12 Jan 93 11:40:04 GMT
Organization: K.T.A.S.


HI!
I'am looking for information on the SNMP software presented in the book

"Internetworking With TCP/IP", vol II: Design, Implementation, and
Internals. Written by Douglas E. Comer and David L. Stevens and
published 1991 by Prentice-Hall Inc.

If anybody knows the address of a ftp-server holding this software
please let me know. 

My aim is to integrate/modify the client software part to
handle the management of the MIB 1 objects in a CISCO router.

Best regards 

Sven Larsen, KTAS, Denmark; svl@ktas.dk
From: k@hprnd.rose.hp.com (Steve Kao)
Date: Tue, 5 Jan 1993 19:51:10 GMT
Subject: Re: STARLAN 10 10BASE-T hub unit doesn't like adapters
Organization: HP Roseville Networks Division
Newsgroups: comp.protocols.tcp-ip

The main difference between StarLan10 and 10baseT is that 10bT requires
LinkBeat, and SL10 doesn't know what it is.  In a SL10 network, you need
to disable LinkBeat on all devices on the network.

- Steve Kao
Newsgroups: comp.protocols.tcp-ip
From: jbvb@vax.ftp.com  (James B. VanBokkelen)
Subject: Re: Why would a Sun take 1.5 seconds to retransmit a missed packet?
Nntp-Software: PC/TCP NNTP
Keywords: TCP retransmit
Reply-To: jbvb@ftp.com
Organization: FTP Software, Inc., Wakefield, MA
Distribution: na
Date: Fri, 08 Jan 1993 12:48:46

In article <184841@pyramid.pyramid.com> lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:

    In article <BARNETT.93Jan7091846@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes:

    >Packets are missed by the archive system, so the Sun has to retransmit
    >the missed packets. I have noticed large delays (0.5 - 1.5 seconds)
    
       Those are pretty typical numbers for TCP layer time-outs...

If so, it indicates that 1) the path is long, 2) the archive system is very
slow or 3) the sending TCP has an inferior or broken adaptive retransmit
algorithm.  TCP should retransmit in something on the order of twice the
average Round Trip Time (from send to ack).  Some implementations use exactly
2X, others combine the RTT and its standard deviation.  With the TCP in PC/TCP
for DOS on a local LAN, the retransmit timeout is typically near its floor of
166 Ms, and I don't see any significant number of unwarranted retransmits.

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

Newsgroups: comp.protocols.tcp-ip
From: dls@mentor.cc.purdue.edu (David L Stevens)
Subject: Re: Source files from TCP/IP Volume 2 Douglas E. Comer
Organization: PUCC UNIX Group
Date: Mon, 4 Jan 1993 16:17:04 GMT

	The sources to volume II of _Internetworking_with_TCP/IP_ are
copyrighted by Prentice Hall and available for sale only. You can get them
through Prentice Hall (order number 47322-3 [Sun cartridge] or 47233-2
[9-track 1600 BPI tape]), or directly from us at a higher price. I'll send
ordering information directly to you, and anyone else interested can send
me mail for details.
	And while I'm at it, the sources for volume III are available for
free via anonymous FTP to "ftp.uu.net", directory "published/books", file
"comer.internetworking3.tar.Z".
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
From: lars@spectrum.CMC.COM (Lars Poulsen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCP/IP for Tops-10
Date: 9 Jan 93 08:08:07 GMT
Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA

In article <lkrbiuINNi35@news.bbn.com>
   mckenzie@labs-n.bbn.com (Alex McKenzie) writes:
>According to Jerry Burchfiel, who was there at the time: "Bill Plummer
>and Ray Tomlinson of BBN first implemented TCP/IP on TENEX.  Thanks to
>Charles Lynn, also of BBN, it was later ported onto TOPS-20.  I think it
>skipped over TOPS-10."

The stock PDP-10s swapped segments. TENEX was a demand paged virtual
memory system, and BBN designed a memory management unit to support
that, and then implemented the system on that base. DARPA bought a lot
of them (by the standards of the time). Later, DEC built a streamlined
TENEX box and called it the DEC-system 20. The system was TENEX with
fairly minor changes, but to DEC Marketing decided to rename it TOPS-20
to underscore the similarities to TOPS-10.

The most significant DEC enhancement over TENEX, may have been
DECNET-20. Did TENEX have DECNET ?
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
From: frank@twg.com (Frank McConnell)
Subject: Re: TELNET terminal types
Organization: The Wollongong Group, Palo Alto, CA (USA)
Date: Sat, 9 Jan 1993 23:59:02 GMT

I find the following workaround helpful in dealing with mismatches
between the terminal types listed in the Assigned Numbers RFC and
those that appear in termcap or terminfo databases:

	eval `tset -s -m 'dec-vt100:vt100' -m 'network:?vt100'`

This appears in my .login on most of the Suns that I work with.

The "-m 'dec-vt100:vt100'" instructs tset to map a terminal type of
"dec-vt100" to "vt100", and the "-s" instructs tset to issue commands
to reset the terminal type in the environment.  (The later 
"-m 'network:?vt100'" instructs tset to prompt for a terminal type if the
terminal type is initially set to "network", but to assume a default
value of "vt100".  This covers cases where the TELNET client I'm using
at the time isn't reporting a terminal type; in some of those cases,
I'm TELNET-ing in from an HP terminal that is not like a VT100 and so
want to be able to specify a type of "hp".)

Hope this helps!  If you need additional help with this, feel free to
e-mail me.

-Frank McConnell, Product Engineering, The Wollongong Group
 <frank@twg.com>
Newsgroups: comp.protocols.tcp-ip
From: matt@wardsgi.med.yale.edu (Matt Healy)
Subject: Re: anonymous ftp
Followup-To: comp.protocols.tcp-ip
Organization: Yale University--Genetics
Date: Wed, 6 Jan 1993 23:03:03 GMT

In article <1993Jan6.163043.17410@walter.bellcore.com>,
maritza@espresso.bae.bellcore.com (Maritza Ramirez) wrote:
> 
> 
> Is there any RFC or other kind of documentation that may
> describe how the "anonymous ftp" works ?
> 
> Any pointers would be appreciated,
> 
> Maritza

There is a document by Tom Czarnik, called Anonymous FTP List - FAQ,
which he posts regularly to a number of newsgroups: comp.archives.admin,
comp.misc, comp.sources.wanted, alt.sources.wanted, & news.answers.

It should answer your questions.



Matt Healy
"I pretend to be a network administrator; the lab
 net pretends to work!"

matt@wardsgi.med.yale.edu
Xref: sparky comp.protocols.tcp-ip:5899 comp.protocols.tcp-ip.ibmpc:7324
From: trier@odin.ins.cwru.edu (Stephen C. Trier)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject: Re: TELNET terminal types
Date: 10 Jan 93 17:01:58 GMT
Organization: Case Western Reserve University, Cleveland OH (USA)
NNTP-Posting-Host: odin.ins.cwru.edu

One solution is to modify the termcap or terminfo files, as appropriate for
the system, to accept dec-vt100 as a synonym for vt100.

The solution used by NCSA Telnet (or was it CUTCP?) was to make the terminal
name user-configurable.

The final option (really klugey) is to assume your telnet was written in C
and use a hex editor to search for and change "DEC-VT100\0" to
"vt100\0\0\0\0\0".  (\0 represents a NUL, an 00 byte.)

I strongly recommend the first option, since one should always prefer making
a system RFC compliant over making its peer non-compliant.  The third option
should be used only as your last resort, and you should check your license to
make sure it's legally OK before doing it.

-- 
Stephen Trier                      "We want to offer you a price that you
Network software type               just can't afford to take advantage of."
Case Western Reserve University         - Sales blurb from HSC Software
trier@ins.cwru.edu
Newsgroups: comp.protocols.tcp-ip
From: wmchung@ie.cuhk.hk (chung wai man)
Subject: About image transmission protocol
Organization: Faculty of Engineering, The Chinese U. of Hong Kong
Date: Sun, 10 Jan 1993 15:16:33 GMT

Hello!

I wonder if there is any popular image transmission protocol (like 
ftp for file transfer). If so, what are they? And, is there any
document on those protocols?

Thanks!

Please mail reply to: wmchung@eng.ie.cuhk.hk

Best Regards,
W.M. Chung

Newsgroups: comp.protocols.tcp-ip
From: mathias@solomon.technet.sg (Mathias Koerber)
Subject: wanted: rpc info, primer, generator
X-Newsreader: TIN [version 1.1 PL8]
Date: Mon, 4 Jan 1993 09:35:05 GMT

I'm looking for a primer on rcp, general info and some tools and maybe
a generator to help in creating programs that use rpc.

Any pointers?

Thx alot
Happy New Year
Gong Xi Fa Cai

--
Mathias Koerber	                    | Tel: +65 / 7780066 ext 29
SW International Systems Pte Ltd    | Fax: +65 / 7779401
14 Science Park Drive #04-01        |
The Maxwell, Singapore Science Park | email: mathias@solomon.technet.sg
Singapore 0511                      |        swispl@solomon.technet.sg
-------------------------------------------------------------------------------
* Eifersucht ist eine Leidenschaft, die mit Eifer sucht, was Leiden schafft *
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: MORE ON TOOLS TO FIND ROUTING TABLES OF REMOTE HOSTS
Keywords: ripquery, rtquery
Date: 6 Jan 93 05:21:09 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <C0EtFo.FCq@exicom.OZ.AU>, ray@exicom.OZ.AU (ray) writes:
> many thanks to all those people who replied to my last post, when i asked how
> would i perform the equivalent of a remote "netstat -rn" on 
> arbitrary internet hosts.
> 
> Most people suggested SNMP. However, wouldn't this limit me to
> querying hosts running SNMP? 
> 
> I was hoping that there would be a solution which only required 
> that the gateway in question be running some routing daemon
> talking RIP (e.g. gated), which is a more common property of gateways
> than SNMP .
> 
> I vaguely remember hearing of a program called ripquery, but i can't
> find any info on it. Has anyone heard of such a thing ; would this
> do the job I just described in the previous paragraph?



There is `rtquery` source in the standard 4.3BSD distribution (I think
in the tools subdirectory of the routed subdirectory), and binary
shipped on some (at least one--guess which) vendors' workstations.

Rtquery works by sending out mostly ordinary RIP requests.
It obviously doesn't work if you are not using RIP.
It also does not work if the remote machine is picky, as cisco routers
seem to be.


Vernon Schryver,   vjs@sgi.com
Newsgroups: comp.protocols.tcp-ip
From: tclark@med.unc.edu (Thomas B. Clark III)
Subject: Setting date and time on PC
Originator: tclark@hudson
Organization: UNC-CH School of Medicine
Date: Tue, 12 Jan 1993 03:15:12 GMT

Does anyone have any experience setting the PC's date and time
from a UNIX time server using tcp/ip?
Newsgroups: comp.protocols.tcp-ip
From: dls@mentor.cc.purdue.edu (David L Stevens)
Subject: Re: time outs in FIN-WAIT2??
Organization: PUCC UNIX Group
Date: Mon, 11 Jan 1993 02:25:32 GMT

In article <C0nu19.8z7@comp.vuw.ac.nz>, duncan@comp.vuw.ac.nz (Duncan McEwan) writes:
....
> It claims this is done as a work around because "certain other TCP
> implementations (incorrectly) fail to send a FIN on a receive-only connection.
> Connections to such hosts will remain in FIN_WAIT_2 state forever unless the
> system times them out".

	It's actually worse than that, in that it doesn't require a non-
conforming TCP to break things. When you're in FIN_WAIT_2, all data you've
sent has been acknowledged and the user has already done a close(). All
you're waiting for is the FIN from the other side. If the other machine
crashes, there isn't anything to cause you to delete the entry or ever
resend another packet, so the TCB will hang around forever.
	In old 4.2 BSD implementations, these used to collect until a reboot
was required to get back the resources they were holding. Adding the timer
prevents that, but has its own problems. Having a timer, but a long one,
is a compromise. Our Berkeley derivatives timeout after 30 minutes, which
is probably long enough; the #define is still named "TCPT_2MSL" (RFC 793
says 2MSL'd be 4 minutes).
	If I remember right, the original poster said 10 seconds-- a good
implementation will restart the TIME_WAIT timer each time it receives a
segment, so it really is timing the "dead interval" when the other side may
have crashed. Fixing that (or asking the vendor to) may be the solution.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
Newsgroups: comp.protocols.tcp-ip