Re: network flow offloading broken in 6.18.45+

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Tue, Sep 15, 2026 at 02:20:25AM +0200, Hauke Mehrtens wrote:
> On 9/14/26 14:36, Pablo Neira Ayuso wrote:
> > On Mon, Sep 14, 2026 at 02:28:49PM +0200, Pablo Neira Ayuso wrote:
> > > Hi,
> > > 
> > > On Mon, Sep 14, 2026 at 12:13:50AM +0200, Pablo Neira Ayuso wrote:
> > > > On Mon, Sep 14, 2026 at 12:12:16AM +0200, Pablo Neira Ayuso wrote:
> > > > > Hi Hauke,
> > > > > 
> > > > > On Wed, Sep 09, 2026 at 06:29:50PM +0200, Hauke Mehrtens wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > flow offloading is currently broken in Linux 6.18.45.
> > > > > > 
> > > > > > Since the backport of commit b5964aac51e0 ("netfilter: flowtable:
> > > > > > consolidate xmit path") to Linux 6.18.45. This is happening in a router with
> > > > > > traffic from wifi to the Ethernet device when mac80211 returns -EOPNOTSUPP.
> > > > > > 
> > > > > > Upstream fixed it in 871df5007eda ("netfilter: flowtable: bail out if
> > > > > > forward path cannot be discovered") by not offloading the flow at all.
> > > > > > backporting this change looks more complicated.
> > > > > > 
> > > > > > This cam up in a discussion in an OpenWrt PR:
> > > > > > https://github.com/openwrt/openwrt/pull/24800
> > > > > > 
> > > > > > An LLM suggested this change: https://github.com/openwrt/openwrt/pull/24800/changes/394d741e6e76ecd172dbbf1d9ba171e378211734
> > > > > 
> > > > > Patch went away.
> > > > > 
> > > > > > It seams to work, but I do not understand this part of the code god enough
> > > > > > to judge if this is correct.
> > > > > 
> > > > > Could you attach the patch to this email for review?
> > > > 
> > > > I've found it :)
> > > > 
> > > > https://github.com/openwrt/openwrt/commit/d2b53b8043e17087b877bfc2335cbba87dffb4e0
> > > 
> > > I've proposed the following fix:
> > > 
> > > https://lore.kernel.org/netfilter-devel/20260914122456.1963453-1-pablo@netfilter.org/
> > 
> > Actually, this v2 should work:
> > 
> > https://lore.kernel.org/netfilter-devel/20260914123334.1964397-1-pablo@netfilter.org/
> 
> Hi Pablo,
> 
> Thank you for looking into this.
> 
> I think we have to handle DEV_PATH_MTK_WDMA like we do it with DEV_PATH_DSA
> in nft_dev_path_info() too.

I don't think you can find DEV_PATH_MTK_WDMA from nft_dev_path_info().

There is a story about this: Felix needed a way to expose the MTK SoC
capabilities in some way to drivers, he decided to use the
.fill_forward_path interface for this purpose.

See mtk_flow_get_wdma_info(), it makes a direct call to
dev_fill_forward_path() to get the DEV_PATH_MTK_WDMA.
Therefore, it is not possible to see DEV_PATH_MTK_WDMA from
nft_dev_path_info() because it does not belong there.

I suggested a new interface for this but SoC requirements were not
clear at the time IIRC.

My patch is a workaround, so dev_fill_forward_path() does not fail for
this case.

> mt7915_net_fill_forward_path() from
> drivers/net/wireless/mediatek/mt76/mt7915/main.c could also return
> -ENODEV like mac80211 does.
> Should we backport 871df5007eda to 6.18 instead?

Does 871df5007eda fix the issue for you?

If I understood correctly, this simply results in not setting up the
flowtable bypass? ie. ethernet to wifi will just fall back to classic
forwarding path.