nft for bridge.

nft for bridge.

[ratheesh kannoth]

hi,

inet offload is working fine for me.
++++++++++++++++++++++++
/etc/nftables/inet.nft

table inet x {

     flowtable f {
        hook ingress priority 0
        devices = { eth0, sdp1-0 }
        flags offload;
     }

    chain forward {
        type filter hook forward priority 0; policy accept;
        ct state { established, related } flow add @f
    }
}
++++++++++++++++++
But bridge nft fails. Could you help with correct configuration?  i
have already enabled below config
CONFIG_NF_TABLES_BRIDGE=y
CONFIG_NF_CONNTRACK_BRIDGE=y


/etc/nftables/ibridge-raw.nft
--------------
table bridge x {

     flowtable f {
        hook ingress priority 0
        devices = { br0  }
        flags offload;
     }

    chain forward {
        type filter hook forward priority 0; policy accept;
        ct state { established, related } flow add @f
    }
}
~# nft -f /etc/nftables/ipv4-raw.nft
/etc/nftables/ipv4-raw.nft:7:16-16: Error: Could not process rule: No
such file or directory
     flowtable f {
               ^
/etc/nftables/ipv4-raw.nft:15:43-53: Error: Could not process rule: No
such file or directory
        ct state { established, related } flow add @f
                                          ^^^^^^^^^^^

Re: nft for bridge.

[Pablo Neira Ayuso]

On Mon, Aug 18, 2025 at 05:35:49PM +0530, ratheesh kannoth wrote:
> hi,
> 
> inet offload is working fine for me.
> ++++++++++++++++++++++++
> /etc/nftables/inet.nft
> 
> table inet x {
> 
>      flowtable f {
>         hook ingress priority 0
>         devices = { eth0, sdp1-0 }
>         flags offload;
>      }
> 
>     chain forward {
>         type filter hook forward priority 0; policy accept;
>         ct state { established, related } flow add @f
>     }
> }
> ++++++++++++++++++
> But bridge nft fails. Could you help with correct configuration?  i
> have already enabled below config
> CONFIG_NF_TABLES_BRIDGE=y
> CONFIG_NF_CONNTRACK_BRIDGE=y
> 
> 
> /etc/nftables/ibridge-raw.nft
> --------------
> table bridge x {
> 
>      flowtable f {
>         hook ingress priority 0
>         devices = { br0  }
>         flags offload;
>      }
> 
>     chain forward {
>         type filter hook forward priority 0; policy accept;
>         ct state { established, related } flow add @f
>     }
> }
> ~# nft -f /etc/nftables/ipv4-raw.nft
> /etc/nftables/ipv4-raw.nft:7:16-16: Error: Could not process rule: No
> such file or directory
>      flowtable f {
>                ^
> /etc/nftables/ipv4-raw.nft:15:43-53: Error: Could not process rule: No
> such file or directory
>         ct state { established, related } flow add @f
>                                           ^^^^^^^^^^^

No flowtable support for the bridge family yet, sorry.

Re: nft for bridge.

[ratheesh kannoth]

On Mon, Aug 18, 2025 at 7:50 PM Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> No flowtable support for the bridge family yet, sorry.
Thanks. For routed flow, Openvswitch case, it pushes Original and
reply direction with the same cookie. But nft case, it pushes Original
direction tuple twice. Is this expected ? or is this issue fixed with
the latest kernel or nft ?
MY nft version : nftables v1.1.5 (Commodore Bullmoose #6)
My kernel :   kernel 6.6

ADD cookie=18446462603462596360 (00:00:00:00:00:00,
192.168.11.200:30443) to (00:00:00:00:00:00, 192.168.9.100:35091) IPv4
TCP
ADD cookie=18446462603462596360 (00:00:00:00:00:00,
192.168.11.200:30443) to (00:00:00:00:00:00, 192.168.9.100:35091) IPv4
TCP

Re: nft for bridge.

[Florian Westphal]

ratheesh kannoth <ratheesh.ksz@gmail.com> wrote:
> On Mon, Aug 18, 2025 at 7:50 PM Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > No flowtable support for the bridge family yet, sorry.
> Thanks. For routed flow, Openvswitch case, it pushes Original and
> reply direction with the same cookie. But nft case, it pushes Original
> direction tuple twice. Is this expected ? or is this issue fixed with
> the latest kernel or nft ?

You will need to figure that out yourself.  Most of us a volunteers.

> MY nft version : nftables v1.1.5 (Commodore Bullmoose #6)
> My kernel :   kernel 6.6
> 
> ADD cookie=18446462603462596360 (00:00:00:00:00:00,
> 192.168.11.200:30443) to (00:00:00:00:00:00, 192.168.9.100:35091) IPv4
> TCP
> ADD cookie=18446462603462596360 (00:00:00:00:00:00,
> 192.168.11.200:30443) to (00:00:00:00:00:00, 192.168.9.100:35091) IPv4
> TCP

I don't even know where these messages come from.

Re: nft for bridge.

[ratheesh kannoth]

On Sun, Oct 5, 2025 at 5:15 PM Florian Westphal <fw@strlen.de> wrote:
> You will need to figure that out yourself.  Most of us a volunteers.
Ok.

>
> > MY nft version : nftables v1.1.5 (Commodore Bullmoose #6)
> > My kernel :   kernel 6.6
> >
> > ADD cookie=18446462603462596360 (00:00:00:00:00:00,
> > 192.168.11.200:30443) to (00:00:00:00:00:00, 192.168.9.100:35091) IPv4
> > TCP
> > ADD cookie=18446462603462596360 (00:00:00:00:00:00,
> > 192.168.11.200:30443) to (00:00:00:00:00:00, 192.168.9.100:35091) IPv4
> > TCP
>
> I don't even know where these messages come from.
Sorry.  THis is a debug print added  in my function  xxxx() to print
flow tuple information.
.ndo_setup_tc()
     |
     |
case TC_SETUP_FT:
   return flow_block_cb_setup_simple(type_data,
                                                  &my_cb_list,
                                                  my_setup_ft_block_ingress_cb,
                                                  priv, priv, true);
              |
              |
              |
 my_setup_ft_block_ingress_cb()  {
    struct flow_cls_offload *cls = type_data;
    switch (cls->command) {
           case FLOW_CLS_REPLACE:
                return xxxx(nic, cls);
}
     |
     |
     |
xxxx() {
  // parsing flow here
 if (flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ETH_ADDRS)) {
                struct flow_match_eth_addrs match;
                    /// debug prints are here to print MAC address
                flow_rule_match_eth_addrs(rule, &match);
   }
     if (flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_IPV4_ADDRS)) {
                struct flow_match_ipv4_addrs match;
                  // debug prints are here to print IP address.
                flow_rule_match_ipv4_addrs(rule, &match);
    }

}

Re: nft for bridge.

[Pablo Neira Ayuso]

On Sun, Oct 05, 2025 at 05:56:06PM +0530, ratheesh kannoth wrote:
> On Sun, Oct 5, 2025 at 5:15 PM Florian Westphal <fw@strlen.de> wrote:
> > You will need to figure that out yourself.  Most of us a volunteers.
> Ok.
> 
> >
> > > MY nft version : nftables v1.1.5 (Commodore Bullmoose #6)
> > > My kernel :   kernel 6.6
> > >
> > > ADD cookie=18446462603462596360 (00:00:00:00:00:00,
> > > 192.168.11.200:30443) to (00:00:00:00:00:00, 192.168.9.100:35091) IPv4
> > > TCP
> > > ADD cookie=18446462603462596360 (00:00:00:00:00:00,
> > > 192.168.11.200:30443) to (00:00:00:00:00:00, 192.168.9.100:35091) IPv4
> > > TCP
> >
> > I don't even know where these messages come from.
> Sorry.  THis is a debug print added  in my function  xxxx() to print
> flow tuple information.
> .ndo_setup_tc()

This is hardware offload trace.

What are you trying to do there?


>      |
>      |
> case TC_SETUP_FT:
>    return flow_block_cb_setup_simple(type_data,
>                                                   &my_cb_list,
>                                                   my_setup_ft_block_ingress_cb,
>                                                   priv, priv, true);
>               |
>               |
>               |
>  my_setup_ft_block_ingress_cb()  {
>     struct flow_cls_offload *cls = type_data;
>     switch (cls->command) {
>            case FLOW_CLS_REPLACE:
>                 return xxxx(nic, cls);
> }
>      |
>      |
>      |
> xxxx() {
>   // parsing flow here
>  if (flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ETH_ADDRS)) {
>                 struct flow_match_eth_addrs match;
>                     /// debug prints are here to print MAC address
>                 flow_rule_match_eth_addrs(rule, &match);
>    }
>      if (flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_IPV4_ADDRS)) {
>                 struct flow_match_ipv4_addrs match;
>                   // debug prints are here to print IP address.
>                 flow_rule_match_ipv4_addrs(rule, &match);
>     }
> 
> }