大家好，我是 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 恩怨情仇： CAKE 是在 Kernel 4.19 才纳入主线。 为改善 tc 与 CAKE 的相容性，我将 libmnl 升级至 1.0.5。 最痛苦的踩坑点在 iptables 升级：新版底层严重依赖 nftables 的 xshared。 我的 4.4.198 内核一定要降回 1.8.7 才能成功对外连线。 我从官方 commit log 逐一挑选了 100 个 patch 进行编译测试， 最後精简出 53 个才完美运作 (移除了 xshared重构, xlate翻译 等)。 为避免伺服器阻挡连线，我将这 53 个成功下载的 patch 上传到专案， 并写入 YAML 比对逻辑动态套用，成功修复多个 ramleak 与稳定性问题。 这证实了剥离 nftables 共用依赖才是正解。 反观极老旧的 3.4.113 核心，推测是不会触发 xshared 的雷， 竟能直上 1.8.11 并打上所有上游 commit，稳定运行无 Bug！ 2. CAKE 与 HWNAT/SFE 的三层拦截共存机制： 这也是为何我非得修复 hw_nat 工具不可， 否则根本无从验证连线是否成功 bind 到 PPE！ 为了极致效能，我将硬体加速绑定阈值从 30 降到 1， 尽最大努力把连线塞进 PPE。 经过实测验证，CAKE、HWNAT 与 SFE (shortcut-fe) 是可以完美共存且不当机的。它们的运作逻辑宛如「三层过滤漏斗」： 第一层：PPE 绝对不偷懒，能硬体加速的封包直接绕过 CPU。 第二层：PPE 无法加速的封包，落入 SFE 拦截网，执行软体捷径转发。 第三层：SFE 处理不了的封包走传统 CPU 转发， 此时由 CAKE 全权接管做 AQM 排序塑形。 虽然这三者的程式码本质上无法互相传递封包标记， 但确实能各自拦截对应的流量。 内网极速交给 HWNAT+SFE，未加速的残余流量交给 CAKE 守底线， 将硬体潜能榨乾！ 3. 复活无线中继 (WISP/APCLI) 的 HWNAT 硬体加速： 以往韧体在中继模式下硬体加速会失效。 - 3.4 核心：修复了 IP 取值的记忆体错位 Bug，并补齐 PPE 注册。 - 4.4 核心：我发现上游的 ra_nat.c 写死了一段逻辑： if (strncmp(dev->name, "apcli", 5) == 0) return; 导致网卡名称包含 apcli 就直接跳过！我解除了这个封印限制， 并修正了介面对应 (如 dst_port[DP_APCLI0] = ra_dev_get_by_name)。 现在终端机会大声喊出 Bind Interface [apcli0] success! 4. 修复 HWNAT 记忆体错位与显示异常 (Unaligned Access)： 原厂 hw_nat 工具取值写法不够严谨。 在 MIPS 架构下有严重的非对齐存取 Bug， 这导致抓到的连线 IP 或 Port，常出现 109.20.106.8:00000 或是 0.0.0.0:00000 这种半残半开的乱码。 为了解决这个问题，我先在 hwnat_ioctl.h 的结构体尾端 追加 __attribute__ ((packed))。 接着在 hw_nat_api.c 的格式化输出前，手动将 args->entries[i] 的资料 提取到严谨的局部变数 (如 unsigned int i_sip, e_sip 以及 IPv6 的 is6[4], id6[4] 阵列)， 再送进 printf 格式化输出。这彻底解决了指标与记忆体错位问题， 确保了 malloc 分配後的稳定性，也排除了潜在的 RAM Leak！ 5. 模组化 YAML 升级 BusyBox 1.37.0 与底层安全性修补： 这是一切灾难与成就的起源！原厂设定档还停在 BusyBox 1.24.2， 身怀 CVSS 9.8 满分的堆叠溢位漏洞 (CVE-2022-48174)。 为了「尊重原开发者」，我选了一条最难的路：不去破坏原来的原始码仓库， 全靠 YAML 脚本修改 Docker runner 的对应路径，进行「模组化即时 Patch」。 我在 YAML 中用 grep 和 sed 大量替换 build_firmware 与 user/ 内的版本号， 并加上 if 判断式，只要查到残留的 1.24.x 代码就直接 exit 1 中断防呆！ 期间揪出了 syslogd 导致日志启动後全部空白的 Bug， 透过脚本动态写入 services_syslogd_fix.patch (补上 "-L" 参数) 才解决。 这就是模组化的初衷：哪里坏修哪里，证明老设备也能有无痛的顶级安全！ 6. 引入 GitHub Actions 云端自动化编译与多国语系： 写好 Workflow，免除本地端架设 Ubuntu 的麻烦。 这是我努力的证明：光是 Padavan 相关的 Repo 我就跑了数百次 Workflow (166+108+27+12+11+106次...)。因为 YAML 没得互动只能狂按 Enter 试错， 光 Busybox 那段脚本就试了 50 几次才终於成功跑完这严谨度 100% 的自动化流程！ 现在只要 Fork 过去，透过下拉选单选择 Target，就能自动产出韧体档。 目前精准支援 142 款机型，且系统内建高达 14 种语言包 (含繁体中文)， 打破网路无国界的限制。 -------------------------------------------------------------------- 【来自国际开源界与总统级的肯定 (真正的数位国民外交)】 这个专案不仅成功在台湾论坛发布，更在国际开源社群引起了巨大的回响， 这对身为唯一开发者的我来说，是极大的肯定与惊喜： 1. 来自捷克的国际开源大神亲自认可： 我的 GitHub 专案获得了 LibreQoS 营运长 Frantisek (Frank) Borsik 的亲自追踪与肯定！Frank 来自捷克布拉格，在国际开源网路界大有来头， 曾负责知名开源路由器 Turris (OpenWrt) 及 RF elements 的核心推广。 这代表本专案已成功打入全球「对抗 Bufferbloat」社群的最核心圈！ 能与来自友好捷克的专家交流，真的是莫大的荣幸。 2. 来自日本的顶尖网路学者跨国关注： 日本顶尖名校庆应义塾大学 (Keio University) 的 Dikshie 博士 也亲自给予此专案关注与认可！博士专攻 P2P 网路与网际网路架构， 能获得这类精於底层基础设施的重量级学者肯定， 证明了这份演算法移植的技术含金量极高！ 有趣的是，我好奇查了一下： 发现博士 14 年前居然也在 PTT 的 FreeBSD 板发过求救救文！ 能在开源界和 PTT 神兽相遇，这努力过的痕迹真的很神奇XD 3. 总统级的数位国民外交： LibreQoS 官方甚至在 X (Twitter)、Facebook 与 LinkedIn 等国际社群平台上发布贴文致敬， 将这个专案誉为给 Dave Täht 的 "Time-Traveling Valentine's Gift"， 并在文中史无前例地标注了台湾总统赖清德、前总统蔡英文与总统府发言人！ 能让台湾的开源技术贡献跃上国际版面，真的是货真价实的国民外交！ -------------------------------------------------------------------- 【迟来的约定：纪念 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://webptt.com/cn.aspx?n=bbs/LinuxDev/M.1773345235.A.F8B.html ※ 编辑: Taiwan641 (1.160.184.1 台湾), 03/13/2026 03:54:16 ※ 编辑: Taiwan641 (1.160.184.1 台湾), 03/13/2026 19:07:45