> >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.
I'm sorry the end of that command got cut off. The example was: host1%> rsh host2 sort wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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=43174&t=43090 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
