Lines Matching full:packet

21 IpExtInOctets. It will be increased even if the packet is dropped
64 for the same packet, you might find that IpInReceives count 1, but
69 Defined in `RFC1213 ipInHdrErrors`_. It indicates the packet is
85 This counter means the packet is dropped when the IP stack receives a
86 packet and can't find a route for it from the route table. It might
95 raw socket, kernel will always deliver the packet to the raw socket
102 For IPv4 packet, it means the actual data size is smaller than the
107 Defined in `RFC1213 ipInDiscards`_. It indicates the packet is dropped
115 Defined in `RFC1213 ipOutDiscards`_. It indicates the packet is
122 Defined in `RFC1213 ipOutNoRoutes`_. It indicates the packet is
137 would be increased even if the ICMP packet has an invalid type. The
193 Echo packet, they are IcmpInEchos and IcmpOutEchos. Their meanings are
194 straightforward. The 'In' counter means kernel receives such a packet
195 and the 'Out' counter means kernel sends such a packet.
206 For example, if the Linux kernel sends an ICMP Echo packet, the
208 packet, IcmpMsgInType0 would increase 1.
212 This counter indicates the checksum of the ICMP packet is
214 before updating IcmpMsgInType[N]. If a packet has bad checksum, the
224 When an error occurs in the ICMP packet handler path, these two
225 counters would be updated. The receiving packet path use IcmpInErrors
226 and the sending packet path use IcmpOutErrors. When IcmpInCsumErrors
234 receives an ICMP packet, kernel follows below logic:
239 4. handle the packet depending on the type, if has any error, update
261 address. It might happen if the packet is a multicast or broadcast
262 packet, or the NIC is in promiscuous mode. In these situations, the
277 GSO, so if a packet would be split to 2 by GSO, TcpOutSegs will
310 a bigger one. This counter increase 1 for every packet merged in such
345 TCP socket is in LISTEN state, and kernel need to drop a packet,
390 When the TCP stack wants to retransmit a packet, and finds that packet
391 is not lost in the network, but the packet is not sent yet, the TCP
393 might happen if a packet stays too long time in a qdisc or driver
398 The socket receives a RST packet in Establish or CloseWait state.
415 When kernel receives a TCP packet, it has two paths to handler the
416 packet, one is fast path, another is slow path. The comment in kernel
448 If a packet set ACK flag and has no data, it is a pure ACK packet, if
455 If a TCP packet has data (which means it is not a pure ACK packet),
456 and this packet is handled in the fast path, TcpExtTCPHPHits will
517 for the fin packet from the other side, kernel could send a RST and
536 increase in packet delay. For detail information, please refer the
537 `Hybrid Slow Start paper`_. Either ACK train length or packet delay
558 How many times the packet delay threshold is detected.
562 The sum of CWND detected by packet delay. Dividing this value by
564 packet delay.
594 A packet was acknowledged by SACK, but the receiver has dropped this
595 packet, so the sender needs to retransmit this packet. In this
597 could drop a packet which has been acknowledged by SACK, although it is
600 the RTO expires for this packet, then the sender assumes this packet
605 The reorder packet is detected by fast recovery. It would only be used
608 the original retransmitted packet is not lost, it is just out of
610 retransmitted packet, another for the arriving of the original out of
611 order packet. Thus the sender would find more ACks than its
616 The reorder packet is detected when a hole is filled. E.g., assume the
617 sender sends packet 1,2,3,4,5, and the receiving order is
618 1,2,4,5,3. When the sender receives the ACK of packet 3 (which will
620 1: (1) if the packet 3 is not re-retransmitted yet. (2) if the packet
621 3 is retransmitted but the timestamp of the packet 3's ACK is earlier
626 The reorder packet detected by SACK. The SACK has two methods to
628 sender sends the same packet more than one times. And the only reason
629 is the sender believes an out of order packet is lost so it sends the
630 packet again. (2) Assume packet 1,2,3,4,5 are sent by the sender, and
631 the sender has received SACKs for packet 2 and 5, now the sender
632 receives SACK for packet 4 and the sender doesn't retransmit the
633 packet yet, the sender would know packet 4 is out of order. The TCP
639 The TCP stack wants to retransmit a packet and the congestion control
644 The TCP stack wants to retransmit a packet and the congestion control
649 A SACK points out that a retransmission packet is lost again.
653 The TCP stack tries to deliver a retransmission packet to lower layers
658 The TCP stack retransmits a SYN packet.
664 duplications: (1) a packet which has been acknowledged is
665 duplicate. (2) an out of order packet is duplicate. The TCP stack
673 The TCP stack receives a duplicate packet which has been acked, so it
678 The TCP stack receives an out of order duplicate packet, so it sends a
684 duplicate packet is received.
689 duplicate packet is received.
715 DSACK block, the reason might be that the packet is duplicated in the
718 will be updated. As implied in its name, it might be an old packet.
748 The TCP layer receives an out of order packet and has enough memory
753 The TCP layer receives an out of order packet but doesn't have enough
759 The received out of order packet has an overlay with the previous
760 packet. the overlay part will be dropped. All of TcpExtTCPOFOMerge
788 would only be skipped if the received packet is either a SYN packet or
799 to send an ACK. E.g., the TCP stack receives the same SYN packet
800 repeately, the received packet does not pass the PAWS check, or the
801 received packet sequence number is out of window. In these scenarios,
866 packet count in the network. For more details, please refer the
873 A delayed ACK timer expires. The TCP stack will send a pure ACK packet
887 It will be updated when the TCP stack receives a packet which has been
889 triggered by other reasons, such as a packet is duplicated in the
894 TLP is an algorithm which is used to detect TCP packet loss. For more
901 A TLP probe packet is sent.
905 A packet loss is detected and recovered by TLP.
917 When the TCP stack receives an ACK packet in the SYN-SENT status, and
918 the ACK packet acknowledges the data in the SYN packet, the TCP stack
926 the other side doesn't acknowledge the data in the SYN packet. (2) The
927 SYN packet which has the TFO cookie is timeout at least once. (3)
978 updated, the received packet won't be treated as a SYN cookie and the
1015 The TCP stack tries to discard packet on the out of order queue.
1039   1 packets transmitted, 1 received, 0% packet loss, time 0ms
1059 The Linux server sent an ICMP Echo packet, so IpOutRequests,
1064 increased 1. The default ping data size is 48, so an ICMP Echo packet
1065 and its corresponding Echo Reply packet are constructed by:
1106 SYN, sent SYN+ACK, received ACK, so server sent 1 packet, received 2
1113 ACK, so client sent 2 packets, received 1 packet, TcpInSegs increased
1205 exactly the same: the client sent a packet to the server, the server
1223 In the first nstat output of client side, the client sent a packet, server
1227 In the second nstat output of client side, the client sent a packet again,
1236 and the packet received from client qualified for fast path, so it
1263 packet, and the TCP layer has acked this packet, but the application didn't
1471 We use '-i' to come into the interactive mode, then a packet::
1476 Send a packet again::
1496 the second packet arrived at server, the first packet was still in
1563 We want to let sever A send a packet to 8.8.8.8, and route the packet
1564 to server B. When server B receives such packet, it might send a ICMP
1588 re-send the SYN packet if it didn't receive a SYN+ACK, we could find
1622 We enabled IP forwarding on server B, when server B received a packet
1624 this packet. We have deleted the default route, there was no route for
1653 Run tcpdump to capture a SYN packet::
1664 command to capture a SYN packet. A linux server might use hardware
1675 On nstat-a, we blocked the packet from port 9000, or nstat-a would send
1715 Send the SYN packet twice::
1732 window. The linux TCP stack would avoid to skip if the packet has
1733 data, so we need a pure ACK packet. To generate such a packet, we
1737 TcpExtTCPACKSkippedSeq via this packet.
1761 On nstat-b, send a packet via the port 9001 socket. E.g. we sent a
1782 Now the /tmp/seq.pcap is the packet we need. Send it to nstat-b::