tests: shell: Fix packetpath/rate_limit for old socat

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>

diff --git a/tests/shell/testcases/packetpath/rate_limit b/tests/shell/testcases/packetpath/rate_limit
index 10cb8f422b1a66635df404811e9ae211184d2c50..e0a8abc96ae3d00cd87bdf415edc09a2071dc95c 100755 (executable)
--- 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