Redian新闻
>
如何terminate掉一个remote server上的tcp session?
avatar
如何terminate掉一个remote server上的tcp session?# Linux - Linux 操作系统
z*r
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里?
avatar
a*i
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里?

avatar
z*r
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...

avatar
f*y
4
Did you see any FIN and FIN-ACK packets from server after you sent RST?
avatar
z*r
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?
avatar
q*d
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.
avatar
z*r
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.

avatar
q*d
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
avatar
f*y
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
avatar
z*r
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

avatar
z*r
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

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。