【Bug 實測報告】ASUS TUF-BE9400 在 PPPoE 環境下極短 UDP 封包固定丟包缺陷

ASUS TUF-BE9400 PPPoE 環境
極短 UDP 回程封包異常丟棄實測報告
RustDesk 自架伺服器無法上線之完整排查、封包驗證與暫時性解決方案
測試日期：2026-10　｜　目的：提供 ASUS 網通研發／韌體團隊重現與修正

一、結論摘要

依本次跨設備、跨網路、跨作業系統及伺服器端封包控制的實際 A/B 測試結果，可確認目前測試之 ASUS TUF-BE9400（韌體 3.0.0.6.102_58500）在 PPPoE WAN 路徑存在極短 UDP 回程封包異常丟棄問題。
在完全相同的 Oracle VPS、相同 UDP 服務、相同家庭固定 PPPoE 公網 IP 與相同 LAN 用戶端條件下，伺服器回傳 UDP payload 5 bytes 時封包無法到達 BE9400 的 ppp0/netfilter 可見層；將 payload 增加至 6 bytes 後則立即可正常接收。實際 RustDesk hbbs 通訊亦觀察到用戶端持續送出 15-byte UDP request，而 hbbs 回覆恰為 4-byte UDP payload（3A 02 10 01），與上述異常範圍完全吻合。
最終在不修改 BE9400、不修改任何 Windows RustDesk 用戶端的前提下，於 VPS 端利用 NFQUEUE 將該 4-byte RustDesk protobuf 回覆合法加入未知欄位 78 00，使 payload 由 4 bytes 增加為 6 bytes；Win7 隨即恢復 Ready 並成功遠端連線，之後 Win11 開機亦正常上線。因此此 workaround 同時驗證：問題並非 Windows、RustDesk Client、家庭交換器或 VPS 網路本身，而與 BE9400 PPPoE 對極短 UDP 回程封包的處理高度直接相關。

二、測試環境

項目 實際環境
路由器 ASUS TUF-BE9400
韌體 3.0.0.6.102_58500（本次測試時的最新正式韌體）
WAN 中華電信 PPPoE，MTU/MRU 1492
家庭固定公網 IP 220.135.246.xxx
PPPoE 邏輯介面 ppp0
實體 WAN 介面 eth0
RustDesk Server Oracle Cloud 日本 VPS
VPS 公網 IPv4 138.2.30.xxx
hbbs UDP 21116，由 hbbs process 直接監聽
獨立 UDP 測試埠 UDP/30001
家庭測試端 Windows 7、Windows 10、Windows 11、CentOS 7

三、故障現象與初始交叉驗證

• 更換舊 ASUS AX56U 為 TUF-BE9400 後，家中多台 RustDesk Client 無法正常顯示 Ready／上線。
• 相同 Win11 改用手機 4G 熱點後，RustDesk 立即 Ready。
• 相同 Win11 帶至公司 ASUS Wi-Fi（後端另有硬體防火牆）後，RustDesk 立即 Ready。
• 以小米 3C 直接 PPPoE 撥號、繞過 BE9400 後，相同 Win11 RustDesk 立即 Ready。
• Win11 在家仍經 BE9400，但於 Win11 本機先建立 WireGuard 到 Oracle VPS，使流量在進入 BE9400 前即被封裝後，RustDesk 立即 Ready；WireGuard 關閉則再次失敗。
上述結果首先將問題範圍集中至 BE9400／其 PPPoE datapath。尤其「同一台 Win11、同一套 RustDesk、同一 ISP、同一 VPS，僅改變封包是否在進入 BE9400 前被 WireGuard 封裝」即可形成明確成功／失敗 A/B。

四、已排除之常見設定因素

為避免將一般 NAT、MTU、UPnP 或 Windows 問題誤判為路由器韌體問題，本次已實際測試或排除下列項目：
• UPnP 關閉：無改善。
• SIP Passthrough 關閉：無改善。
• NAT acceleration／QCA SFE 關閉及完整重開機：無改善；之後已恢復原設定。
• PPPoE reconnect／restart_wan：無改善。
• DoS、IPv6、Gaming Port／實體 LAN 路徑等：無改善。
• MTU/MRU 已確認為 1492；加入 MSS 1452 clamp：無改善，規則已移除。
• PPPoE header compression 已確認停用。
• 移除 qca_nss_ppe_pppoe_mgr 後重新建立 PPPoE session：RustDesk 仍失敗；模組已恢復。
• RustDesk disable-udp=Y 測試仍無法使 Win11 在 BE9400 下恢復，因此不能將所有 RustDesk 症狀簡化為單一 UDP 功能開關。
• 家庭 CentOS 7 有線端亦可重現短 UDP 丟失，故並非 Windows、Wi-Fi 或 RustDesk Client 本身造成。

五、獨立 UDP 封包長度實驗

