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