On 12/02/2020 19:44, kfm@xxxxxxxxxxxxx wrote:
On 12/02/2020 19:21, ѽ҉ᶬḳ℠ wrote:
On 12/02/2020 19:01, kfm@xxxxxxxxxxxxx wrote:
On 12/02/2020 18:52, ѽ҉ᶬḳ℠ wrote:
On 12/02/2020 18:40, kfm@xxxxxxxxxxxxx wrote:
On 12/02/2020 16:41, ѽ҉ᶬḳ℠ wrote:
Have tried to some online guidance which NFT features require
which kernel config to be set to get them working and whether
jump is among such feature set.
Because hitting:
Error: Could not process rule: Not supported
with:
table inet filter {
chain input { type filter hook input priority 0; iifname
pppoe-wan jump wan_i }
}
As shown, this isn't quite valid nft syntax. Please post a minimal
- but complete - ruleset that reproduces your issue in a form that
is verbatim. Include the wan_i definition, even if it merely an
empty chain.
table inet filter {
chain input { type filter hook input priority 0; iifname
pppoe-wan jump wan_i; }
chain wan_i { type filter hook input priority 0; }
}
You may not jump to the wan_i chain because it is hooked. It makes
as little sense as trying to run iptables -I INPUT -j INPUT.
So jump and goto are only good with non-base chains and those can
only be utilised for:
* nft_immediate: loads an immediate value into a register.
* nft_cmp: compare a given data with data from a given register.
* nft_payload: set/get arbitrary data from packet headers.
* nft_bitwise: perform bit-wise math operations over data in a given
register.
* nft_byteorder: perform byte order operations over data in a given
register.
* nft_counter: a basic counter for packet/bytes that gets incremented
everything is evaluated for a packet.
* nft_meta: set/get packet meta information, such as related
interfaces, timestamps, etc.
* nft_lookup: search for data from a given register (key) into a
dataset. If the set is a map/dictionary, returns the value for
that key.
then, that correct? I had hoped that I could organise the chain
structure for processing into something like WAN, LAN and WAN<>LAN.
The obvious solution is to remove the hook from the wan_i chain. There
is no apparent reason for it to have one. Also, you may find it useful
to jump from your input chain to others by way of a verdict map.
If the hook is removed then packages are not processed in the chain, e.g.
table inet filter {
chain input { type filter hook input priority 0;
iifname pppoe-wan jump wan_i; }
chain wan_i { policy drop; ct state 1 drop; ct state
2,4 accept; }
}
which does not help with organising chains in the sense/way I had mind.
Looks like it requires a more circuitous route with more/different
tables and negating interfaces (iif = ! | oik = !) for each such table.
