At 01:44 PM 5/2/02, sam sneed wrote:
>Richard Stevens defines TCP Half CLose in his book TCP/IP Ilustrated.
>Reading this post I get the assumption that data can not be sent sent in
>either direction when a connection is half-closed.

The RFC doesn't mention a "half-closed" state, but it does say that in the 
FIN-WAIT-1 state, a host can still receive data. FIN-WAIT-1 means this side 
has sent a FIN and is awaiting an ACK and FIN from the other side. I 
suppose this could be called "half closed."

>This contradicts what I
>read in TCP/IP Ilustrated by stevens p.238-239. There he explains an example
>when a connection is half-closed and data is still sent to the side that
>closed the connection.
>
>The example is the following.
>host1%> rsh host2 sort

Your example just executes sort on host2. Why is that considered half 
closed and what is host2 sorting? I could see that there might be a case 
where you would tell another host to sort something and then you would 
consider yourself finished. But you might be waiting for feedback that the 
sort actually worked. You could send a FIN and be in the FIN-WAIT-1 state 
and still receive a message that says the sort worked. Perhaps it's 
something like that.

Priscilla

>wrote in message
>[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > At 11:08 AM 5/2/02, Mark Odette II wrote:
> > >Tamas- Thank you for your reply.
> > >
> > >Could you or anyone else explain in more indepth terms what is or what
> > >causes a Half-Closed TCP session??
> >
> > There are a number of states that a TCP connection can be in per the RFC
> > for TCP (793). "Half-closed" is not one of them, however... But my guess
>is
> > that "half-closed" refers to the state that the RFC would call
>"half-open."
> > An established connection is said to be "half-open" if one of the sides
>has
> > closed or aborted the connection at its end without the knowledge of the
> > other, or if the two ends of the connection have become desynchronized
> > because of a crash.  Such connections will automatically become reset if
>an
> > attempt is made to send data in either direction.
> >
> > Another possibility is that "half-closed" refers to one of the states
that
> > occurs at the normal end of a session:
> >
> > FIN-WAIT-1 - represents waiting for a connection termination request from
> > the remote TCP, or an acknowledgment of the connection termination
request
> > previously sent.
> >
> > FIN-WAIT-2 - represents waiting for a connection termination request from
> > the remote TCP.
> >
> > CLOSE-WAIT - represents waiting for a connection termination request from
> > the local user.
> >
> > CLOSING - represents waiting for a connection termination request
> > acknowledgment from the remote TCP.
> >
> > These states (and the half-open state) should be temporary, but if they
> > aren't, then they can leave a host slightly vulnerable to attack. The
host
> > may use up resources that it really no longer needs.
> >
> > I know this is a lot of theory to throw at you, but hopefully it will
> > relate somehow to your problem. ;-) For even more info about the TCP
> > states, see RFC 793.
> >
> > Priscilla
> >
> >
> >
> > >Correct me if I'm wrong, but for the Connection Slot, this refers to TCP
> > >connections between two nodes, such as a Windows workstation running an
> > >application to connect to a Server Application Server, and the
connectios
> > >are between specific and random ports above 1024 simultaneously!?! Do I
> > >understand that correctly?
> > >
> > >
> > >I'm sure our famous question is starting to surface in many folks'
minds:
> > >"What problem are you trying to solve?"
> > >
> > >That problem is with users on workstations at remote locations
connecting
>to
> > >an application server (located at the other end of a PIX-to-PIX VPN
>Tunnel
> > >at the "main" office) and at random, they get disconnected from the
> > >server... but Internet access continues to work at the same time.  In
>short,
> > >it appears that there is something happening with sessions across the
VPN
> > >tunnel for users that go idle for a varying window of time.  Just
>yesterday,
> > >I was reported that at one of the remote locations (and there are 3,
>which
> > >all suffer the same exact problem), one user "worked straight through
>lunch,
> > >while everyone else who used the same application went to lunch.  End
>result
> > >was that the continuous worker did not get "kicked" out of the system,
>but
> > >all the other users that left the application open and when to lunch
>did."
> > >
> > >So, I'm trying to chase down what the issue might be, short of putting a
> > >Sniffer at the main location to see if I can identify the problem there.
>I
> > >suspect that there is something I need to adjust with the Timeout
>settings
> > >on the PIX, but did not want to make changes without understanding the
> > >pros/cons/implications of what I was doing.
> > >
> > >Unfortunately, the PIX Command Reference for 6.1, CCO, and most of
>Tamas's
> > >explanation were exactly what I found, and nothing more.... Tamas, thank
>you
> > >for at least giving me a little more info!
> > >
> > >I even searched Google for a definition of "half-closed session", but
got
>no
> > >definitiion hits... just lots of pages (mostly Cisco) mentioning the
>phrase
> > >amidst other topics. :(
> > >
> > >Any help is appreciated.
> > >
> > >Thanks
> > >Mark
> > >
> > >-----Original Message-----
> > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> > >HORVATH TAMAS
> > >Sent: Thursday, May 02, 2002 7:41 AM
> > >To: [EMAIL PROTECTED]
> > >Subject: RE: Definition of terms... Do you know the answer?? [7:43090]
> > >
> > >
> > >Hi!
> > >
> > >timeout xlate: Idle time until a translation slot if freed.
> > >
> > >timeout conn: Idle time until a connection slot is freed.
> > >
> > >There is a distinction made between translated sessions (produced by
nat,
> > >global, static,  access-list, access-group commands)and connected
>sesssions
> > >when discussing the PIX firewall. Translations are at the IP layer,
> > >connections are at the transport layer. You cab have many connections
>open
> > >under one translation.
> > >
> > >timeout half-closed: Idle time until a TCP half-close connection is
>freed.
> > >
> > >timeout udp: Idle time until an UDP slot is freed.
> > >
> > >timeout rpc: Idle time until an UDP slot is freed.
> > >
> > >If a given slot has not been used for the idle time specified, the
>resource
> > >is returned to the free pool.
> > >
> > >So one purpose of these commands is resource management. Another purpose
>is
> > >to provide the 'Adaptive' part of the ASA, as the unused ports will be
> > >closed.
> > >
> > >Best regards,
> > >
> > >             Tamas Horvath
> > >             network engineer
> > >             Tel.: +36 22/515-452,
> > >             Fax: +36 22/327-532
> > >             E-Mail: [EMAIL PROTECTED]
> > >Message-ID:
> > >From: Mark Odette II
> > >Reply-To: Mark Odette II
> > >To: [EMAIL PROTECTED]
> > >Subject: Definition of terms... Do you know the answer?? [7:43090]
> > >Date: Thu, 2 May 2002 07:29:44 +0200
> > >MIME-Version: 1.0
> > >X-Mailer: Internet Mail Service (5.5.2650.21)
> > >Content-Type: text/plain; charset="iso-8859-2"
> > >
> > >Folks, I've been trying to find the answer to a couple of questions I
>have,
> > >and unfortunately, my patience is thin at the moment due to a really bad
> > >allergy attach, which in turn is making me barely be able to stay at the
> > >computer.... but I've got to solve a problem.
> > >
> > >So, could someone give me the low-down on what the following
>terms/settings
> > >really mean in relation to TCP/UDP communications?
> > >
> > >These terms are related to settings on a Firewall (PIX or Router), and
> > >explanations relating to such would really help me understand their
> > >purpose/functionality.  Thanks in Advance!!
> > >
> > >timeout xlate
> > >
> > >timeout conn
> > >
> > >timeout half-closed
> > >
> > >timeout udp
> > >
> > >timeout rpc
> > >
> > >
> > >I've got what I believe is a solid idea of what the first one, and
>perhaps
> > >the second one covers... but someone formally explaining them all will
>make
> > >me, and I'm sure many others benefit.
> > >
> > >Thanks,
> > >Mark
> > ________________________
> >
> > Priscilla Oppenheimer
> > http://www.priscilla.com
________________________

Priscilla Oppenheimer
http://www.priscilla.com




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=43173&t=43090
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to