z**r
发帖数: 17771 | 1 【 以下文字转载自 EmergingNetworking 讨论区 】
发信人: zher (民工.铜豌豆), 信区: EmergingNetworking
标 题: 如何terminate掉一个remote server上的tcp session？
发信站: BBS 未名空间站 (Thu Mar 19 16:29:41 2009), 站内
用hping和bittwist发了RST过去到server上tcp port，没有反应。有什么办法？这种
half-open connection，已经terminated的一端，有什么办法可以send data到对方还
open的session里？ | a*****i
发帖数: 4391 | 2
Server tcp should terminate automatically, after select failed.
But depends on how long you were asking select to wait...
【在 z**r 的大作中提到】
: 【 以下文字转载自 EmergingNetworking 讨论区 】
: 发信人: zher (民工.铜豌豆), 信区: EmergingNetworking
: 标 题: 如何terminate掉一个remote server上的tcp session？
: 发信站: BBS 未名空间站 (Thu Mar 19 16:29:41 2009), 站内
: 用hping和bittwist发了RST过去到server上tcp port，没有反应。有什么办法？这种
: half-open connection，已经terminated的一端，有什么办法可以send data到对方还
: open的session里？
| z**r
发帖数: 17771 | 3 usually yes, but I changed the timeout to 0...
【在 a*****i 的大作中提到】
:
: Server tcp should terminate automatically, after select failed.
: But depends on how long you were asking select to wait...
| f**y
发帖数: 138 | 4 Did you see any FIN and FIN-ACK packets from server after you sent RST? | z**r
发帖数: 17771 | 5 no. this is not the typical 4-way termination, so I don't think I'm supposed
to see FIN/FIN-ACK?
【在 f**y 的大作中提到】
: Did you see any FIN and FIN-ACK packets from server after you sent RST?
| q**d
发帖数: 16 | 6 If I understand OP's question correctly, the remote site is in time_wait
state, and there is nothing client can do to make the remote TCB to CLOSED
state
however, client application can avoid it by closing the TCP connection
before server does, or, on server, change time_wait timeout. | z**r
发帖数: 17771 | 7 time_wait是server发了FIN，在等FIN-ACK吧？最多几分钟就timeout了，应该不是这个。
俺还是回去再读一遍TCP RFC好了，很多年不写程序了，这些细节都忘差不多了
CLOSED
【在 q**d 的大作中提到】
: If I understand OP's question correctly, the remote site is in time_wait
: state, and there is nothing client can do to make the remote TCB to CLOSED
: state
: however, client application can avoid it by closing the TCP connection
: before server does, or, on server, change time_wait timeout.
| q**d
发帖数: 16 | 8 right. which ever make an active close would be in time_wait for timeout,
and I believ so_linger can skip the timeout. anyway check the conn state
another possiblilty, connection is broken w/o FIN received by server, and
there is no TX data to send - that is, server may not know conn is broken
for long time unless 1) keep_alive is enabled and 2)client firewall not
ignoring invalid tcp packet.
Hope it helps | f**y
发帖数: 138 | 9 When you construct a TCP RST packet, you may have to match the seq, ack as
well as src/dst IP and port with the existing TCP session, otherwise the
server may ignore the packet.
Regarding the time out, the linux system default TCP keepalive is 2 hours.
The application can not rely on 'select' or 'recv' to determine if the other
end of the socket is closed. It is simply too long. On the other hand, the
application can send packets periodically and catch the SIG_PIPE signal to
forcefully determine | z**r
发帖数: 17771 | 10 I understand what you are saying, my issue was I don't have the access to
the server, and the session was broken by accident, so yes the server didn't
know the session was broken. I know eventually the timeout will kick in, no
matter it's from the sever itself side or any layer 4 or above device in
between, but my question was how I can terminate this session...
【在 q**d 的大作中提到】
: right. which ever make an active close would be in time_wait for timeout,
: and I believ so_linger can skip the timeout. anyway check the conn state
: another possiblilty, connection is broken w/o FIN received by server, and
: there is no TX data to send - that is, server may not know conn is broken
: for long time unless 1) keep_alive is enabled and 2)client firewall not
: ignoring invalid tcp packet.
: Hope it helps
| z**r
发帖数: 17771 | 11
I didn't know I need the seq number matching up, hmm ... good point, I'll
give it a try
other
the
【在 f**y 的大作中提到】
: When you construct a TCP RST packet, you may have to match the seq, ack as
: well as src/dst IP and port with the existing TCP session, otherwise the
: server may ignore the packet.
: Regarding the time out, the linux system default TCP keepalive is 2 hours.
: The application can not rely on 'select' or 'recv' to determine if the other
: end of the socket is closed. It is simply too long. On the other hand, the
: application can send packets periodically and catch the SIG_PIPE signal to
: forcefully determine
|
|
