Please, avoid top-posting, thanks :-)
There is information about debugging in the wiki [0], and is rather
easy to use.
[0]
https://wiki.nftables.org/wiki-nftables/index.php/Ruleset_debug/tracing
Okay :)
I added all the debug logs I can think of:
table ip filter {
chain filter-prerouting-0 {
type filter hook prerouting priority 0; policy accept;
ip protocol icmp nftrace set 1
}
chain test2 {
type filter hook forward priority 0; policy accept;
ip protocol icmp nftrace set 1
}
chain test-200 {
type filter hook prerouting priority 200; policy accept;
ip protocol icmp nftrace set 1
}
chain test-m500 {
type nat hook prerouting priority -500; policy accept;
ip protocol icmp nftrace set 1
}
chain test-500 {
type filter hook prerouting priority 500; policy accept;
ip protocol icmp nftrace set 1
}
chain forward-0 {
type filter hook forward priority 0; policy accept;
ip protocol icmp nftrace set 1
}
chain forward-m500 {
type filter hook forward priority -500; policy accept;
ip protocol icmp nftrace set 1
}
}
and the packets go missing between test-500 and forward-m500 also the
test-m500 chain is never hit (nat).
Sorry for the names, I tried to rename them with:
nft rename chain ip filter test filter-prerouting-0
<cmdline>:1:1-47: Error: Could not process rule: No such file or
directory
rename chain ip filter test filter-prerouting-0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
nft monitor logs:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
daddr 18:a9:05:79:73:6e ip saddr 10.21.13.5 ip daddr 10.253.10.12 ip
dscp cs0 ip ecn not-ect ip ttl 63 ip id 24831 ip length 84 icmp type
echo-request icmp code 0 icmp id 21685 icmp sequence 1
trace id 42c618bd ip filter test2 rule ip protocol icmp nftrace set 1
(verdict continue)
trace id 42c618bd ip filter test2 verdict continue
trace id 42c618bd ip filter test2
trace id 42c618bd ip filter forward-0 packet: iif eth0 oif kube-bridge
ether saddr 9c:8e:99:0f:7e:46 ether daddr 18:a9:05:79:73:6e ip saddr
10.21.13.5 ip daddr 10.253.10.12 ip dscp cs0 ip ecn not-ect ip ttl 63 ip
id 24831 ip length 84 icmp type echo-request icmp code 0 icmp id 21685
icmp sequence 1
trace id 42c618bd ip filter forward-0 rule ip protocol icmp nftrace set
1 (verdict continue)
trace id 42c618bd ip filter forward-0 verdict continue
trace id 42c618bd ip filter forward-0
trace id a1f8a919 ip filter test packet: iif kube-bridge ether saddr
0a:58:0a:fd:0a:0c ether daddr 0a:58:0a:fd:0a:01 ip saddr 10.253.254.236
ip daddr 10.21.13.5 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 18916 ip
length 84 icmp type echo-reply icmp code 0 icmp id 21685 icmp sequence 1
trace id a1f8a919 ip filter test rule ip protocol icmp nftrace set 1
(verdict continue)
trace id a1f8a919 ip filter test verdict continue
trace id a1f8a919 ip filter test
trace id a1f8a919 ip filter test-200 packet: iif kube-bridge ether saddr
0a:58:0a:fd:0a:0c ether daddr 0a:58:0a:fd:0a:01 ip saddr 10.253.254.236
ip daddr 10.21.13.5 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 18916 ip
length 84 icmp type echo-reply icmp code 0 icmp id 21685 icmp sequence 1
trace id a1f8a919 ip filter test-200 rule ip protocol icmp nftrace set 1
(verdict continue)
trace id a1f8a919 ip filter test-200 verdict continue
trace id a1f8a919 ip filter test-200
trace id a1f8a919 ip filter test-500 packet: iif kube-bridge ether saddr
0a:58:0a:fd:0a:0c ether daddr 0a:58:0a:fd:0a:01 ip saddr 10.253.254.236
ip daddr 10.21.13.5 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 18916 ip
length 84 icmp type echo-reply icmp code 0 icmp id 21685 icmp sequence 1
trace id a1f8a919 ip filter test-500 rule ip protocol icmp nftrace set 1
(verdict continue)
trace id a1f8a919 ip filter test-500 verdict continue
trace id a1f8a919 ip filter test-500
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
any idea where I could poke, what I could start to figure out why the
packets are dropped in the kernel?
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
