Documentation/networking/snmp_counter.rst

275 it excludes the retransmitted packets. But it includes the SYN, ACK
286 It means the TCP layer sends a SYN, and come into the SYN-SENT
296 It means the TCP layer receives a SYN, replies a SYN+ACK, come into
297 the SYN-RCVD state.
320   retransmission but including data-in-SYN). This counter is different from
329   TCPSynRetrans: number of SYN and SYN/ACK retransmits to break down
330   retransmissions into SYN, fast-retransmits, timeout retransmits, etc.
337   TCPFastOpenActiveFail: Fast Open attempts (SYN/data) failed because
344 When kernel receives a SYN from a client, and if the TCP accept queue
345 is full, kernel will drop the SYN and add 1 to TcpExtListenOverflows.
356 queue is full. On the old kernel, TCP stack won't drop the SYN, it
359 half open queue, TCP stack will send SYN+ACK on an exponential backoff
660 The TCP stack retransmits a SYN packet.
792 would only be skipped if the received packet is either a SYN packet or
800 TCP stack receives a SYN and replies SYN+ACK. Now the TCP stack is
803 to send an ACK. E.g., the TCP stack receives the same SYN packet
921 When the TCP stack receives an ACK packet in the SYN-SENT status, and
922 the ACK packet acknowledges the data in the SYN packet, the TCP stack
930 the other side doesn't acknowledge the data in the SYN packet. (2) The
931 SYN packet which has the TFO cookie is timeout at least once. (3)
964 SYN cookies
966 SYN cookies are used to mitigate SYN flood, for details, please refer
967 the `SYN cookies wiki`_.
973 It indicates how many SYN cookies are sent.
977 How many reply packets of the SYN cookies the TCP stack receives.
981 The MSS decoded from the SYN cookie is invalid. When this counter is
982 updated, the received packet won't be treated as a SYN cookie and the
996 The number of challenge acks sent in response to SYN packets. After
1108 When the server received the first SYN, it replied a SYN+ACK, and came into
1109 SYN-RCVD state, so TcpPassiveOpens increased 1. The server received
1110 SYN, sent SYN+ACK, received ACK, so server sent 1 packet, received 2
1115 When the client sent SYN, the client came into the SYN-SENT state, so
1116 TcpActiveOpens increased 1, the client sent SYN, received SYN+ACK, sent
1531 will drop the SYN if the accept queue is full. If the nc client is running
1550 the SYN of the 4th nc was dropped, the client was retrying.
1592 re-send the SYN packet if it didn't receive a SYN+ACK, we could find
1649 In this test, we send 3 same SYN packets from client to server. The
1650 first SYN will let server create a socket, set it to Syn-Recv status,
1651 and reply a SYN/ACK. The second SYN will let server reply the SYN/ACK
1653 third SYN will let server check the previous duplicate ACK reply time,
1657 Run tcpdump to capture a SYN packet::
1668 command to capture a SYN packet. A linux server might use hardware
1684 Send 3 SYN repeatedly to nstat-b::
1697 To trigger PAWS, we could send an old SYN.
1704 On nstat-a, run tcpdump to capture a SYN::
1714 Now the tcpdump has captured the SYN and exit. We should fix the
1719 Send the SYN packet twice::
1728 We sent two SYN via tcpreplay, both of them would let PAWS check
1729 failed, the nstat-b replied an ACK for the first SYN, skipped the ACK
1730 for the second SYN, and updated TcpExtTCPACKSkippedPAWS.