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

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

[ѽ҉ᶬḳ℠]

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 }
}

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

[kfm]

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.

That aside, you would definitely need CONFIG_NF_TABLES_INET for "inet" 
support.

-- 
Kerin Millar

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

[ѽ҉ᶬḳ℠]

On 12/02/2020 18:40, kfm@plushkava.net 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; }
}

>
> That aside, you would definitely need CONFIG_NF_TABLES_INET for "inet" 
> support.
>

That is fine, CONFIG_NF_TABLES_INET=y

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

[kfm]

On 12/02/2020 18:52, ѽ҉ᶬḳ℠ wrote:
> 
> On 12/02/2020 18:40, kfm@plushkava.net 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.

-- 
Kerin Millar

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

[ѽ҉ᶬḳ℠]

On 12/02/2020 19:01, kfm@plushkava.net wrote:
> On 12/02/2020 18:52, ѽ҉ᶬḳ℠ wrote:
>>
>> On 12/02/2020 18:40, kfm@plushkava.net 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.

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

[kfm]

On 12/02/2020 19:21, ѽ҉ᶬḳ℠ wrote:
> 
> On 12/02/2020 19:01, kfm@plushkava.net wrote:
>> On 12/02/2020 18:52, ѽ҉ᶬḳ℠ wrote:
>>>
>>> On 12/02/2020 18:40, kfm@plushkava.net 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

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

[ѽ҉ᶬḳ℠]

On 12/02/2020 19:44, kfm@plushkava.net wrote:
> On 12/02/2020 19:21, ѽ҉ᶬḳ℠ wrote:
>>
>> On 12/02/2020 19:01, kfm@plushkava.net wrote:
>>> On 12/02/2020 18:52, ѽ҉ᶬḳ℠ wrote:
>>>>
>>>> On 12/02/2020 18:40, kfm@plushkava.net 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.

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

[kfm]

On 12/02/2020 19:51, ѽ҉ᶬḳ℠ wrote:
> 
> On 12/02/2020 19:44, kfm@plushkava.net wrote:
>> On 12/02/2020 19:21, ѽ҉ᶬḳ℠ wrote:
>>>
>>> On 12/02/2020 19:01, kfm@plushkava.net wrote:
>>>> On 12/02/2020 18:52, ѽ҉ᶬḳ℠ wrote:
>>>>>
>>>>> On 12/02/2020 18:40, kfm@plushkava.net 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.

I do not understand what is meant by "not processed". If the packet is 
directed to the wan_i chain, then it will be processed there.

> 
> 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.
> 
Consider the following ruleset as a possible foundation (formatted to be 
somewhat post-friendly).

table ip filter {
   chain input {
     type filter hook input priority 0; policy drop;
     ct state vmap {
       established : accept,
       related     : accept,
       invalid     : drop,
       untracked   : drop }
     # At this point, the packet can only have a ct state of new
     iifname vmap {
       "lo"       : accept,
       "ppoe-wan" : jump wan_i,
       "eth0-lan" : jump lan_i }
   }
   chain wan_i {
     tcp dport 22 accept
   }
   chain lan_i {
     accept
   }
}

Here, you accept whatever you intend to accept in the wan_i and lan_i 
chains. If the packet isn't accepted then it will return to the input 
chain and fall through to its drop policy.

There are nuances that could stand to be altered. For example, you might 
want to accept lo up front, rather than subject it to the ravages of 
connection tracking, and ICMP isn't dealt with in any capacity, which 
would become pertinent in an inet table.

Still, from a basic structural standpoint, it's not clear to me why your 
ruleset would need to be markedly more circuitous than this.

--
Kerin Millar

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

[ѽ҉ᶬḳ℠]

On 12/02/2020 20:57, kfm@plushkava.net wrote:
> On 12/02/2020 19:51, ѽ҉ᶬḳ℠ wrote:
>>
>> On 12/02/2020 19:44, kfm@plushkava.net wrote:
>>> On 12/02/2020 19:21, ѽ҉ᶬḳ℠ wrote:
>>>>
>>>> On 12/02/2020 19:01, kfm@plushkava.net wrote:
>>>>> On 12/02/2020 18:52, ѽ҉ᶬḳ℠ wrote:
>>>>>>
>>>>>> On 12/02/2020 18:40, kfm@plushkava.net 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.
>
> I do not understand what is meant by "not processed". If the packet is 
> directed to the wan_i chain, then it will be processed there.
>
>>
>> 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.
>>
> Consider the following ruleset as a possible foundation (formatted to 
> be somewhat post-friendly).
>
> table ip filter {
>   chain input {
>     type filter hook input priority 0; policy drop;
>     ct state vmap {
>       established : accept,
>       related     : accept,
>       invalid     : drop,
>       untracked   : drop }
>     # At this point, the packet can only have a ct state of new
>     iifname vmap {
>       "lo"       : accept,
>       "ppoe-wan" : jump wan_i,
>       "eth0-lan" : jump lan_i }
>   }
>   chain wan_i {
>     tcp dport 22 accept
>   }
>   chain lan_i {
>     accept
>   }
> }
>
> Here, you accept whatever you intend to accept in the wan_i and lan_i 
> chains. If the packet isn't accepted then it will return to the input 
> chain and fall through to its drop policy.
>
> There are nuances that could stand to be altered. For example, you 
> might want to accept lo up front, rather than subject it to the 
> ravages of connection tracking, and ICMP isn't dealt with in any 
> capacity, which would become pertinent in an inet table.
>
> Still, from a basic structural standpoint, it's not clear to me why 
> your ruleset would need to be markedly more circuitous than this.
>
> -- 
> Kerin Millar

