On Fri, Sep 20, 2013 at 04:01:33PM +0200, Florian Westphal wrote:
> src/nft add rule filter output meta oifname eth0
>
> doesn't work on x86. Problem is that nft declares these as
> BYTEORDER_INVALID, but when converting the string mpz_import_data
> treats INVALID like BIG_ENDIAN.
>
> [ cmp eq reg 1 0x00000000 0x00000000 0x65000000 0x00306874 ]
>
> as kernel nft_cmp_eval basically boils down to
>
> memcmp(reg, skb->dev->name, sizeof(reg) comparision fails.
>
> with patch:
> [ cmp eq reg 1 0x30687465 0x00000000 0x00000000 0x00000000 ]
Applied with small change:
Error: Byteorder mismatch: expected invalid, got host endian
add rule filter output ct helper "ftp" counter
^^^^^
I was hitting that error here. I have mangled your patch to change
endianess of the helper name, I couldn't find any other string type in
the current tree that needs to be adjusted.
> Signed-off-by: Florian Westphal <fw@xxxxxxxxx>
> ---
> On a related note:
> Instead of
> memcmp(register, devicename, strlen(register)+1) [i.e., strcmp]
> The comparision in kernel is always
> memcmp(register, dev->name, IFNAMSIZ).
>
> IOW, why does expr_evaluate_value() replace the interface names
> string length with the template length (IFNAMSIZ)?
I see, it's adjusting the expression to use the type length. I cannot
currently find a reason any reason for not changing that.
> It doesn't seem to be needed, and without it supporting
> iptables-style wildcard name match (oifname "eth+") should be quite simple.
We support this in iptables-nftables, to interpret the data from the
kernel the assumption is that if_nametoindex fails to resolve the
interface name, then it handles the interface name as an interface
wildcard. But that's a problem, if the interface is removed, all
existing rules for it will be interpreted as wildcard.
Regards.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