為將 RustDesk 應用層完全排除，於 Oracle VPS 建立獨立 UDP/30001 echo 測試，控制伺服器回覆 payload 長度，家庭 CentOS 7 透過 BE9400 PPPoE 接收。實測結果如下：
UDP payload 家庭 BE9400 PPPoE 結果
1 byte 無法收到 FAIL
4 bytes 無法收到 FAIL
5 bytes 無法收到 FAIL
6 bytes 可正常收到 PASS
8 bytes 可正常收到 PASS
16 bytes 可正常收到 PASS
因此，在本次實測條件下存在非常清楚的邊界：已測試之 UDP payload 1～5 bytes 失敗，而 6 bytes 及以上的測試值成功。同一 Oracle VPS 的 5-byte UDP 回覆由公司網路測試則可正常收到，進一步排除 VPS 本身無法傳送短 UDP 的可能性。

六、封包消失位置：未進入 ppp0／netfilter

為判斷短 UDP 封包是在 LAN/NAT 階段被丟棄，還是在 PPPoE RX 更前端即消失，於 BE9400 ppp0 的 mangle PREROUTING 加入只計數的 UDP 規則。
iptables -t mangle -I PREROUTING 1 -i ppp0 -p udp -s 138.2.30.xxx --sport 30001
A/B 結果：
• 5-byte 回覆：Oracle 端確認已 TX；家庭 CentOS timeout；CentOS tcpdump 看不到 inbound；BE9400 ppp0 PREROUTING counter 維持 0。
• 6-byte 回覆：相同流程下，BE9400 ppp0 counter 增加 1 packet / 34 bytes；家庭 CentOS 同時正常收到。
此結果表示 5-byte UDP 回覆並非在一般 FORWARD/NAT 規則中被丟棄，而是在封包呈現給 ppp0/netfilter 之前即已消失。依 BE9400 架構，值得 ASUS 研發優先檢查 eth0 → QCA/NSS/PPE datapath → PPPoE decapsulation → ppp0 之 RX short-packet handling。本測試並未直接證明 5-byte 封包已抵達實體 eth0，因此不主張丟包的精確硬體節點；但可以確認其未到達 ppp0 可見層。

七、RustDesk 實際封包驗證

確認獨立 UDP 異常後，再回到真實 RustDesk 流量。hbbs 直接監聽 UDP/21116。僅保留家中 Win7 在線時，VPS tcpdump/NFQUEUE 可穩定觀察到以下重複交換：
方向 UDP payload 內容／特徵 現象
Win7 → hbbs 15 bytes RustDesk request 持續約每 1～2 秒重送
hbbs → Win7 4 bytes 3A 02 10 01 每次 request 後立即回覆，但 Win7 未完成上線
也就是說，真實 RustDesk hbbs 恰好會送出一個 4-byte UDP 回覆，而 4 bytes 正落在前述 BE9400 PPPoE 獨立實驗所證實的失敗範圍。Win7 因收不到該回覆而反覆重送 request，形成非常強的因果關聯。
原始 hbbs UDP payload：3A 02 10 01
IP total length：32 bytes
UDP payload length：4 bytes

八、第一次 padding 嘗試為何失敗

初次嘗試在 VPS 端直接於 4-byte payload 後補兩個 00，使其變為 6 bytes。雖然封包長度已跨過 BE9400 的失敗範圍，Win7 仍未 Ready。原因經協議內容分析後，3A 02 10 01 可視為合法 protobuf 編碼，而直接追加 00 00 可能形成非法 tag 0，導致 RustDesk protobuf parser 無法接受該訊息。因此單純『補零』不是可用方案。
失敗版本：3A 02 10 01 00 00

九、最終成功方案：加入合法 protobuf unknown field

最終改為在原始 protobuf 後加入一個合法但 RustDesk 可忽略的 unknown field：78 00。其中 0x78 對應 protobuf field 15、wire type 0（varint），0x00 為其值 0。原有 RustDesk 欄位內容不變，只增加一個正常 parser 可忽略的未知欄位，同時將 UDP payload 從 4 bytes 增加至 6 bytes。
原始：3A 02 10 01 （4 bytes，BE9400 PPPoE 下無法正常通過）
修改：3A 02 10 01 78 00 （6 bytes，成功）
VPS 使用 Python NetfilterQueue 程式 `/opt/udp_pad6.py`，並以 OUTPUT/mangle NFQUEUE 攔截指定封包。測試規則：
iptables -t mangle -I OUTPUT 1 -p udp -d 220.135.246.xxx --sport 21116 \
-m length --length 28:33 -j NFQUEUE --queue-num 116 --queue-bypass
程式收到符合條件之 hbbs 短 UDP 回覆後，在 payload 尾端加入 78 00，更新 UDP length、IP total length，並重新計算 IP/UDP checksum 後放行。

十、最終實際驗證結果

