Le 26/11/2014 19:13, Pablo Neira Ayuso a écrit :
How can it interpret the below output which seems buggy ?
root@vgoip:~# nft list table filter
table ip filter {
chain input {
type filter hook input priority 0;
oifname "lo" accept
ip protocol icmp accept
ct state 8 unknown unknown 0x16 [invalid type] accept
ct state { 4, 2} accept
reject with icmp type 10
}
What is the original ruleset you loaded? This should not happen. Any
relevant information regarding your testbed?
Ruleset is:
nft add table ip filter
nft add chain ip filter input { type filter hook input priority 0 \; }
nft add rule filter input meta oifname lo accept
nft add rule filter input ip protocol icmp accept
nft add rule filter input ct state new tcp dport 22 accept
nft add rule filter input ct state {established, related} accept
nft add rule filter input reject with icmp type host-prohibited
Target is a powerpc
All building is done on a x86 PC, using home built cross-compile gnu
tools (binutils, gcc, glibc, ....)
I just ran 'nft' with gdb, and I have seen something wrong with byte
ordering.
It looks like in symbolic_constant_print(), mpz_export_data() return a
strange val.
First time we get there, we get 0x800000000
Next time, we get 0x400000000
Last time, we get 0x200000000
While we expect 8(new), 4(related), 2(established)
Any idea on how I can fix that ?
Kernel 3.17.4
nftables-20141121
gmp-4.3.2
libmnl-1.0.3
libnfnetlink-1.0.1
libnftnl-20141121
libnetfilter_conntrack-1.0.4
Christophe
--
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
