Passive TCP close, final ACK *lost*.
M
In a normal TCP passive close, the local system / TCP process
receives the remote ACK,FIN, and transitions into CLOSE_WAIT
state. The local TCP process ACKs the remote ACK,FIN, and
consults the local user/application for session termination.
Once the local application informs the local TCP process it
should complete session termination, the local TCP process
sends its ACK,FIN to the remote TCP process, which then ACKs
the local ACK,FIN. Upon the local TCP process's reception
of that final remote ACK, it transitions to CLOSE for that
TCP connection.
What I haven't been able to figure out is, what happens if
that final ACK from the remote TCP process is lost? Does
the local TCP process sit in CLOSE_WAIT until the system
is reboot or TCP is otherwise restarted? Does it vary by
implementation? Is there some timer specifically for
that condition I don't know of?
Or does it use 2MSL like TIME_WAIT in an active close? All
I found online (RFCs, etc.) is that after the local TCP
process receives that final ACK, it immediately closes. No
references to a passive close making any use of 2MSL, as
TIME_WAIT does in an active close.
But now, see Douglas Comer's TCP finite state diagram on page
242 of his _Internetworking With TCP/IP_, Volume 4. At the
bottom right, you'll see that from the statement, "timeout
after 2 segment lifetimes," he draws an arrow to the last
portion of *both* the active close and the passive close.
I wish he explained that, because in every other TCP state
diagram I can find, the 2MSL is shown only in reference to
the TIME_WAIT state of the active close. I thought, then,
perhaps CLOSE_WAIT does use the 2MSL timer for reception
of the final ACK. But that's just speculation on my part.
Comer doesn't elaborate. (I'm not picking on the great
Mr. Comer, by the way. Just looking for answers.)
Thanks very much if you know the answer. (And share it. :-))
Mitch
J S
situation you are talking about occured and my computer stayed in the
Close-Wait state until I rebooted. The 2 MSL did not apply, I had the
computer up for hours because I myself was interetested in the Close-Wait
since research seems to lack details about its nature. It was windows 2000
adv serv. As a result which is common sense, no one could log into the ftp,
the port was dead. All in all I find it pretty interesting, and would like
to know of other occurences and testing on a different OS.
"M" <mitc...@yahoo.com> wrote in message
news:9db4ac93.03033...@posting.google.com...
Barry Margolin
M <mitc...@yahoo.com> wrote:
>Hi. Having a tough time figuring out the following.
>
>In a normal TCP passive close, the local system / TCP process
>receives the remote ACK,FIN, and transitions into CLOSE_WAIT
>state. The local TCP process ACKs the remote ACK,FIN, and
>consults the local user/application for session termination.
>Once the local application informs the local TCP process it
>should complete session termination, the local TCP process
>sends its ACK,FIN to the remote TCP process, which then ACKs
>the local ACK,FIN. Upon the local TCP process's reception
>of that final remote ACK, it transitions to CLOSE for that
>TCP connection.
>
>What I haven't been able to figure out is, what happens if
>that final ACK from the remote TCP process is lost? Does
>the local TCP process sit in CLOSE_WAIT until the system
>is reboot or TCP is otherwise restarted? Does it vary by
>implementation? Is there some timer specifically for
>that condition I don't know of?
You seem to have missed a state. When CLOSE is called on a TCB that's in
CLOSE-WAIT state, you transition into LAST-ACK state immediately, to wait
for the ACK of the FIN.
During this time, you continue retransmissions normally. If you don't
receive an ACK of the FIN, you retransmit it, and keep retransmitting until
the normal retransmit timer is reached. If that happens, you abort the
connection just like you would if this had happened while the connection
was in ESTABLISHED state.
--
Barry Margolin, barry.m...@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
M
Excuse me. Volume 1, 4th edition, I meant.
Mitch
Glen Herrmannsfeldt
> > But now, see Douglas Comer's TCP finite state diagram on page
> > 242 of his _Internetworking With TCP/IP_, Volume 4 ...
>
> Excuse me. Volume 1, 4th edition, I meant.
I was wondering, as I thought there were only three volumes. I didn't know
there was a fourth edition, though.
-- glen
M
> You seem to have missed a state. When CLOSE is called on a TCB
> that's in CLOSE-WAIT state, you transition into LAST-ACK state
> immediately, to wait for the ACK of the FIN.
Ah, quite right, thank you. I did miss LAST_ACK after that final
FIN is sent from the passive closing side.
> During this time, you continue retransmissions normally. If you
> don't receive an ACK of the FIN, you retransmit it, and keep
> retransmitting until the normal retransmit timer is reached.
> If that happens, you abort the connection just like you would
> if this had happened while the connection was in ESTABLISHED
> state.
That does sound reasonable. On the other hand, there's the
gentleman above who found that the CLOSE_WAITs hung until he
reboot his server. Perhaps a bug in the implementation?
But still, the point about LAST_ACK is helpful. The matter that
caused me to research this was having been asked on separate
occasions about some servers on which CLOSE_WAIT states are
accumulating such that performance becomes an issue, even to the
extent in some cases that they lock up entirely. Realizing that
the LAST_ACK state follows the FIN from the passively closing
side narrows down that problem. If they are hung in CLOSE_WAIT,
then I suppose the issue is the application/user not passing to
the local TCP process that it is prepared to close the session.
(Of course, the issue could also just be an overloaded server.)
The preponderance of my daily work stops at later 4 on the OSI
model, so I'm not well acquainted with the follow-up examination
of an application that is preventing connection closure (some
delayed queuing of the session data?). If you have thoughts
on where to look in that regard, by all means let me know. :-)
Mitch
Barry Margolin
M <mitc...@yahoo.com> wrote:
>Barry Margolin <barry.m...@level3.com> wrote in message
>news:<MMhia.1$af5...@paloalto-snr1.gtei.net>...
>
>> You seem to have missed a state. When CLOSE is called on a TCB
>> that's in CLOSE-WAIT state, you transition into LAST-ACK state
>> immediately, to wait for the ACK of the FIN.
>
>Ah, quite right, thank you. I did miss LAST_ACK after that final
>FIN is sent from the passive closing side.
>
>> During this time, you continue retransmissions normally. If you
>> don't receive an ACK of the FIN, you retransmit it, and keep
>> retransmitting until the normal retransmit timer is reached.
>> If that happens, you abort the connection just like you would
>> if this had happened while the connection was in ESTABLISHED
>> state.
>
>That does sound reasonable. On the other hand, there's the
>gentleman above who found that the CLOSE_WAITs hung until he
>reboot his server. Perhaps a bug in the implementation?
A socket in CLOSE-WAIT is waiting for something from the *local* machine,
not a network packet that might be lost. A socket goes into CLOSE-WAIT
when a FIN has been received and ACKed, and we're waiting for the local
process to call close(). If the local process isn't finished sending
all its responses, it would be wrong for TCP to close the connection out
from under it. It might be running an application that takes several hours
to produce results.
>But still, the point about LAST_ACK is helpful. The matter that
>caused me to research this was having been asked on separate
>occasions about some servers on which CLOSE_WAIT states are
>accumulating such that performance becomes an issue, even to the
>extent in some cases that they lock up entirely. Realizing that
>the LAST_ACK state follows the FIN from the passively closing
>side narrows down that problem. If they are hung in CLOSE_WAIT,
>then I suppose the issue is the application/user not passing to
>the local TCP process that it is prepared to close the session.
>(Of course, the issue could also just be an overloaded server.)
If lots of sockets are hanging around in CLOSE-WAIT it's most likely a bug
in the application.
Blakely LaCroix
after finding it that Volume missing on my library shelf.
Blakely
M wrote:
--
Blakely LaCroix
President
Wrenchman, Inc.
Phone: 651-638-9012
Fax: 651-638-9212
Email: blac...@wrenchman.com
This message contains information from Wrenchman, Inc. that may be
confidential and privileged. If you are not the intended recipient,
please refrain from any disclosure, copying, distribution, or use of
of this information and note that such actions are prohibited. If
you have received this transmission in error, please notify the sender
immediately by telephone or by replying to this transmission
M
> Thanks for clearing that up. I was just heading to Amazon
> after finding it that Volume missing on my library shelf.
But it seems that line Mr. Comer draws linking the 2MSL timer
to *both* the active and passive TCP close remains a mystery!
You lurk on Usenet, Mr. Comer? :-)
Mitch
Jieming Wang
A FIN is a result of close/shutdown, while ACK is handled
automatically by TCP layer. So CLOSE_WAIT can be held forever until 1)
the application issues close; or 2) a system reboot.
On Solaris 2.6, you can set tcp_close_wait_interval. On Solaris 7/8,
Sun dropped this option and introduced tcp_time_wait_interval which is
adopted by most Unix vendors (actually tcp_close_wait_interval
violates TCP protocol). Both values are set to 4 minutes.
But even on Solaris 2.6 the CLOSE_WAIT socket cannot not be freed if
the application still holds the socket.
FYI: One way to identify whether a packet is handled by an application
or by TCP layer (at least on Solaris):
If the sequence of the packet is increased (by 1 or by the size of the
packet last received), the packet is transmitted by TCP (i.e. ACK). If
the sequence of packet doesn't change, then the packet is transmitted
by system call (application).
-JW
M
> A FIN is a result of close/shutdown, while ACK is handled
> automatically by TCP layer. So CLOSE_WAIT can be held forever
> until 1) the application issues close; or 2) a system reboot.
the passive close, after CLOSE_WAIT, is a mystery to me.
> On Solaris 2.6, you can set tcp_close_wait_interval.
researching this, that was an error and never actually referred
to any interval for CLOSE_WAIT. Even though it was called that,
I understand it referred to TIME_WAIT anyway. Here's one source
that seems pretty good to me:
http://www.sean.de/Solaris/soltune.html#tcp_time_wait_interval
Quoting from the above: "tcp_close_wait_interval ... Even though
the parameter key contains "close_wait" in its name, the value
specifies the TIME_WAIT interval! In order to fix this kind of
confusion, starting with Solaris 7, the parameter tcp_close_wait_
interval was renamed to the correct name tcp_time_wait_interval."
> On Solaris 7/8, Sun dropped this option and introduced
> tcp_time_wait_interval which is adopted by most Unix vendors
> (actually tcp_close_wait_interval violates TCP protocol). Both
> values are set to 4 minutes.
others stating the same thing if you Google for it (funny that
"to Google" has become a verb), that change is in name only.
The parameter always did refer to TIME_WAIT.
> But even on Solaris 2.6 the CLOSE_WAIT socket cannot not be
> freed if the application still holds the socket.
enough behind a condition that causes CLOSE_WAIT resource loading
on many servers: some applications don't issue a close for sockets
in a timely fashion. I wish I could identify some high quality,
relatively succinct materials to help a network engineer who
deals more with layers 1-4 develop an understanding of such
application issues.
> FYI: One way to identify whether a packet is handled by an
> application or by TCP layer (at least on Solaris): If the
> sequence of the packet is increased (by 1 or by the size of
> the packet last received), the packet is transmitted by TCP
> (i.e. ACK). If the sequence of packet doesn't change, then
> the packet is transmitted by system call (application).
failed to explain something that sorely needs explaining. I
checked the online errata for the 4th edition; no such error
listed.
So, either I found another error in one of the most widely
hailed TCP/IP books (not that this would be a big deal!); or
it's just awfully hard to find the explanation for the role
of the 2MSL timer in the TCP passive close; or more likely
than either of those possibilities, we've missed something
obvious that Comer understands with one brain hemisphere
tied behind his back. :-)
Mitch