blob: 05edc9c7c33ebc49072898c41c92fd5bbaa9065c (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
|
#!/bin/bash
set -e
# Expose how naive cache update logic (i.e., drop cache and repopulate from
# kernel ruleset) may mess things up. The following input does:
#
# list ruleset -> populate the cache, cache->genid is non-zero
# add table ip t -> make kernel's genid increment (cache->genid remains
# unchanged)
# add table ip t2; -> first command of batch, new table t2 is added to the cache
# add chain ip t2 c -> second command of batch, triggers cache_update() which
# removes table t2 from it
$NFT -i >/dev/null <<EOF
list ruleset
add table ip t
add table ip t2; add chain ip t2 c
EOF
# The following test exposes a problem with simple locking of cache when local
# entries are added:
#
# add table ip t3 -> cache would be locked without previous update
# add chain ip t c -> table t is not found due to no cache update happening
$NFT -i >/dev/null <<EOF
add table ip t3; add chain ip t c
EOF
# The following test exposes a problem with incremental cache update when
# reading commands from a file that add a rule using the "index" keyword.
#
# add rule ip t4 c meta l4proto icmp accept -> rule to reference in next step
# add rule ip t4 c index 0 drop -> index 0 is not found due to rule cache not
# being updated
# add rule ip t4 c index 2 drop -> index 2 is not found due to igmp rule being
# in same transaction and therefore not having
# an allocated handle
$NFT -i >/dev/null <<EOF
add table ip t4; add chain ip t4 c
add rule ip t4 c meta l4proto icmp accept
EOF
$NFT -f - >/dev/null <<EOF
add rule ip t4 c index 0 drop
EOF
$NFT -f - >/dev/null <<EOF
add rule ip t4 c meta l4proto igmp accept
add rule ip t4 c index 2 drop
EOF
|