When TCP is in TIME_WAIT state, PAWS verification uses
LINUX_PAWSESTABREJECTED, which is ambiguous and cannot be distinguished
from other PAWS verification processes.
Moreover, when PAWS occurs in TIME_WAIT, we typically need to pay special
attention to upstream network devices, so we added a new counter, like the
existing PAWS_OLD_ACK one.
Also we update the doc with previously missing PAWS_OLD_ACK.
usage:
'''
nstat -az | grep PAWSTimewait
TcpExtPAWSTimewait 1 0.0
'''
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
Documentation/networking/net_cachelines/snmp.rst | 2 ++
include/net/dropreason-core.h | 1 +
include/uapi/linux/snmp.h | 1 +
net/ipv4/proc.c | 1 +
net/ipv4/tcp_minisocks.c | 2 +-
5 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/networking/net_cachelines/snmp.rst b/Documentation/networking/net_cachelines/snmp.rst
index bc96efc92cf5..bd44b3eebbef 100644
--- a/Documentation/networking/net_cachelines/snmp.rst
+++ b/Documentation/networking/net_cachelines/snmp.rst
@@ -37,6 +37,8 @@ unsigned_long LINUX_MIB_TIMEWAITKILLED
unsigned_long LINUX_MIB_PAWSACTIVEREJECTED
unsigned_long LINUX_MIB_PAWSESTABREJECTED
unsigned_long LINUX_MIB_TSECR_REJECTED
+unsigned_long LINUX_MIB_PAWS_OLD_ACK
+unsigned_long LINUX_MIB_PAWS_TW_REJECTED
unsigned_long LINUX_MIB_DELAYEDACKLOST
unsigned_long LINUX_MIB_LISTENOVERFLOWS
unsigned_long LINUX_MIB_LISTENDROPS
diff --git a/include/net/dropreason-core.h b/include/net/dropreason-core.h
index 9701d7f936f6..bea77934a235 100644
--- a/include/net/dropreason-core.h
+++ b/include/net/dropreason-core.h
@@ -287,6 +287,7 @@ enum skb_drop_reason {
/**
* @SKB_DROP_REASON_TCP_RFC7323_TW_PAWS: PAWS check, socket is in
* TIME_WAIT state.
+ * Corresponds to LINUX_MIB_PAWS_TW_REJECTED.
*/
SKB_DROP_REASON_TCP_RFC7323_TW_PAWS,
/**
diff --git a/include/uapi/linux/snmp.h b/include/uapi/linux/snmp.h
index ec47f9b68a1b..1d234d7e1892 100644
--- a/include/uapi/linux/snmp.h
+++ b/include/uapi/linux/snmp.h
@@ -188,6 +188,7 @@ enum
LINUX_MIB_PAWSESTABREJECTED, /* PAWSEstabRejected */
LINUX_MIB_TSECRREJECTED, /* TSEcrRejected */
LINUX_MIB_PAWS_OLD_ACK, /* PAWSOldAck */
+ LINUX_MIB_PAWS_TW_REJECTED, /* PAWSTimewait */
LINUX_MIB_DELAYEDACKS, /* DelayedACKs */
LINUX_MIB_DELAYEDACKLOCKED, /* DelayedACKLocked */
LINUX_MIB_DELAYEDACKLOST, /* DelayedACKLost */
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 10cbeb76c274..ea2f01584379 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -191,6 +191,7 @@ static const struct snmp_mib snmp4_net_list[] = {
SNMP_MIB_ITEM("PAWSEstab", LINUX_MIB_PAWSESTABREJECTED),
SNMP_MIB_ITEM("TSEcrRejected", LINUX_MIB_TSECRREJECTED),
SNMP_MIB_ITEM("PAWSOldAck", LINUX_MIB_PAWS_OLD_ACK),
+ SNMP_MIB_ITEM("PAWSTimewait", LINUX_MIB_PAWS_TW_REJECTED),
SNMP_MIB_ITEM("DelayedACKs", LINUX_MIB_DELAYEDACKS),
SNMP_MIB_ITEM("DelayedACKLocked", LINUX_MIB_DELAYEDACKLOCKED),
SNMP_MIB_ITEM("DelayedACKLost", LINUX_MIB_DELAYEDACKLOST),
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index 27511bf58c0f..43d7852ce07e 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -248,7 +248,7 @@ tcp_timewait_state_process(struct inet_timewait_sock *tw, struct sk_buff *skb,
if (paws_reject) {
*drop_reason = SKB_DROP_REASON_TCP_RFC7323_TW_PAWS;
- __NET_INC_STATS(twsk_net(tw), LINUX_MIB_PAWSESTABREJECTED);
+ __NET_INC_STATS(twsk_net(tw), LINUX_MIB_PAWS_TW_REJECTED);
}
if (!th->rst) {
--
2.47.1On Mon, Apr 7, 2025 at 4:00 PM Jiayuan Chen <jiayuan.chen@linux.dev> wrote: > > When TCP is in TIME_WAIT state, PAWS verification uses > LINUX_PAWSESTABREJECTED, which is ambiguous and cannot be distinguished > from other PAWS verification processes. > > Moreover, when PAWS occurs in TIME_WAIT, we typically need to pay special > attention to upstream network devices, so we added a new counter, like the > existing PAWS_OLD_ACK one. I really dislike the repetition of "upstream network devices". Is it mentioned in some RFC ? > > Also we update the doc with previously missing PAWS_OLD_ACK. > > usage: > ''' > nstat -az | grep PAWSTimewait > TcpExtPAWSTimewait 1 0.0 > ''' > > Suggested-by: Eric Dumazet <edumazet@google.com> > Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev> Reviewed-by: Eric Dumazet <edumazet@google.com>
April 8, 2025 at 22:18, "Eric Dumazet" <edumazet@google.com> wrote: > > On Mon, Apr 7, 2025 at 4:00 PM Jiayuan Chen <jiayuan.chen@linux.dev> wrote: > > > > > When TCP is in TIME_WAIT state, PAWS verification uses > > LINUX_PAWSESTABREJECTED, which is ambiguous and cannot be distinguished > > from other PAWS verification processes. > > Moreover, when PAWS occurs in TIME_WAIT, we typically need to pay special > > attention to upstream network devices, so we added a new counter, like the > > existing PAWS_OLD_ACK one. > > > > I really dislike the repetition of "upstream network devices". > Is it mentioned in some RFC ? I used this term to refer to devices that are located in the path of the TCP connection, such as firewalls, NATs, or routers, which can perform SNAT or DNAT and these network devices use addresses from their own limited address pools to masquerade the source address during forwarding, this can cause PAWS verification to fail more easily. You are right that this term is not mentioned in RFC but it's commonly used in IT infrastructure contexts. Sorry to have caused misunderstandings. Thanks. > > > > Also we update the doc with previously missing PAWS_OLD_ACK. > > usage: > > > > ''' > > nstat -az | grep PAWSTimewait > > TcpExtPAWSTimewait 1 0.0 > > ''' > > > > Suggested-by: Eric Dumazet <edumazet@google.com> > > Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev> > > > > Reviewed-by: Eric Dumazet <edumazet@google.com> >
On Tue, 08 Apr 2025 14:57:29 +0000 Jiayuan Chen wrote: > > > When TCP is in TIME_WAIT state, PAWS verification uses > > > LINUX_PAWSESTABREJECTED, which is ambiguous and cannot be distinguished > > > from other PAWS verification processes. > > > Moreover, when PAWS occurs in TIME_WAIT, we typically need to pay special > > > attention to upstream network devices, so we added a new counter, like the > > > existing PAWS_OLD_ACK one. > > > > > > > I really dislike the repetition of "upstream network devices". > > Is it mentioned in some RFC ? > > I used this term to refer to devices that are located in the path of the > TCP connection Could we use some form of: "devices that are located in the path of the TCP connection" ? Maybe just "devices in the networking path" ? I hope that will be sufficiently clear in all contexts. Upstream devices sounds a little like devices which have drivers in upstream Linux kernel :( > such as firewalls, NATs, or routers, which can perform > SNAT or DNAT and these network devices use addresses from their own limited > address pools to masquerade the source address during forwarding, this > can cause PAWS verification to fail more easily. > > You are right that this term is not mentioned in RFC but it's commonly used > in IT infrastructure contexts. Sorry to have caused misunderstandings. -- pw-bot: cr
April 8, 2025 at 23:19, "Jakub Kicinski" <kuba@kernel.org> wrote: > > On Tue, 08 Apr 2025 14:57:29 +0000 Jiayuan Chen wrote: > > > > > When TCP is in TIME_WAIT state, PAWS verification uses > > > LINUX_PAWSESTABREJECTED, which is ambiguous and cannot be distinguished > > > from other PAWS verification processes. > > > Moreover, when PAWS occurs in TIME_WAIT, we typically need to pay special > > > attention to upstream network devices, so we added a new counter, like the > > > existing PAWS_OLD_ACK one. > > > > > > > > > I really dislike the repetition of "upstream network devices". > > Is it mentioned in some RFC ? > > > > I used this term to refer to devices that are located in the path of the > > TCP connection > > > > Could we use some form of: "devices that are located in the path of the > TCP connection" ? Maybe just "devices in the networking path" ? > I hope that will be sufficiently clear in all contexts. > > Upstream devices sounds a little like devices which have drivers in > > upstream Linux kernel :( That makes sense :). Thanks. > > > > such as firewalls, NATs, or routers, which can perform > > SNAT or DNAT and these network devices use addresses from their own limited > > address pools to masquerade the source address during forwarding, this > > can cause PAWS verification to fail more easily. > > > > You are right that this term is not mentioned in RFC but it's commonly used > > in IT infrastructure contexts. Sorry to have caused misunderstandings. > > -- > > pw-bot: cr >
© 2016 - 2026 Red Hat, Inc.