为什么在接收SYN / ACK时,会向某些站点发送RST数据包

时间:2011-07-23 09:06:24

标签: networking tcp

我正在运行ArchLinux,最近遇到了这个奇怪的问题。一段时间后,连接到Google将超时,因为我的系统在从服务器接收SYN / ACK数据包时不断发送RST数据包。它与Google的其他IP和端口号相同。它也发生在yahoo.com上。

这从未发生过。我认为我的系统可能有问题,但我不记得我最近更改了系统配置。

[UPDATE]

这又发生了,我得到了以下tcpdump输出,如skjaidev所述:

$ sudo tcpdump -i eth0 "ip host 209.85.153.100"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:44:15.737180 IP 10.20.1.113.53894 > encrypted.google.com.https: Flags [S], seq 1037252805, win 14600, options [mss 1460,sackOK,TS val 33830667 ecr 0,nop,wscale 6], length 0
13:44:15.905741 IP encrypted.google.com.https > 10.20.1.113.53894: Flags [S.], seq 371070936, ack 1037252806, win 5672, options [mss 1430,sackOK,TS val 266521270 ecr 33818028,nop,wscale 6], length 0
13:44:15.905761 IP 10.20.1.113.53894 > encrypted.google.com.https: Flags [R], seq 1037252806, win 0, length 0
13:44:16.209090 IP encrypted.google.com.https > 10.20.1.113.53894: Flags [S.], seq 371070936, ack 1037252806, win 5672, options [mss 1430,sackOK,TS val 266521573 ecr 33818028,nop,wscale 6], length 0
13:44:16.209111 IP 10.20.1.113.53894 > encrypted.google.com.https: Flags [R], seq 1037252806, win 0, length 0
13:44:18.738936 IP 10.20.1.113.53894 > encrypted.google.com.https: Flags [S], seq 1037252805, win 14600, options [mss 1460,sackOK,TS val 33831568 ecr 0,nop,wscale 6], length 0
13:44:18.896373 IP encrypted.google.com.https > 10.20.1.113.53894: Flags [S.], seq 417800121, ack 1037252806, win 5672, options [mss 1430,sackOK,TS val 266524260 ecr 33818028,nop,wscale 6], length 0
13:44:18.896391 IP 10.20.1.113.53894 > encrypted.google.com.https: Flags [R], seq 1037252806, win 0, length 0
13:44:24.752266 IP 10.20.1.113.53894 > encrypted.google.com.https: Flags [S], seq 1037252805, win 14600, options [mss 1460,sackOK,TS val 33833372 ecr 0,nop,wscale 6], length 0
13:44:25.102758 IP encrypted.google.com.https > 10.20.1.113.53894: Flags [S.], seq 514770952, ack 1037252806, win 5672, options [mss 1430,sackOK,TS val 266530467 ecr 33818028,nop,wscale 6], length 0
13:44:25.102777 IP 10.20.1.113.53894 > encrypted.google.com.https: Flags [R], seq 1037252806, win 0, length 0
13:44:36.765603 IP 10.20.1.113.53894 > encrypted.google.com.https: Flags [S], seq 1037252805, win 14600, options [mss 1460,sackOK,TS val 33836976 ecr 0,nop,wscale 6], length 0
13:45:28.236165 IP 10.20.1.113.53890 > encrypted.google.com.https: Flags [P.], seq 31651351:31651378, ack 2535469155, win 279, options [nop,nop,TS val 33852417 ecr 299514426], length 27
13:45:28.236184 IP 10.20.1.113.53890 > encrypted.google.com.https: Flags [F.], seq 27, ack 1, win 279, options [nop,nop,TS val 33852417 ecr 299514426], length 0
13:45:28.426021 IP encrypted.google.com.https > 10.20.1.113.53890: Flags [F.], seq 1, ack 27, win 194, options [nop,nop,TS val 299629642 ecr 33852417], length 0
13:45:28.426044 IP 10.20.1.113.53890 > encrypted.google.com.https: Flags [.], ack 2, win 279, options [nop,nop,TS val 33852474 ecr 299629642], length 0
13:45:28.426983 IP encrypted.google.com.https > 10.20.1.113.53890: Flags [.], ack 28, win 194, options [nop,nop,TS val 299629644 ecr 33852417], length 0

3 个答案:

答案 0 :(得分:2)

我终于找到了解决方案 - 禁用TCP时间戳(sysctl net.ipv4.tcp_timestamps=0)为我解决了问题。这些数据包的时间戳似乎无效。

答案 1 :(得分:1)

注意这两个数据包的源端口,序列号等是否相同?

13:44:16.209111 IP 10.20.1.113.53894 > encrypted.google.com.https: Flags [R], seq 1037252806, win 0, length 0
13:44:18.738936 IP 10.20.1.113.53894 > encrypted.google.com.https: Flags [S], seq 1037252805, win 14600, options [mss 1460,sackOK,TS val 33831568 ecr 0,nop,wscale 6], length 0

您无法快速重用源端口。您的机器正在发生一些事情。看起来你的TCP堆栈没有看到来自服务器的任何数据包,还有其他东西正在生成RST。要么你有iptable规则,要么可能有校验和错误,完整的数据包捕获(使用-s 0 -w foo.pcap并分析wireshark中的跟踪)应该显示任何校验和错误。

答案 2 :(得分:0)

你的时钟最有可能漂移。设置NTPD以更积极地更新系统时间,以便您始终更准确。特别是如果您的系统经常进入休眠状态。时钟总会下降。