| /linux/tools/testing/selftests/net/netfilter/packetdrill/ |
| A D | conntrack_synack_reuse.pkt | 1 // Check reception of another SYN while we have an established conntrack state.
3 // state and SYN retransmit should give us new 'SYN_RECV' connection state.
8 +0 `iptables -A INPUT -m conntrack --ctstate INVALID -p tcp --tcp-flags SYN,ACK SYN,ACK`
|
| A D | conntrack_syn_challenge_ack.pkt | 1 // Check connection re-use, i.e. peer that receives the SYN answers with
|
| A D | conntrack_synack_old.pkt | 37 // with buggy conntrack above packet is dropped, so SYN rtx is seen:
|
| /linux/Documentation/networking/ |
| A D | snmp_counter.rst | 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.
329 TCPSynRetrans: number of SYN and SYN/ACK retransmits to break down
796 TCP stack receives a SYN and replies SYN+ACK. Now the TCP stack is
960 SYN cookies
962 SYN cookies are used to mitigate SYN flood, for details, please refer
1106 SYN, sent SYN+ACK, received ACK, so server sent 1 packet, received 2
1111 When the client sent SYN, the client came into the SYN-SENT state, so
1588 re-send the SYN packet if it didn't receive a SYN+ACK, we could find
[all …]
|
| A D | ip-sysctl.rst | 390 TCP SYN and SYNACK messages usually advertise an ADVMSS option,
794 overflows. This is to prevent against the common 'SYN flood attack'
799 against legal connection rate. If you see SYN flood warnings
809 SYN flood warnings in logs not being really flooded, your server
818 the initial SYN packet is received during the three-way handshake.
843 SYN packet.
847 rather than connect() to send data in SYN.
859 a SYN packet to be accepted and passed to the
861 0x4 (client) send data in the opening SYN regardless of cookie
863 0x200 (server) accept data-in-SYN w/o any cookie option present.
[all …]
|
| A D | tcp_ao.rst | 118 If the segment is a SYN, then this is the first segment of a new
216 A: [7.5.2] doesn't have the same choice as SYN packet handling in [7.5.1.i]
367 keys on a first properly signed SYN would make the request socket bigger, that
|
| A D | mptcp.rst | 48 it, the returned ``SYN+ACK`` packet will not contain MPTCP options in the TCP
|
| A D | ipvs-sysctl.rst | 108 the SYN-RECV/SYNACK state, which should be effective against
|
| /linux/tools/testing/selftests/net/packetdrill/ |
| A D | tcp_zerocopy_fastopen-client.pkt | 13 // Send a FastOpen request, no cookie yet so no data in SYN
33 // Send another Fastopen request, now SYN will have data
|
| A D | tcp_md5_md5-only-on-client-ack.pkt | 2 // Test what happens when client does not provide MD5 on SYN,
|
| A D | tcp_zerocopy_fastopen-server.pkt | 18 // Client sends a SYN with data.
|
| /linux/Documentation/driver-api/surface_aggregator/ |
| A D | ssh.rst | 8 .. |SYN| replace:: ``SYN`` substdef
93 * - |SYN|
97 A message consists of |SYN|, followed by the frame (|TYPE|, |LEN|, |SEQ| and
140 Each exchange begins with |SYN|, followed by a |DATA_SEQ|- or
165 tx: -- SYN FRAME(D) CRC(F) PAYLOAD CRC(P) -----------------------------
166 rx: ------------------------------------- SYN FRAME(A) CRC(F) CRC(P) --
175 tx: -- SYN FRAME(D) CRC(F) PAYLOAD CRC(P) -----------------------------
176 rx: ------------------------------------- SYN FRAME(N) CRC(F) CRC(P) --
184 tx: -- SYN FRAME(DATA_NSQ) CRC(F) PAYLOAD CRC(P) ----------------------
|
| /linux/tools/testing/selftests/bpf/prog_tests/ |
| A D | cls_redirect.c | 151 SYN, enumerator
199 if (test->flags == SYN) in test_str()
209 { TCP, ACCEPT, UNKNOWN_CONN, NO_HOPS, SYN },
308 if (test->flags == SYN) in build_input()
|
| /linux/tools/perf/trace/beauty/ |
| A D | msg_flags.c | 55 P_MSG_FLAG(SYN); in syscall_arg__scnprintf_msg_flags()
|
| /linux/net/ipv4/ |
| A D | Kconfig | 271 Normal TCP/IP networking is open to an attack known as "SYN
277 SYN cookies provide protection against this type of attack. If you
279 protocol known as "SYN cookies" to enable legitimate users to
282 SYN cookies work transparently to them. For technical information
283 about SYN cookies, check out <https://cr.yp.to/syncookies.html>.
285 If you are SYN flooded, the source address reported by the kernel is
290 SYN cookies may prevent correct error reporting on clients when the
294 If you say Y here, you can disable SYN cookies at run time by
|
| /linux/tools/testing/selftests/bpf/progs/ |
| A D | test_cls_redirect.c | 83 SYN, enumerator
830 return SYN; in process_tcp()
1059 case SYN: in cls_redirect()
|
| A D | test_cls_redirect_dynptr.c | 77 SYN, enumerator
723 return SYN; in process_tcp()
957 case SYN: in cls_redirect()
|
| /linux/kernel/configs/ |
| A D | hardening.config | 87 # Provides some protections against SYN flooding.
|
| /linux/net/netfilter/ |
| A D | Kconfig | 676 during SYN-flood attacks.
1127 MSS value of TCP SYN packets, to control the maximum size for that
1143 iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
1470 analyzing incoming TCP SYN packets.
1630 MSS value of TCP SYN packets, which control the maximum packet size
|
| /linux/drivers/net/ethernet/sfc/ |
| A D | tc_conntrack.c | 255 tcp_interesting_flags = EFX_NF_TCP_FLAG(SYN) | in efx_tc_ct_parse_match()
|
| /linux/net/ipv6/netfilter/ |
| A D | Kconfig | 223 during SYN-flood attacks.
|
| /linux/net/ipv4/netfilter/ |
| A D | Kconfig | 209 during SYN-flood attacks.
|
| /linux/Documentation/networking/devlink/ |
| A D | devlink-trap.rst | 460 This could include TCP checksum errors, improper combination of SYN, FIN
|
| /linux/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/ |
| A D | phy_n.c | 38 write_radio_reg(pi, radio_type##_##SYN##_##reg_name, value)
|
| /linux/ |
| A D | MAINTAINERS | 11239 K: \b(ABS|SYN)_MT_
|