old pack problem about tcp fin_wait2 ?

[Terry Tan]

Hi all,

for tcp status fin_wait2, i have a question, which is , if a client of fin_wait2 status can still receive old pack and process them ?

[Jorgen Grahn]

Post by Terry Tan
Hi all,
for tcp status fin_wait2, i have a question, which is , if a client
of fin_wait2 status can still receive old pack and process them ?

You mean "if A is in FIN_WAIT_2, can its application still receive data
from B?"

As far as I can tell from Stevens' "TCP/IP illustrated: vol 1, this is
a "half-close". A has ended its stream of data to B, but the stream
in the opposite direction is intact. B may send as much as it
pleases, forever, or until A resets.

/Jorgen

[Terry Tan]

Hi Jorgen,

Thank you so much for your reply.

I mean A in state fin_wait2 has already received B's Fin request, A knows the fin_seq, here i mean A received fin request earlier than those pack whose seq is smaller than fin_seq (considering the network problem) ,which means A'acked_seq is still less than fin_seq, so A will go to state time_wait ,right? wait for those not received pack?


Another question is for server B ,when it will change to last_ack? i read the source code of linux 1.2 ,it seems after B notified an EOF to application, then the application calls tcp_close， but in tcp_close,it sends the fins request and just changes it's state to fin_wait2 ,rather than last_ack.I am confused that if the last_ack is required ,or maybe under some scenario ,it is not required ?


Jorgen Grahn於 2018年5月10日星期四 UTC+8上午6時07分54秒寫道：

Post by Jorgen Grahn

Post by Terry Tan
Hi all,
for tcp status fin_wait2, i have a question, which is , if a client
of fin_wait2 status can still receive old pack and process them ?

You mean "if A is in FIN_WAIT_2, can its application still receive data
from B?"
As far as I can tell from Stevens' "TCP/IP illustrated: vol 1, this is
a "half-close". A has ended its stream of data to B, but the stream
in the opposite direction is intact. B may send as much as it
pleases, forever, or until A resets.
/Jorgen
--
\X/ snipabacken.se> O o .

[Jorgen Grahn]

Post by Terry Tan
Hi Jorgen,
Thank you so much for your reply.
Jorgen Grahn於 2018年5月10日星期四 UTC+8上午6時07分54秒寫道：

Post by Jorgen Grahn

Post by Terry Tan
Hi all,
for tcp status fin_wait2, i have a question, which is , if a client
of fin_wait2 status can still receive old pack and process them ?

You mean "if A is in FIN_WAIT_2, can its application still receive data
from B?"
As far as I can tell from Stevens' "TCP/IP illustrated: vol 1, this is
a "half-close". A has ended its stream of data to B, but the stream
in the opposite direction is intact. B may send as much as it
pleases, forever, or until A resets.

I mean A in state fin_wait2 has already received B's Fin request,

Then I think you are misunderstanding what I wrote. In my scenario,

Post by Terry Tan
A knows the fin_seq, here i mean A received fin request earlier than
those pack

You mean "TCP segment", I think.

Post by Terry Tan
whose seq is smaller than fin_seq (considering the
network problem) ,which means A'acked_seq is still less than
fin_seq, so A will go to state time_wait ,right? wait for those not
received pack?

I don't know if it's called TIME_WAIT or not, but yes, I think it's
the same as any out-of-order reception. If A has received the byte
with sequence number #1, then receives #3, it cannot do anything about
it until it has also received #2 to fill the hole.

I don't think receiving a FIN means "let's drop everything and pretend
the data stream suddenly ended". That sounds more like what RST does.

Post by Terry Tan
Another question is for server B ,when it will change to last_ack? i
read the source code of linux 1.2 ,it seems after B notified an EOF
to application, then the application calls tcp_close， but in
tcp_close,it sends the fins request and just changes it's state to
fin_wait2 ,rather than last_ack.I am confused that if the last_ack
is required ,or maybe under some scenario ,it is not required ?

I won't try to answer that second (or third) question, but quote it in
case someone else will.

/Jorgen