Unable to get WED / Acceleration Working on dumb AP

Apache14 · May 17, 2026, 5:54pm

Hello,

I am struggling to get hardware offload / WED working while in a "dumb" AP setup. Tested on snapshot as of today and on 25.12.2.

Devices tested :

Netgear WAX206 (MT7622BV)
Xiaomi AX3000T (MT7981BA)

I install bridger and enable hardware offloading within the firewall config page but get nothing listed in /sys/kernel/debug/ppe*/bind however a lot of lines in /sys/kernel/debug/ppe*/entries

My config

/etc/config/network


config interface 'loopback'
	option device 'lo'
	option proto 'static'
	list ipaddr '127.0.0.1/8'

config globals 'globals'
	option dhcp_default_duid '0004c7aa1deb2dfb4ea5a81141afefb949c1'
	option ula_prefix 'fdcf:eb7d:33de::/48'
	option packet_steering '1'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'
	list ports 'wan'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ip6assign '60'
	list ipaddr '192.168.33.3/24'
	option gateway '192.168.33.1'
	option multipath 'off'
	list dns '192.168.33.1'

/etc/config/firewall


config defaults
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'
	option flow_offloading '1'
	option flow_offloading_hw '1'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'lan'

config zone
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'DROP'
	option masq '1'
	option mtu_fix '1'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

/etc/config/wireless


config wifi-device 'radio0'
	option type 'mac80211'
	option path 'platform/soc/18000000.wifi'
	option band '2g'
	option channel '4'
	option htmode 'HE40'
	option cell_density '0'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'study'
	option encryption 'sae'
	option key '-----'
	option ocv '0'

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'platform/soc/18000000.wifi+1'
	option band '5g'
	option channel '64'
	option htmode 'HE80'
	option country 'GB'
	option cell_density '0'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'study2'
	option encryption 'sae'
	option key '-----'
	option ocv '0'

Other Info

Bridger is running and WED is enabled

root@OpenWrt:~# ps | grep brid
 3247 root      2796 S    /usr/sbin/bridger
 3388 root      1328 S    grep brid
root@OpenWrt:~# cat /sys/module/mt7915e/parameters/wed_enable
Y

When running a speed test via the AP the CPU usage is very high

Any pointers as to what im missing would be greatly appreciated

frollic · May 17, 2026, 6:16pm

Are you sure the hw supports WED ?

Apache14 · May 17, 2026, 6:32pm

They do, i just confirmed by setting the AX3000T up as a DHCP client (WAN) and a different LAN subnet and i could see data in the bind sysfs path and 600/600Mbps wifi throughput with near zero CPU load

lleachii · May 17, 2026, 7:50pm

You have to route for WED to be effective, an AP does not route. Your response above seems to confirm this. I'm guessing the bridger installation was to overcome this?

Can you verify the previous version this worked on?

Apache14 · May 17, 2026, 8:38pm

Yes birder was to allow for the offloading of traffic from LAN -> WLAN, the instructions are seen here : https://openwrt.org/docs/guide-user/network/wifi/wed

if you configure your router as a Dumb AP, flow offloading requires flows to be tracked via NAT or routing. The bridger package uses BPF to track bridged streams for the PPE.

    Install the bridger package.
    (Optional) Edit /etc/config/bridger to define specific devices or bridges to exclude from acceleration.

Im fairly confident this worked on 24.10.x as I remember checking this a few weeks ago prior to updating.

Some more info, when looking at entrieswithin the ppe debug directory i see all the connections as UNB, so im guessing the PPE subsystem is seeing the traffic but is unable to accelerate it ?

platanopi · May 17, 2026, 9:20pm

github.com/openwrt/openwrt

nft_flow_offload: add L2 bridge offload support (#22533)

main ← rchen14b:nft-flow-offload-bridge

opened 09:16PM - 20 Mar 26 UTC

rchen14b

+609 -3

## Summary Bridged traffic (e.g. WiFi client to wired LAN through br-lan) curre…ntly cannot be offloaded via nft_flow_offload. Only routed/NAT flows get picked up by the flowtable. This means AP/bridge mode setups always go through the full kernel bridge + conntrack + netfilter path for every packet, regardless of hardware capabilities. These patches add bridge awareness to nft_flow_offload: - Detect bridged packets by looking up the destination MAC in the bridge FDB - Build flow entries using bridge port in/out interfaces instead of L3 routes - Handle WDMA path for WiFi bridge offload (MT7996) - Support VLAN passthrough when bridge VLAN filtering is disabled This benefits both software and hardware flowtable users: - **Software flowtable** (`flow_offloading=1`): bridged traffic takes the kernel fast path, skipping per-packet conntrack/firewall/FDB lookups. Works on any device, no PPE or hardware offload needed. - **Hardware offload** (`flow_offloading_hw=1`): bridged flows are pushed to PPE hardware on MediaTek and Airoha platforms for wire-speed forwarding. The second commit enables the required infrastructure on the Airoha AN7581 target (kmod-br-netfilter, sysctl, WiFi flowtable hotplug). Based on MediaTek SDK patches (999-ppe-15, 999-ppe-16, 999-ppe-24) by Bo-Cun Chen and chak-kei.lam. Adapted and tested on Airoha AN7581. The PPE drivers on both MediaTek (mtk_ppe) and Airoha (airoha_ppe) already support PPE_PKT_TYPE_BRIDGE entries — these patches complete the netfilter side of the pipeline. ## Test results - Airoha AN7581 (Gemtek W1700K) in AP/bridge mode: verified [HW_OFFLOAD] for both wired and WiFi bridged flows - MediaTek MT7981 (Cudy TR3000 v1) tested by @ttc0419: CPU usage reduced from 24% to 8% on 250Mbps WAN, flows bound correctly - Router mode (NAT) offload: no regression - Devices without PPE: no behavior change, code paths only activate when a flowtable is configured ## Test plan - [x] Build for airoha target, verify patches apply cleanly - [x] Boot in AP/bridge mode, verify bridged flows get [HW_OFFLOAD] - [x] Confirm router mode NAT offload still works - [x] Build and test on mediatek/filogic (MT7981) — confirmed by @ttc0419 - [ ] Test software-only flowtable (no hardware offload) on a device without PPE

Nightman_80 · May 18, 2026, 3:54pm

I can confirm this with my 2 MT76 devices,

Zyxel LTE3301-plus (MT7621) Router mode
Cudy WR3000H v1 (MT7981BA/filogic) dumb AP

with 25.12.4 WED on the Cudy is not working, there are no connections in /sys/kernel/debug/ppe0/bind , its empty. Im not sure if Hardware flow offload is active at all, with 24.10.6 i can see BND connections . I used it with 24.10.x both enabled for Months now and i can see my wireless devices ip there too.

The Zyxel does not have WED feature but it is the same there are no BND entries in /sys/kernel/debug/ppe0/bind and in 24.10.6 i can see them for wired devices.

Apache14 · May 18, 2026, 4:20pm

@nbd I think you worked on the bridger package, do you know if there has been any known regression in the latest release ?

I was also unable to get this working well on snapshot