Antony

Device: Keenetic Giga KN-1012 (MediaTek MT7981 / Filogic 820, aarch64) Firmware: KeeneticOS 5.00.C.12.0 Symptom With "ppe hardware" enabled (the default), a long-lived WebRTC UDP media session (Opus/RTP audio, ~50 pps, to a remote SFU) degrades reliably every ~13–15 minutes: the far side stops hearing us, the client reconnects, the cycle repeats. It reproduces with two independent WebRTC clients — a Chromium-based browser client and a native one — so it is not application-specific. Localization (two-sided nf_conntrack capture, LAN + WAN, taken live through the moment of failure): • LAN-IN: packets from the PC keep flowing at ~50 pps — the PC is sending fine; • WAN-OUT: the outbound translation (external IP → SFU) freezes — the outbound half of the 5-tuple stops being forwarded; • downlink (inbound from the SFU) stays alive; • the conntrack entry is tagged [FASTNAT]. So the hardware offload stops forwarding the outbound half of an active UDP session while the inbound half is still alive. This is not congestion (RTT stays ~30 ms, jitter low) and not an idle timeout (traffic is continuous at ~50 pps). Root-cause isolation — exactly one variable changed: • ppe hardware ON → failure guaranteed every ~13–15 min (many cycles in a row); • no ppe hardware (both off) → 22.5 min call, zero drops, 0.018% loss; • ppe software only → 34 min clean, networkScore = EXCELLENT, 0.024% loss, surviving two windows where it previously always failed. Nothing else was changed — toggling ppe hardware deterministically breaks / fixes the path. This is a known class of bug The same issue was reported and acknowledged by Keenetic years ago on the older MT7620 platform — topic 1171 (in Russian): https://forum.keenetic.com/topic/1171- A Keenetic developer (ndm) acknowledged it was their oversight: the hardware path did not account for checksum changes inside the UDP stream. It was fixed in KeeneticOS 2.09.A.0.0-3 by routing UDP through ppe software while keeping TCP on ppe hardware. On the new MT7981 platform the symptom is back — a regression, or the automatic "UDP → software PPE" routing from 2.09 is not applied on the KN-1012. The same MT7981 SoC has an analogous hardware-flow-offload defect in OpenWrt — issue #19449 "hardware flow offloading working abnormally": https://github.com/openwrt/openwrt/issues/19449 The general "HW offload breaks long-lived UDP" class is #17915: https://github.com/openwrt/openwrt/issues/17915 Request Please either restore the automatic routing of UDP through software PPE (as done for MT7620 in 2.09), or expose a CLI/UI switch to disable UDP offload while keeping TCP hardware offload. Right now the only workaround is a full "no ppe hardware", which gives up gigabit LAN acceleration. Notes The single deciding variable is the state of ppe hardware — firmware, client and network are otherwise identical across the failing and working runs, and it reproduces across independent WebRTC clients (browser-based and native). Happy to provide a self-test diagnostic file or run any additional repro on request.