Issue:
When a client accesses a domain that's on the VPN split-tunnel policy list (i.e. dnsmasq resolves it and adds the IP to the routing ipset/nftset), the entire router network stack drops for ~5 seconds - not just the tunneled connection. This includes wired LAN traffic and pings to unrelated IPs outside the VPN (e.g. ping 1.1.1.1 -t on Windows shows several consecutive timeouts). This happens consistently and reproducibly.
Hardware acceleration (Network Acceleration / Flow Offloading) is already disabled in the UI.
Logs (via logread) during the exact moment of the drop:
kernel: 7981@C02L1,mtk_fe_event() 402: receive fe reset(hang) event, trigger ser by FE
kernel: 7981@C02L1,mt7981_dump_ser_stat() 6681: ::E R , SER_HOST_STEP = 0x00000005
kernel: 7981@C02L1,mt7981_dump_ser_stat() 6683: ::E R , SER_HOST_STAGE = 0x00000000
[mtk_pending_work] mtk_hw_init starts !
[mtk_hw_init] reset_lock:1, force:1
[mtk_hw_init] execute fe warm reset
[mtk_pending_work] mtk_hw_init ends !
kernel: mtk_fe_event() 413: receive fe reset done event, continue SER
[mtk_pending_work] WiFi SER reset done !
What I've already ruled out:
Not Wi-Fi related - reproduces over wired Ethernet too.
Not the hardware NAT/acceleration toggle - already disabled.
Not device-specific - happens with a clean, isolated reproduction (ping running continuously, drop starts exactly when a new domain from the VPN policy list is accessed).
Suspected trigger:
The VPN policy list is fairly large (~950 domains/IPs, including some broad CIDR ranges). My working theory is that when dnsmasq adds a newly-resolved IP to the ipset/nftset used for policy routing, the resulting hardware flow-table reprogramming on the Frame Engine causes it to hang, triggering a full SER (Serious Error Recovery) reset of the entire network subsystem (Ethernet + Wi-Fi + HNAT).
Question:
Is this a known issue with the MT7981 Frame Engine / SER recovery path when combined with VPN domain-based policy routing on a large list? Is there a fix planned, or a recommended workaround (e.g. list size limits, MTU tuning, disabling certain features) short of manually shrinking the domain list?
We attempted to reproduce the issue on a GL-MT3000 using firmware 4.9.0 beta 6, AmneziaWG 2.0, disabled Network Acceleration, and a policy list containing approximately 950 domain/IP entries, but we did not observe packet loss or a Frame Engine/SER reset.
Could you please send us the following information by private message?
The complete Domain/IP policy list or subscription URL, together with two or three domains that can reliably trigger the issue.
A redacted copy of the AmneziaWG 2.0 configuration. Please remove the PrivateKey and PresharedKey, but retain parameters such as MTU, DNS, AllowedIPs, Endpoint port, Jc/Jmin/Jmax, S1–S4, H1–H4.
Screenshots of the VPN Dashboard policy settings and the Network → DNS page.
If possible, could you please reproduce the issue once more and send us the complete system log afterward.
Thank you for your patience and assistance with the investigation.
The danger with storing domains into ipsets, is that these site very well rotate ip every few seconds, this can sum you up with a even bigger list, Cloudflare does that, but akamai aswell.
I would monitor the memory usage, wireless loads it's runtime and blobs in memory, maybe it doesn't like that high usage and starts killing certain parts to keep running and then breaks.
//Offtopic on a side note:
the other nasty effect is that there is also no end verification to the ip matching in this ipset, so a completely different site not set as pbr using that ip can make you leak either unintentionally to vpn or to wan.
I'm doing some research about this, but my guess is that something like sniproxy can solve this problem, currently in my homelab I gonna try to get this on OpenWrt to do some more tests since I have a nasty situation here where most of my debugging skills left the door because all was eventually akamai... ironically I thought luci-app-pbr had a bug on vanilla openwrt, even my bank started to get blocked again.
Thanks for raising these points - went through all three and wanted to share what I found in my specific setup:
1. Unbounded ipset growth from CDN IP rotation. Checked with ipset list dst_net10 during a live drop - the working set currently holds 264 entries with proper TTL-based expiry (individual /32s from Google/Facebook/Akamai/Cloudflare alongside my manually-added CIDR ranges). So it's not growing unbounded in my case; dnsmasq's TTL cleanup is doing its job.
2. Firewall reload triggering the hang. My setup uses legacy iptables (mangle table, fwmark-based) rather than nftables:
MARK ... match-set dst_net10 dst MARK xset 0x1000/0xf000
Since the rule references the ipset by name rather than embedding its contents, updating ipset entries doesn't trigger a full ruleset reload - just an ipset add/del, which should be a cheap O(1) kernel operation. So a reload storm doesn't seem to be the mechanism here either.
3. Memory/CPU exhaustion forcing something to get killed. Ran top -d 1 during a live drop - no spike at all, everything stayed under 10% VSZ. No OOM kills in the logs either.
So for my case, all three don't seem to be the direct cause. What I'm left with (and what I've shared with GL.iNet support directly, since they're actively investigating) is that the actual trigger looks like a driver-level issue at the intersection of mark-based ipset routing and hardware flow offload (HNAT/PPE) on the MT7981 - specifically, when an already hardware-offloaded connection's fwmark needs to change mid-flight (e.g. a new domain gets added to the routing ipset), something in that reconciliation path causes the Frame Engine to hang (mtk_fe_event() 402: receive fe reset(hang) event), which then triggers a full SER (Serious Error Recovery) reset of the whole network subsystem.
Your point about SNI/IP-leak with shared CDN IPs is a separate (and valid) concern though - worth its own investigation, probably via something SNI-aware like sniproxy rather than pure IP-based PBR. Curious how your OpenWRT test with that goes, if you get anywhere with it.