Re: [nftables 0.9.2] does jump require a kconf to be set to get it working?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

--
Kerin Millar



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux