[nft PATCH] tests: shell: Fix packetpath/rate_limit for old socat

[Phil Sutter <phil@nwl.cc>]

The test would spuriously fail on RHEL9 due to the penultimate socat
call exiting 0 despite the connection being expected to fail. Florian
writes:

| It's the socat version in rhel9. With plain reject (icmp error):
|
|   read(0, "AAA\n", 8192)                  = 4
|   recvfrom(3, 0x7ffd59cf1ab0, 519, MSG_DONTWAIT, NULL, NULL) = -1
| EAGAIN (Resource temporarily unavailable)
| [..]
|   write(5, "AAA\n", 4)                    = 4
|   recvfrom(3, 0x7ffd59cf1f90, 519, MSG_DONTWAIT, NULL, NULL) = -1
| EAGAIN (Resource temporarily unavailable)
| [..]
|   read(0, "", 8192)                       = 0
|   recvfrom(3, 0x7ffd59cf1ab0, 519, MSG_DONTWAIT, NULL, NULL) = -1
| EAGAIN (Resource temporarily unavailable)
|   shutdown(5, SHUT_WR)                    = 0
|   shutdown(5, SHUT_RDWR)                  = 0
|   recvfrom(3, 0x7ffd59cf2260, 519, MSG_DONTWAIT, NULL, NULL) = -1
| EAGAIN (Resource temporarily unavailable)
|   exit_group(0)
|
| ---> indicates success, even though it did not receive any data.
[...]
| Replacing "reject" with a "reject with tcp reset" gives:
|   read(0, "AAA\n", 8192)                  = 4
|   recvfrom(3, 0x7ffcffd04220, 519, MSG_DONTWAIT, NULL, NULL) = -1
| EAGAIN (Resource temporarily unavailable)
| [..]
|   write(5, "AAA\n", 4)                    = -1 ECONNREFUSED (Connection refused)
|   recvfrom(3, 0x7ffcffd04700, 519, MSG_DONTWAIT, NULL, NULL) = -1
| EAGAIN (Resource temporarily unavailable)
| [..]                               = 10212
|   write(2, "2025/08/06 08:34:29 socat[10212]"..., 832025/08/06
| 08:34:29 socat[10212] E write(5, 0x55a4f0652000, 4): Connection
| refused
|   ) = 83
|   shutdown(5, SHUT_RDWR)                  = -1 ENOTCONN (Transport
| endpoint is not connected)
|   exit_group(1)                           = ?
|
| -> so failure is detected and the script passes.

While this is likely a bug in socat, working around it is simple so
let's tackle it on this side, too.

Note: The second chunk is sufficient to resolve the issue, probably
because the initial ruleset's rate limiter does not trigger during TCP
handshake. Adjust it anyway to keep things consistent.

Suggested-by: Florian Westphal <fw@strlen.de>
Fixes: 9352fa7fb0a31 ("test: shell: Add rate_limit test case for 'limit statement'.")
Cc: Yi Chen <yiche@redhat.com>
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
 tests/shell/testcases/packetpath/rate_limit | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/shell/testcases/packetpath/rate_limit b/tests/shell/testcases/packetpath/rate_limit
index 10cb8f422b1a6..e0a8abc96ae3d 100755
--- a/tests/shell/testcases/packetpath/rate_limit
+++ b/tests/shell/testcases/packetpath/rate_limit
@@ -55,7 +55,7 @@ table ip filter {
 		ip protocol tcp  counter jump in_tcp
 	}
 	chain in_tcp {
-		iifname "s_c" tcp dport 80 ct state new add @http1 { tcp dport . ip saddr limit rate over 1/minute burst 5 packets } counter reject
+		iifname "s_c" tcp dport 80 ct state new add @http1 { tcp dport . ip saddr limit rate over 1/minute burst 5 packets } counter reject with tcp reset
 		iifname "s_c" tcp dport 80 counter accept
 	}
 
@@ -120,7 +120,7 @@ assert_pass result "flush chain"
 ip netns exec $S $NFT flush set filter http1
 assert_pass result "flush set"
 
-ip netns exec $S $NFT add rule filter in_tcp iifname s_c tcp dport 80 ct state new add @http1 { tcp dport . ip saddr limit rate over 1/second burst 1 packets} counter reject
+ip netns exec $S $NFT add rule filter in_tcp iifname s_c tcp dport 80 ct state new add @http1 { tcp dport . ip saddr limit rate over 1/second burst 1 packets} counter reject with tcp reset
 assert_pass result "add rule limit rate over 1/second burst 1"
 ip netns exec $S $NFT add rule filter in_tcp iifname s_c tcp dport 80 counter accept
 
-- 
2.49.0