The current kernel deployed, which kconf is beyond my control, is 
missing the flag to support sets and thus vmap. But that aside something 
like this seems to work

table inet filter {
     chain input                { type filter hook input priority 0; 
policy drop; iifname pppoe-wan jump wan_i; }
     chain wan_i                { ip saddr 0.0.0.0/32 udp sport 67 ip 
daddr 255.255.255.255/32 udp dport 68 accept; }
}

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

[kfm]

On 13/02/2020 11:41, ѽ҉ᶬḳ℠ wrote:

<snip>

> The current kernel deployed, which kconf is beyond my control, is 
> missing the flag to support sets and thus vmap. But that aside something 
> like this seems to work
> 
> table inet filter {
>      chain input                { type filter hook input priority 0; 
> policy drop; iifname pppoe-wan jump wan_i; }
>      chain wan_i                { ip saddr 0.0.0.0/32 udp sport 67 ip 
> daddr 255.255.255.255/32 udp dport 68 accept; }
> }

Indeed, vmap is by no means required. This is equivalent to the 
previously suggested input chain, only marginally less efficient:

chain input {
   type filter hook input priority 0; policy drop;
   ct state established,related accept
   ct state invalid,untracked drop
   iifname "lo" accept
   iifname "pppoe-wan" goto wan_i
   iifname "eth0-lan" goto lan_i
}

Note that goto is an optimisation. It would still be appropriate to use 
jump in the case that you need for the packet to be able to fall through 
one of the user-defined chains and return to the input chain in order to 
be subjected to other rules there. In this particular example, it is not 
possible for iifname to match "eth0-lan" if it did not already match 
"pppoe-wan" and, because there are no further rules in the input chain, 
the use of goto is fine.

-- 
Kerin Millar

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

[ѽ҉ᶬḳ℠]

On 13/02/2020 11:59, kfm@plushkava.net wrote:
> On 13/02/2020 11:41, ѽ҉ᶬḳ℠ wrote:
>
> <snip>
>
>> The current kernel deployed, which kconf is beyond my control, is 
>> missing the flag to support sets and thus vmap. But that aside 
>> something like this seems to work
>>
>> table inet filter {
>>      chain input                { type filter hook input priority 0; 
>> policy drop; iifname pppoe-wan jump wan_i; }
>>      chain wan_i                { ip saddr 0.0.0.0/32 udp sport 67 ip 
>> daddr 255.255.255.255/32 udp dport 68 accept; }
>> }
>
> Indeed, vmap is by no means required. This is equivalent to the 
> previously suggested input chain, only marginally less efficient:
>
> chain input {
>   type filter hook input priority 0; policy drop;
>   ct state established,related accept
>   ct state invalid,untracked drop
>   iifname "lo" accept
>   iifname "pppoe-wan" goto wan_i
>   iifname "eth0-lan" goto lan_i
> }
>
> Note that goto is an optimisation. It would still be appropriate to 
> use jump in the case that you need for the packet to be able to fall 
> through one of the user-defined chains and return to the input chain 
> in order to be subjected to other rules there. In this particular 
> example, it is not possible for iifname to match "eth0-lan" if it did 
> not already match "pppoe-wan" and, because there are no further rules 
> in the input chain, the use of goto is fine.

Thanks for the hint/tip (and other input) - goto makes sense in this 
case, saves CPU cycles (even if just a tiny bit - but why waste it anyway).

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

[kfm]

On 13/02/2020 12:09, ѽ҉ᶬḳ℠ wrote:
> On 13/02/2020 11:59, kfm@plushkava.net wrote:
>> On 13/02/2020 11:41, ѽ҉ᶬḳ℠ wrote:
>>
>> <snip>
>>
>>> The current kernel deployed, which kconf is beyond my control, is 
>>> missing the flag to support sets and thus vmap. But that aside 
>>> something like this seems to work
>>>
>>> table inet filter {
>>>      chain input                { type filter hook input priority 0; 
>>> policy drop; iifname pppoe-wan jump wan_i; }
>>>      chain wan_i                { ip saddr 0.0.0.0/32 udp sport 67 ip 
>>> daddr 255.255.255.255/32 udp dport 68 accept; }
>>> }
>>
>> Indeed, vmap is by no means required. This is equivalent to the 
>> previously suggested input chain, only marginally less efficient:
>>
>> chain input {
>>   type filter hook input priority 0; policy drop;
>>   ct state established,related accept
>>   ct state invalid,untracked drop
>>   iifname "lo" accept
>>   iifname "pppoe-wan" goto wan_i
>>   iifname "eth0-lan" goto lan_i
>> }
>>
>> Note that goto is an optimisation. It would still be appropriate to 
>> use jump in the case that you need for the packet to be able to fall 
>> through one of the user-defined chains and return to the input chain 
>> in order to be subjected to other rules there. In this particular 
>> example, it is not possible for iifname to match "eth0-lan" if it did 
>> not already match "pppoe-wan" and, because there are no further rules 
>> in the input chain, the use of goto is fine.
> 
> Thanks for the hint/tip (and other input) - goto makes sense in this 
> case, saves CPU cycles (even if just a tiny bit - but why waste it anyway).

You are welcome. Also, mea culpa; "if it did not already match" should 
have been "if it already matched".

-- 
Kerin Millar