• 啟用合法 protobuf padding 後，家中 Win7 RustDesk 當場由離線狀態恢復 Ready。
• 隨即由外部實際遠端連入 Win7，遠端控制成功，並非僅 UI 顯示 Ready。
• 之後透過遠端方式啟動家中 Win11，Win11 RustDesk 亦正常上線。
• 因此此 workaround 並非只對單一 Win7 版本偶然有效，而能解除家中多台 RustDesk Client 經 BE9400 PPPoE 時的實際連線障礙。
• 不需更換 BE9400、不需修改各 Windows Client、不需讓每台電腦個別建立 WireGuard VPN。

十一、對 ASUS 的問題判定與建議檢查方向

問題判定：依上述可重現、可控制封包長度且跨應用層驗證的結果，本案可確認 TUF-BE9400 在本次韌體與 PPPoE 環境下，對極短 UDP 回程封包存在異常丟棄 BUG。這不是單純 RustDesk 相容性問題，因獨立 UDP/30001 測試亦能穩定重現。
建議 ASUS Networking RD／Firmware 團隊優先檢查：
• QCA/NSS/PPE PPPoE RX datapath 對 UDP short packet／small skb 的長度檢查。
• PPPoE decapsulation 前後對 IPv4 total length、UDP length、minimum packet length 的判斷。
• 是否存在硬體 offload／PPE parser 對特定極短 UDP frame 的錯誤 drop 條件。
• 為何 payload 5 bytes 的回覆無法出現在 ppp0/netfilter，而 payload 6 bytes 即正常。
• 即使關閉一般 NAT acceleration／SFE，問題仍存在；且單獨移除 qca_nss_ppe_pppoe_mgr 並重建 PPPoE session 仍無改善，故需進一步檢查更底層 RX datapath。
• 建議提供 debug／candidate firmware，以相同 5-byte/6-byte UDP 測試直接驗證修正。

十二、建議 ASUS 內部最小重現方式

此問題不需要建置 RustDesk 即可重現。建議 ASUS 實驗室使用一台 Internet UDP Server 與一台位於 TUF-BE9400 PPPoE LAN 後方的 Client：
• Client 向 Internet UDP Server 發送任意 request。
• Server 對該 NAT mapping 回傳固定 5-byte UDP payload，確認 Client 是否 timeout。
• 保持所有條件不變，僅將 Server 回覆改成 6-byte UDP payload。
• 在 TUF-BE9400 ppp0 PREROUTING 加計數規則；比較 5-byte 與 6-byte 回覆是否進入 ppp0。
• 若能重現本案，5-byte 將在 ppp0 前消失，而 6-byte 將正常出現並送達 LAN Client。

十三、目前暫時性 workaround

在 ASUS 正式修正韌體前，目前採用 VPS server-side workaround：僅針對 hbbs UDP/21116 發往家庭固定 IP 的極短回覆進入 NFQUEUE，將實際 4-byte protobuf `3A 02 10 01` 合法擴充為 6-byte `3A 02 10 01 78 00`。
此方式已由 Win7 與 Win11 實際上線及遠端控制成功驗證。正式部署時建議進一步將 Python 程式條件收斂至實際 4-byte payload／特定內容，避免修改其他非目標 UDP 訊息；並保留 `--queue-bypass`，避免 NFQUEUE consumer 未啟動時造成額外阻斷。

十四、重要觀察與限制

• 本報告所稱『確認 BUG』是指本次實測之 TUF-BE9400、韌體 3.0.0.6.102_58500、PPPoE WAN 組合下，可穩定重現極短 UDP 回程異常；ASUS 仍應於實驗室確認不同硬體批次與後續韌體版本。
• 已證實 1、4、5-byte payload 失敗，6、8、16-byte payload 成功；因此可描述為『本次已測試值中 ≤5 bytes 失敗、≥6 bytes 成功』，但未窮舉所有可能封包結構。
• ppp0 計數結果證明失敗封包未到達 ppp0/netfilter 可見層，但因路由器無可用的實體 WAN tcpdump，本報告不宣稱已證明封包抵達 eth0 後才被丟棄。
• RustDesk `disable-udp=Y` 曾無法解決 Win11 的完整上線問題，因此 RustDesk 可能還有其他流程受 BE9400 datapath 影響；但目前 4-byte hbbs UDP 回覆的 server-side 修正已足以讓實際 Win7、Win11 恢復上線。

十五、請 ASUS 協助事項

敬請 ASUS 將此案轉交 Networking RD／Firmware 團隊，針對 TUF-BE9400 PPPoE RX 路徑的極短 UDP 封包處理進行確認，並提供可修正此問題的正式／測試韌體。本案已有獨立 UDP 長度 A/B、ppp0 counter、RustDesk 真實封包及 server-side 長度修正後立即恢復等多層證據，應可作為韌體團隊建立最小重現案例的依據。