Home
last modified time | relevance | path

Searched refs:ACK (Results 1 – 20 of 20) sorted by relevance

/tools/testing/selftests/net/packetdrill/
A Dtcp_md5_md5-only-on-client-ack.pkt3 // but then does on the ACK that completes the three-way handshake.
15 // Ooh, weird: client provides MD5 option on the ACK:
22 // Now here comes the legit ACK:
A Dtcp_fast_recovery_prr-ss-ack-below-snd_una-cubic.pkt3 // In this variant we verify that the sender uses SACK info on an ACK
36 // The following ACK was reordered - delayed so that it arrives with
37 // an ACK field below snd_una. Here we check that the newly-SACKed
A Dtcp_sack_sack-shift-sacked-2-6-8-3-9-nofack.pkt45 // ACK for 1:1001 as packets from t=0.303 arrive.
49 // ACK for 1:4001 as packets from t=0.310 arrive.
53 // ACK for 1:7001 as packets from t=0.320 arrive.
56 // ACK for all data as packets from t=0.403 arrive.
A Dtcp_close_close-local-close-then-remote-fin.pkt3 // the local process calls close() first, so we send a FIN, and receive an ACK.
4 // Then we receive a FIN and ACK it.
A Dtcp_validate_validate-established-no-flags.pkt2 // Verify that established connections drop a segment without the ACK flag set.
22 // Receive a segment with ACK flag set, verify that it is enqueued.
A Dtcp_blocking_blocking-write.pkt31 // This ACK should wakeup the write(). An ACK of 35001 does not.
A Dtcp_ts_recent_invalid_ack.pkt2 // Test that we reject TS val updates on a packet with invalid ACK sequence
20 // bad packet with high tsval (its ACK sequence is above our sndnxt)
A Dtcp_ecn_ecn-uses-ect0.pkt11 // ECN handshake: send EW flags in SYN packet, E flag in SYN-ACK response
A Dtcp_slow_start_slow-start-ack-per-4pkt.pkt4 // In this variant, the receiver sends one ACK per 4 packets.
A Dtcp_nagle_https_client.pkt34 // Without disabling Nagle, this packet will not happen until the remote ACK.
A Dtcp_limited_transmit_limited-transmit-no-sack.pkt33 // We have one packet newly acked (1001:3001 were DUP-ACK'd)
A Dtcp_nagle_sendmsg_msg_more.pkt45 // Err... we relase the remaining right after the ACK? note that PUSH is reset
A Dtcp_sack_sack-shift-sacked-7-5-6-8-9-fack.pkt54 // To simplify clean-up, say we get an ACK for all data.
A Dtcp_sack_sack-shift-sacked-7-3-4-8-9-fack.pkt58 // To simplify clean-up, say we get an ACK for all data.
/tools/testing/selftests/net/netfilter/packetdrill/
A Dconntrack_synack_reuse.pkt2 // Challenge ACK is supposed to pass through, RST reply should clear conntrack
8 +0 `iptables -A INPUT -m conntrack --ctstate INVALID -p tcp --tcp-flags SYN,ACK SYN,ACK`
A Dconntrack_inexact_rst.pkt9 // 5.772212 client_ip > server_ip TCP 66 45020 > 443 [ACK] Seq=1905874048 Ack=781810658 Win=36352 …
12 // 5.788207 server_ip > client_ip TCP 66 443 > 45020 [FIN, ACK] Seq=781811916 Ack=1905874048 Win=3…
14 // 5.788479 client_ip > server_ip TCP 66 45020 > 443 [RST, ACK] Seq=1905874072 Ack=781811917 Win=3…
A Dconntrack_syn_challenge_ack.pkt2 // a challenge-ACK.
24 // Challenge ACK, old incarnation.
A Dconntrack_ack_loss_stall.pkt112 …REC=0x00 TTL=255 ID=0 PROTO=TCP SPT=34375 DPT=8080 SEQ=1 ACK=4162510439 WINDOW=257 RES=0x00 ACK PS…
A Dconntrack_synack_old.pkt12 …LEN=40 TOS=0x00 PREC=0x00 TTL=255 ID=0 PROTO=TCP SPT=8080 DPT=34500 SEQ=162602411 ACK=2124350315 ..
/tools/testing/selftests/bpf/prog_tests/
A Dcls_redirect.c152 ACK, enumerator
201 else if (test->flags == ACK) in test_str()
210 { TCP, ACCEPT, UNKNOWN_CONN, NO_HOPS, ACK },
211 { TCP, FORWARD, UNKNOWN_CONN, ONE_HOP, ACK },
212 { TCP, ACCEPT, KNOWN_CONN, ONE_HOP, ACK },
310 if (test->flags == ACK) in build_input()

Completed in 17 milliseconds