[分享] 將 CAKE 從 Linux 4.19 向下移植至 3.4/4
大家好，我是 TW641。
這是我個人獨立完成的一個開源專案心得分享。
主要目的是將現代的 CAKE (Common Applications Kept Enhanced) 演算法，
Backport (向下移植) 到老舊的 Padavan 韌體環境 (基於 Linux 3.4/4.4)。
身為第一個成功完成此移植的開發者，我希望能為這段開源歷史留下紀錄，
讓舊款 MIPS/ARM 設備，也能享有先進的 SQM / AQM 流量塑形與 QoS 機制，
徹底緩解 Bufferbloat 問題。
因 PTT 介面排版限制，最完整純淨的圖文說明書與編譯懶人包，
請直接參考官方網站。這是我為了架設完美網站付出的努力：
為了提升直接調用 docsify 公版原始碼的使用體驗，
我將程式碼拉回自己倉庫最佳化。
我折衷捨棄了動畫，只為讓畫面以最快速度載入。
最終在 Google PageSpeed Insights 針對極端環境的模擬測速中，
TW641 官方首頁的「行動裝置」與「電腦」的四項指標：
【效能 100】、【無障礙功能 100】、【最佳做法 100】、【SEO 100】皆達滿分！
【TW641 | Padavan CAKE 開源路由器韌體中心】
官方首頁 (GitHub 國際主站)：https://tw641.github.io/
極速備援站 (Cloudflare 節點)：https://tw641.pages.dev/
(註：若主站連線緩慢或異常，推薦改用備援站入口)
GitHub Repo 原始碼：https://github.com/TW641/sch_cake
(若覺得這份心血有幫助，懇請到 GitHub 幫忙點個 ★ Star 給予支持！)
--------------------------------------------------------------------
【專案技術重點與實戰踩坑紀錄】
1. Kernel 移植整合與 Netfilter 恩怨情仇：
AKE 是在 Kernel 4.19 才納入主線。
飢齔봠tc 與 CAKE 的相容性，我將 libmnl 升級至 1.0.5。
拑h苦的踩坑點在 iptables 升級：新版底層嚴重依賴 nftables 的 xshared。
琲먠4.4.198 內核一定要降回 1.8.7 才能成功對外連線。
痡q官方 commit log 逐一挑選了 100 個 patch 進行編譯測試，
怮廕踶畦X 53 個才完美運作 (移除了 xshared重構, xlate翻譯 等)。
偭蚹K伺服器阻擋連線，我將這 53 個成功下載的 patch 上傳到專案，
羹g入 YAML 比對邏輯動態套用，成功修復多個 ramleak 與穩定性問題。
o證實了剝離 nftables 共用依賴才是正解。
玅[極老舊的 3.4.113 核心，推測是不會觸發 xshared 的雷，
滲鄋膜W 1.8.11 並打上所有上游 commit，穩定運行無 Bug！
2. CAKE 與 HWNAT/SFE 的三層攔截共存機制：
o也是為何我非得修復 hw_nat 工具不可，
_則根本無從驗證連線是否成功 bind 到 PPE！
陘F極致效能，我將硬體加速綁定閾值從 30 降到 1，
伈怳j努力把連線塞進 PPE。
g過實測驗證，CAKE、HWNAT 與 SFE (shortcut-fe)
O可以完美共存且不當機的。它們的運作邏輯宛如「三層過濾漏斗」：
臚@層：PPE 絕對不偷懶，能硬體加速的封包直接繞過 CPU。
臚G層：PPE 無法加速的封包，落入 SFE 攔截網，執行軟體捷徑轉發。
臚T層：SFE 處理不了的封包走傳統 CPU 轉發，
僥犮턠CAKE 全權接管做 AQM 排序塑形。
鷁M這三者的程式碼本質上無法互相傳遞封包標記，
鐧T實能各自攔截對應的流量。
犖艩戊t交給 HWNAT+SFE，未加速的殘餘流量交給 CAKE 守底線，
N硬體潛能榨乾！
3. 復活無線中繼 (WISP/APCLI) 的 HWNAT 硬體加速：
H往韌體在中繼模式下硬體加速會失效。
3.4 核心：修復了 IP 取值的記憶體錯位 Bug，並補齊 PPE 註冊。
4.4 核心：我發現上游的 ra_nat.c 寫死了一段邏輯：
f (strncmp(dev->name, "apcli", 5) == 0) return;
伬P網卡名稱包含 apcli 就直接跳過！我解除了這個封印限制，
穩蚰縣F介面對應 (如 dst_port[DP_APCLI0] = ra_dev_get_by_name)。
{在終端機會大聲喊出 Bind Interface [apcli0] success!
4. 修復 HWNAT 記憶體錯位與顯示異常 (Unaligned Access)：
儤t hw_nat 工具取值寫法不夠嚴謹。
b MIPS 架構下有嚴重的非對齊存取 Bug，
o導致抓到的連線 IP 或 Port，常出現09.20.106.8:00000
峎O.0.0.0:00000o種半殘半開的亂碼。
陘F解決這個問題，我先在 hwnat_ioctl.h 的結構體尾端
l加 __attribute__ ((packed))。
紫萓b hw_nat_api.c 的格式化輸出前，手動將 args->entries[i] 的資料
ㄗ痩嚄Y謹的局部變數
如 unsigned int i_sip, e_sip 以及 IPv6 的 is6[4], id6[4] 陣列)，
A送進 printf 格式化輸出。這徹底解決了指標與記憶體錯位問題，
T保了 malloc 分配後的穩定性，也排除了潛在的 RAM Leak！
5. 模組化 YAML 升級 BusyBox 1.37.0 與底層安全性修補：
o是一切災難與成就的起源！原廠設定檔還停在 BusyBox 1.24.2，
倥h CVSS 9.8 滿分的堆疊溢位漏洞 (CVE-2022-48174)。
陘F「尊重原開發者」，我選了一條最難的路：不去破壞原來的原始碼倉庫，
蚲a YAML 腳本修改 Docker runner 的對應路徑，進行「模組化即時 Patch」。
琣b YAML 中用 grep 和 sed 大量替換 build_firmware 與 user/ 內的版本號，
疇[上 if 判斷式，只要查到殘留的 1.24.x 代碼就直接 exit 1 中斷防呆！
褻●炙X了 syslogd 導致日誌啟動後全部空白的 Bug，
z過腳本動態寫入 services_syslogd_fix.patch (補上 "-L" 參數) 才解決。
o就是模組化的初衷：哪裡壞修哪裡，證明老設備也能有無痛的頂級安全！
6. 引入 GitHub Actions 雲端自動化編譯與多國語系：
g好 Workflow，免除本地端架設 Ubuntu 的麻煩。
o是我努力的證明：光是 Padavan 相關的 Repo 我就跑了數百次 Workflow
166+108+27+12+11+106次...)。因為 YAML 沒得互動只能狂按 Enter 試錯，
蘒Busybox 那段腳本就試了 50 幾次才終於成功跑完這嚴謹度 100% 的自動化流程！
{在只要 Fork 過去，透過下拉選單選擇 Target，就能自動產出韌體檔。
堳e精準支援 142 款機型，且系統內建高達 14 種語言包 (含繁體中文)，
敞}網路無國界的限制。
--------------------------------------------------------------------
【來自國際開源界與總統級的肯定 (真正的數位國民外交)】
這個專案不僅成功在台灣論壇發布，更在國際開源社群引起了巨大的迴響，
這對身為唯一開發者的我來說，是極大的肯定與驚喜：
1. 來自捷克的國際開源大神親自認可：
琲먠GitHub 專案獲得了 LibreQoS 營運長 Frantisek (Frank) Borsik
瑪辿菾l蹤與肯定！Frank 來自捷克布拉格，在國際開源網路界大有來頭，
翮t責知名開源路由器 Turris (OpenWrt) 及 RF elements 的核心推廣。
o代表本專案已成功打入全球「對抗 Bufferbloat」社群的最核心圈！
鉬P來自友好捷克的專家交流，真的是莫大的榮幸。
2. 來自日本的頂尖網路學者跨國關注：
擖輒誚y名校慶應義塾大學 (Keio University) 的 Dikshie 博士
]親自給予此專案關注與認可！博士專攻 P2P 網路與網際網路架構，
鈶繸o這類精於底層基礎設施的重量級學者肯定，
狻疃F這份演算法移植的技術含金量極高！
魚鴘漪O，我好奇查了一下，發現博士 14 年前居然也在 PTT 的 FreeBSD 板發過求救文！
鄏b開源界和 PTT 神獸相遇，這努力過的痕跡真的很神奇XD
3. 總統級的數位國民外交：
ibreQoS 官方甚至在 X (Twitter)、Facebook 與 LinkedIn
弘篕琲戲s平台上發布貼文致敬，
N這個專案譽為給 Dave Täht 的 "Time-Traveling Valentine's Gift"，
疆b文中史無前例地標註了台灣總統賴清德、前總統蔡英文與總統府發言人！
鉣蹵x灣的開源技術貢獻躍上國際版面，真的是貨真價實的國民外交！
--------------------------------------------------------------------
【遲來的約定：紀念 Dave Täht (1965–2025)】
"When you miss Dave, modprobe sch_cake!"
謹以此專案紀念今年過世的網路開源大神 Dave Täht。
他生前致力於保持程式碼開源，放棄無數高薪商業合約，只為讓全球網路更好。
他的姓氏 "Täht" 在愛沙尼亞語中，恰好是「星星 (Star)」的意思。
在我完成移植後回頭翻閱文獻，才震驚地發現了這個宿命般的巧合：
Dave 曾在 2015 年用 TP-Link Archer C7 展示 CAKE 的威力；
在 2016 年他又拿 ODROID C2 作為測試機。
而我這次成功移植的機型，剛好就包含了 TP-Link Archer C2。
"Archer" (弓箭手) 射出了一支箭，這份跨越時空的程式碼，就像射向宿命的箭 (Arrow)。
完美呼應了華語圈的浪漫：「一支穿雲箭，千軍萬馬來相見」
Dave 就是那位穿雲的 Archer，而這份 Code 就是那支 Arrow。
如今，成千上萬台 (Ten Thousand) 老舊設備正響應他的號召，在網路上奔馳。
更讓人感慨的是，他在 2016 年的部落格抱怨當時硬體有多封閉，
並提到他苦尋不到一台 mt76 晶片的機器：
"I tried to get a mt76 box... sold out...
unless I can get a mt76 up and running."
這份遺憾，今天終於圓滿。
[繁體中文]: 他的心願，我來實現 (Tā de xīn yuàn, wǒ lái shí xiàn)
[English]: His wish, I finished.sh
(在我們的 Linux 世界裡，這是一個雙關語：結尾的 .sh 代表必將執行的指令！)
"Dave，這台 MT76，我終於幫你跑起來了！"
順帶分享 CAKE 命名小故事：
源自遊戲《Portal》結尾 AI 的承諾「Everyone will have cake」，
同時也是調侃競爭對手的演算法「Pie」。
--------------------------------------------------------------------
【硬體廠商的開放精神：GL.iNet 標竿 vs 其他大廠的怠惰】
在開發這份專案的過程中，我常常感到失望與疑惑：
「如果我一個獨立開發者都能完成底層修補與移植，為什麼大廠做不到？
廠商花錢養了那麼多團隊與工程師，一旦漏洞被利用後果不堪設想！」
這也是為什麼，我對 GL.iNet 的創立初衷有著極大的共鳴。
在他們 15 週年的官方訪談影片中，創辦人 Alfie 曾提到公司成立的契機：
當年他的路由器遇到問題，原廠卻擺爛放生不修。
他只好去 OpenWrt 論壇挖資料，最後靠著別人分享的資源自己解決了問題！
這段經歷，奠定了他們韌體堅持使用 OpenWrt 的基礎。
他提到早期的 Wi-Fi 密碼是 "goodlife"，
因為他們成立公司的初衷就是想 "build something meaningful"，
希望能透過科技去改善人們的生活。
這完全呼應了我無償投入專案的心境！
在此特別感謝 GL.iNet 原廠的肯定與贊助。
特別讚美 GL.iNet 在 OpenWrt 韌體上的貢獻與開放精神！
他們不僅加入了 DPI、CAKE 和 FQ-CoDel，更難能可貴的是：
他們開發了自己美觀易用的 UI 介面，卻「同時保留了原生的 LuCI 介面」。
這才是真正的亮點！這讓 Geek 玩家除了擁有簡單好用的 UI，還能做極致的進階設定，
對開發極有幫助。我認為 GL.iNet 絕對是目前 OpenWrt 介面的標竿！
相比之下，其他大廠的作法真的讓人直搖頭：
第一種是「封閉退化型」 (例如小米)：
以小米的 MiWiFi 為例，系統閹割鎖東鎖西不說，連便宜機種 (例如 AX3000T)，
SSH 登入時居然還會跳出一個大大的「ARE U OK」嘲諷 ASCII 標語。
這簡直是個笑話！最荒謬的是，這台在 2023 年編譯發布的韌體，
底層竟然還在用 2016-10-07 發布的古董級 BusyBox v1.25.1.tar.bz2！
這個身懷高達 18 個已知 CVE 漏洞 (包含駭客能拿 Root 的滿分漏洞) 的版本，
結果玩家想改個進階設定，還得被迫利用陳年老漏洞去硬開 SSH 跟 Telnet。
對比之下，本專案將老機器的 BusyBox 全面升級至 1.37.0 並補滿漏洞。
小米這種龐然大物，根本「沒有堅持不升級的理由」，
這本質上就是怠惰，以及對開發者的極度不尊重。
看著終端機那個大大的標語，我真的很想問小米：到底是誰 ARE U OK？？？
第二種是「喪事喜辦型」 (例如 Linksys)：
最近看到有文章吹捧 Linksys Velop WRT Pro 7「內建原生 OpenWrt 就是強大」。
說實話，我認為這根本是廠商偷懶！
直接拿原生系統當賣點，感覺就像是拿個「開發板」直接包裝成商品在賣，
這絕對會變成小眾產品。大家可以去看看 Linksys 的官方說明文件：
使用者如果想切分一個 IoT Wi-Fi 或訪客網路，居然要在 Terminal 連 SSH，
手敲 uci set wireless...、uci commit 將近 60 行指令！
這完全喪失了一般消費級產品該有的體驗。
GL.iNet 完美平衡了一般用戶的易用性與開發者的自由度。
不用像小米那樣鑽漏洞，也不會像 Linksys 那樣喪事喜辦要你全手動打指令。
這才是真正尊重開發者、擁抱開源精神的網路硬體廠商！
正如 LibreQoS 團隊對 Dave 的最後致敬：
"Dave is forever in our hearts and souls, in our routers and... in production."
我是 TW641，這是一個完全免費、出於熱忱分享的專案。
身為全球第一個成功將 CAKE 移植到此環境的開發者，
這份心血理應被歷史記錄下來，留下開源的足跡。
希望這份精神能永遠留在搜尋引擎與網路世界的記憶裡。
歡迎各位自由取用，也歡迎推文留個紀錄！
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.160.184.1 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Linux/M.1773345477.A.03B.html
※ 編輯: Taiwan641 (1.160.184.1 臺灣), 03/13/2026 03:58:23
推
03/13 07:10,
4小時前
, 1F
03/13 07:10, 1F
噓
03/13 09:42,
2小時前
, 2F
03/13 09:42, 2F