Linux有没有办法记录发送TCP RST数据包的原因？

Question

运行这个版本的内核4.11.8-1.el6.elrepo.x86_64，并想知道为什么TCP栈会发送一些RST包，例如，是否有与BSD对应的net.inet.tcp.log_debug=1

以下是需要原因的情况之一。在握手的最终到达ACK之后立即发送RST。可以看出，SYN丢失了几次，最后一个ACK到达的时间不超过1秒。但仍不清楚为什么要发送RST。禁用syn cookie无济于事。

15:27:41.166799 IP CLIENT.16537 > SERVER.80: Flags [S], seq 1397492268, win 29200, options [mss 1440,sackOK,TS val 1230199 ecr 0,nop,wscale 6], length 0
15:27:41.166820 IP SERVER.80 > CLIENT.16537: Flags [S.], seq 1773519351, ack 1397492269, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 9], length 0
15:27:42.069572 IP CLIENT.16537 > SERVER.80: Flags [S], seq 1397492268, win 29200, options [mss 1460,sackOK,TS val 1230299 ecr 0,nop,wscale 6], length 0
15:27:42.069590 IP SERVER.80 > CLIENT.16537: Flags [S.], seq 1773519351, ack 1397492269, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 9], length 0
15:27:43.123141 IP SERVER.80 > CLIENT.16537: Flags [S.], seq 1773519351, ack 1397492269, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 9], length 0
15:27:44.067228 IP CLIENT.16537 > SERVER.80: Flags [S], seq 1397492268, win 29200, options [mss 1460,sackOK,TS val 1230499 ecr 0,nop,wscale
 6], length 0
15:27:44.067240 IP SERVER.80 > CLIENT.16537: Flags [S.], seq 1773519351, ack 1397492269, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 9], length 0
15:27:46.547072 IP CLIENT.16537 > SERVER.80: Flags [.], ack 1, win 457, length 0
15:27:46.547094 IP SERVER.80 > CLIENT.16537: Flags [R], seq 1773519352, win 0, length 0
15:27:46.548177 IP CLIENT.16537 > SERVER.80: Flags [.], ack 1, win 457, options [nop,nop,sack 1 {0:1}], length 0
15:27:46.548186 IP SERVER.80 > ClIENT.16537: Flags [R], seq 1773519352, win 0, length 0

谢谢你的帮助。

Answer 1

这个确切的功能不可用，这可以通过查看调用tcp_send_active_reset的代码来看到。在code中如下所示：

int tcp_disconnect(struct sock *sk, int flags)
{
    ...
    int old_state = sk->sk_state;

    if (old_state != TCP_CLOSE)
        tcp_set_state(sk, TCP_CLOSE);

    if ...
    } else if (tcp_need_reset(old_state) ||
           (tp->snd_nxt != tp->write_seq &&
            (1 << old_state) & (TCPF_CLOSING | TCPF_LAST_ACK))) {
        /* The last check adjusts for discrepancy of Linux wrt. RFC
         * states
         */
        tcp_send_active_reset(sk, gfp_any());

所示的多个原因中的哪一个导致RST没有被提供给任何调试宏，并且没有被提供给tcp_send_active_reset。

Linux4.15添加了跟踪点，包括this blog entry中记录的tcp:tcp_send_reset。对于许多重置，可以从函数和跟踪点的动态探测器中提取状态，以与内核相同的方式进行检查，并推断其选择的原因。这很重要，因为在我的示例中，重置可能源自何处，套接字在使用tcp:tcp_send_reset探测器执行函数之前已经更改了状态，因此必须结合使用一个在调用tcp_disconnect()或tcp_set_state()时检查sk->sk_state的动态探测器来获取old_state，以及在tcp_send_active_reset中的跟踪点上的一个探测器，以确认重置是在特定套接字上发送的。