作者Taiwan641 (641)
看板Broad_Band
标题[无线] CAKE移植 Padavan TP-Link Archer C2 V1 斐讯 K2P A1/A2
时间Mon Jan 26 19:22:03 2026
全球首发！Taiwan No.1！台湾第一！世界第一！
本文章同步刊登於Mobile01论坛：
https://www.mobile01.com/topicdetail.php?f=110&t=7220226
PTT排版不易，若伤了您的双眼，还请您谅解！
有些内容是无论我编辑几次都无法修正的，句子被截断，後面跑出?之类的奇怪状况，若您真的有需要看原文，可以直接看上面这篇Mobile01的网址，在那边显示是完全正常的。
PTT这边是我把Mobile01的原文转过来分享的，如果您刚好是这两个路由器机型，注重资安且有自行动手的能力，您可以选择更新到我使用Github Actions云端编译成功的韧体，韧体纯净，大幅度精简不必要的功能和存在漏洞的老旧协定，程式码完全开源，有兴趣的人可以自行研究。
[许愿1]：希望小米、TP-Link、ASUS 华硕、D-Link 友讯、Zyxel 合勤、Linksys、NETGEAR
如果贵公司愿意提供任何贵公司的开发板或新产品或试用产品，可以透过Mobile01站内讯息
看到下面这篇文章的分享，好想要那片WiFi 8 开发板、WiFi 7 的 GT-BE19000和那台WiFi
https://www.mobile01.com/topicdetail.php?f=110&t=7216185
【CES2026】 WiFi 8 首度公开展示传输性能表现 传输速度略为提升／稳定度与涵盖范围是
[许愿2]：如果您看了这篇文章，发现您手边有用不到的、汰换的、还能用且功能良好的路?
若您愿意捐赠您的路由器给我，可以透过Mobile01站内讯息功能私讯我，或者是透过我的Gi
优先徵求型号：
ASUS ZenWifi XT9 AX7800
小米AX3000T：有分国际版(RD23)跟中国版(RD03)、小米WR30U
处理器型号：MT7981(mt7981-ax3000)、MT7986(mt7986-ax4200、mt7986-ax6000、mt7986-a
以下为上方型号之外的详细型号表：
360
360-T6M (360 安全路由 T6M)
ASUS (华硕)
RT-AC85P (华硕 ASUS RT-AC85P)
China Mobile (中国移动)
C-Life-XG1 (中国移动 China Mobile 和目 XG1)
D-Link (友讯)
DIR-878 (D-Link 友讯 DIR-878)
DIR-882 (D-Link 友讯 DIR-882)
Fuchunjiang (富春江)
G-AX1800 (富春江 Fuchunjiang G-AX1800)
G-AX1800-B (富春江 Fuchunjiang G-AX1800 黑色版)
GHL (华凌)
GHL (广州华凌 GHL R-045)
Haier (海尔)
HAR-20S2U1 (海尔 Haier / 营运商客制 HAR-20S2U1)
HiWiFi (极路由)
B70 (极路由 HiWiFi 4 增强版)
JCG (捷稀)
JCG-836PRO (捷稀 JCG JHR-AC836M PRO)
JCG-AC860M (捷稀 JCG AC860M)
JCG-Q20 (捷稀 JCG Q20 金刚坦克)
JCG-Y2 (捷稀 JCG Y2)
JCQ-Q10Pro (捷稀 JCG Q10 Pro)
JCQ-Q11Pro (捷稀 JCG Q11 Pro)
JDCloud (京东云)
JDCloud RE-CP-02 (京东云 JDCloud 无线宝 鲁班)
JDCloud RE-SP-01B (京东云 JDCloud 无线宝 1代/坐享其成版)
Komi (科米)
KOMI-A8 (科米 Komi A8)
Linksys (领势)
EA7500 (Linksys 领势 EA7500 v2)
Motorola (摩托罗拉)
MR2600 (Motorola 摩托罗拉 MR2600)
Netgear (Netgear / 网件)
NETGEAR-BZV (Netgear 网件 R6220)
NETGEAR-R6800 (Netgear 网件 R6800)
NETGEAR-R7450 (Netgear 网件 R7450)
Newifi (新路由)
NEWIFI (新路由 Newifi mini / Y1)
NEWIFI3 (新路由 Newifi 3 / D2)
Nokia Shanghai Bell (上海贝尔)
BELL-A040WQ (上海贝尔 Nokia Shanghai Bell A-040W-Q)
Phicomm (斐讯)
K2P (斐讯 Phicomm K2P)(A1/A2皆可)
K2P-USB (斐讯 Phicomm K2P 改USB版)
Qumei (曲美)
QM-B1 (曲美 Qumei / 营运商客制 QM-B1)
Raisecom (瑞斯康达)
MSG1500 (瑞斯康达 Raisecom MSG1500)
MSG1500-Z (瑞斯康达 Raisecom MSG1500-Z)
Sim Wireless
SIM-AX1800T (Sim Wireless SIM-AX1800T)
TP-Link (TP-Link / 普联)
WDR8620 (TP-Link 普联 TL-WDR8620)
TuoShi (拓实)
TX1801 Plus (拓实 TuoShi TX1801 Plus)
Tyco (泰科)
WE410443-TC (泰科 Tyco / 营运商客制 WE410443-TC)
Xiaomi (小米)
CR660x (小米 Xiaomi / 红米 Redmi CR6606/CR6608/CR6609 营运商客制版)
MI-4 (小米 Xiaomi 路由器4)
MI-R3G (小米 Xiaomi 路由器3G)
MI-R3P (小米 Xiaomi 路由器3 Pro)
MI-R4A (小米 Xiaomi 路由器4A Gigabit版)
R2100 (小米 Xiaomi 路由器 AC2100)
Redmi (红米)
RM2100 (红米 Redmi 路由器 AC2100)
XiaoYu (小娱)
XY-C1 (小娱 XiaoYu C1)
Xijia (西加云杉)
WIA3300-10 (西加云杉 Xijia WIA3300-10)
Youhu (友华)
WR1200JS (友华 Youhu / 摩云 WR1200JS)
WRL18M4GD (友华 Youhu / 联通客制 WRL18M4GD)
ZTE (中兴)
ZTE-E8820S (中兴 ZTE E8820S)
ZTE-E8820V2 (中兴 ZTE E8820 V2)
ZTT (中天科技)
ZTT-RX6000 (中天科技 ZTT RX6000)
[许愿3]：因为我没有微信支付，也没有支付宝，若您愿意赞助我一个注册中国技术论坛「?
==========================
许愿结束！韧体功能与分享开始！
==========================
TP-Link Archer C2 V1 Padavan 3.4.113+CAKE演算法移植+繁体中文台湾用语
实测HWNAT+SFE+CAKE+限速85M/43M(WISP 5G连上K2P的5G WiFi)
测速时，我连上的是 TP-Link Archer C2 V1 的 5G WiFi
以下为三次测速结果：
Redmi (红米)
RM2100 (红米 Redmi 路由器 AC2100)
XiaoYu (小娱)
XY-C1 (小娱 XiaoYu C1)
Xijia (西加云杉)
WIA3300-10 (西加云杉 Xijia WIA3300-10)
Youhu (友华)
WR1200JS (友华 Youhu / 摩云 WR1200JS)
WRL18M4GD (友华 Youhu / 联通客制 WRL18M4GD)
ZTE (中兴)
ZTE-E8820S (中兴 ZTE E8820S)
ZTE-E8820V2 (中兴 ZTE E8820 V2)
ZTT (中天科技)
ZTT-RX6000 (中天科技 ZTT RX6000)
[许愿3]：因为我没有微信支付，也没有支付宝，若您愿意赞助我一个注册中国技术论坛「?
==========================
许愿结束！韧体功能与分享开始！
==========================
TP-Link Archer C2 V1 Padavan 3.4.113+CAKE演算法移植+繁体中文台湾用语
实测HWNAT+SFE+CAKE+限速85M/43M(WISP 5G连上K2P的5G WiFi)
测速时，我连上的是 TP-Link Archer C2 V1 的 5G WiFi
以下为三次测速结果：
http://i.imgur.com/BKxgVyx.jpg
http://i.imgur.com/APkj4K6.jpg
台湾第一！ ！ ！
我相信这正是 Dave Täht 真正希望看到的！ ！ ！
Dave 贡献的程式码总是免费且开源的。
他拒绝了许多利润丰厚的合同，因为他始终把原则放在第一位——他重视的是他的代码在全
谨以此纪念 Dave Täht（1965–2025），他在 bufferbloat 方面的工作显着改善了互联网
https://libreqos.io/2025/04/01/in-loving-memory-of-dave/
PS：Dave 将永远活在我们心中，活在我们的路由器里，活在我们的生产环境中。ttps://gi
原厂的 Linux kernel version: 2.6.36
此韧体 Linux kernel version: 3.4.113
路由器的网页管理介面截图如下：
http://i.imgur.com/nInS4yq.jpg
http://i.imgur.com/fBf47HL.jpg
http://i.imgur.com/1dzgY61.jpg
http://i.imgur.com/YlpRjvS.jpg
http://i.imgur.com/mguIbu0.jpg
http://i.imgur.com/0pmAYtS.jpg
http://i.imgur.com/YDqr74f.jpg
http://i.imgur.com/NEKcjyr.jpg
http://i.imgur.com/jDcjxIb.jpg
http://i.imgur.com/XD9XmWf.jpg
http://i.imgur.com/h2q0rnz.jpg
http://i.imgur.com/BWVne8v.jpg
+ Busybox 1.37.0 已修正安全漏洞 CVE-2025-60876 (Max CVSS 6.5) 和 CVE-2025-46394
我已经检视过原厂提供的程式码，原厂搭配使用的是Busybox 1.19.2，到今天为止，这个版
https://reurl.cc/gnX0yL
Busybox 1.19.2版本存在的CVE漏洞高达24个，目前1.37.0已知3个CVE漏洞，已修补上述两?
存在堆叠溢位漏洞。在车联网环境下，此漏洞可利用来执行任意命令和任意程式码。不过在
这非常重要，路由器是以root权限运作，也就是最高权限在运行，一旦漏洞被利用，後果是
大部分的路由器是24小时不间断运行的，存在的漏洞越多，越可能会让骇客有机可趁！
附上原厂GPL原始码内使用的套件，全都是将近12年前的内容：
http://i.imgur.com/jkvnkC2.jpg
+ Iptables 1.8.11，已结合最新程式码上游commit修补
原厂程式码使用的是iptables 1.4.17，iptables本身的CVE漏洞不多，使用新版可增强相容
+ Arptables 0.0.5，原厂程式码不包含此套件，arptables的主要用途之一是防范ARP欺骗?
此版本为2019-12-02发布的版本，已经是最新版了！
在Arptables 0.0.5发布後，只有新增一条commit log：
於2024-03-09修复了：Fix a couple of spelling errors：One mistake in a man-page,
白话文：就只是拼字错误而已，例如：
原为：-.SS MISCELLANOUS COMMANDS
改为：+.SS MISCELLANEOUS COMMANDS
原为：- printf("Warning: wierd character in interface"
改为：+ printf("Warning: weird character in interface"
结论：这不重要！所以我就不套用patch了！直接用Arptables 0.0.5的原始码套件编译完成
+ 针对 16:9 宽萤幕和 1920x1080 解析度最佳化 WebUI。
+ MT7610E 驱动程式补丁（防断开连接和快速重连）
（防断线：原先的信标逾时时间为 12 秒，应用信标逾时补丁後，
时间是60秒。
快速重连：对等断开连接逻辑已更改！快速重连模式已启用！ ）
+ 将 HWNAT 绑定阈值设为 1。 （HWNAT 将更快地整合到您的连接中，并显着降低 CPU 负载。
+ 修复了 HWNAT 错误，并提高了 HWNAT 启动绑定和取消绑定介面工作流程的清晰度。
在我修改之前，由於记忆体错位，显示的 IP 位址和连接埠完全错误。
我还修复了原MTK程式码中的IP值检索逻辑，并显着提高了程式码的稳定性！
HWNAT 错误已修正：显示所有Foe无效条目、显示所有Foe未绑定条目、显示所有Foe已绑定?
输入指令：hw_nat -e hw_nat -f hw_nat -g 现在将列印出正确的 IP 和连接埠资讯。
提高 HWNAT 启动绑定和解绑定介面工作流程的清晰度：例如，您将在日志中看到 HWNAT 执
以下是您将在日志中看到的透明过程，让您清楚地了解 HWNAT 执行的操作。
「启动绑定介面」工作流程的日志，例如：
1月25日 01:48:58 核心：HWNAT：===> 开始绑定介面...
1月25日 01:48:58 核心：HWNAT：绑定介面 [ra0] 成功！ （索引：11）
1月25日 01:48:58 核心：HWNAT：绑定介面 [ra1] 成功！ （索引：12）
1月25日 01:48:58 核心：HWNAT：绑定介面 [wds0] 成功！ （索引：27）
1月25日 01:48:58 核心：HWNAT：绑定介面 [wds1] 成功！ （索引：28）
1月25日 01:48:58 核心：HWNAT：绑定介面 [wds2] 成功！ （索引：29）
1月25日 01:48:58 核心：HWNAT：绑定介面 [wds3] 成功！ （索引：30）
1月25日 01:48:58 核心：HWNAT：绑定介面 [apcli0] 成功！ （索引：31）
1月25日 01:48:58 核心：HWNAT：绑定介面 [rai0] 成功！ （索引：33）
1月25日 01:48:58 核心：HWNAT：绑定介面 [rai1] 成功！ （索引：34）
1月25日 01:48:58 核心：HWNAT：绑定介面 [wdsi0] 成功！ （索引：49）
1月25日 01:48:58 核心：HWNAT：绑定介面 [wdsi1] 成功！ （索引：50）
1月25日 01:48:58 核心：HWNAT：绑定介面 [wdsi2] 成功！ （索引：51）
1月25日 01:48:58 核心：HWNAT：绑定介面 [wdsi3] 成功！ （索引：52）
1月25日 01:48:58 核心：HWNAT：绑定介面 [apclii0] 成功！ （索引：53）
1月25日 01:48:58 核心：HWNAT：绑定介面 [eth2] 成功！ （索引：60）
1 月 25 日 01:48:58 核心：HWNAT：<=== 绑定完成。
「开始解绑定介面」工作流程的日志，例如：
1月25日 21:08:06 核心：HWNAT：===> 开始解除介面绑定（模组清理）...
1月25日 21:08:06 核心：HWNAT：解除绑定介面 [ra0]（索引：11）
1月25日 21:08:06 核心：HWNAT：解除绑定介面 [ra1]（索引：12）
1月25日 21:08:06 核心：HWNAT：解除绑定介面 [wds0]（索引：27）
1月25日 21:08:06 核心：HWNAT：解除绑定介面 [wds1]（索引：28）
1月25日 21:08:06 核心：HWNAT：解除绑定介面 [wds2]（索引：29）
1月25日 21:08:06 核心：HWNAT：解除绑定介面 [wds3]（索引：30）
1月25日 21:08:06 核心：HWNAT：解除绑定介面 [apcli0]（索引：31）
1月25日 21:08:06 核心：HWNAT：解除绑定介面 [rai0]（索引：33）
1月25日 21:08:06 核心：HWNAT：解除绑定介面 [rai1]（索引：34）
1月25日 21:08:06 核心：HWNAT：解除绑定介面 [wdsi0]（索引：49）
1月25日 21:08:06 核心：HWNAT：解除绑定介面 [wdsi1]（索引：50）
1月25日 21:08:06 核心：HWNAT：解除绑定介面 [wdsi2]（索引：51）
1月25日 21:08:06 核心：HWNAT：解除绑定介面 [wdsi3]（索引：52）
1月25日 21:08:06 核心：HWNAT：解除绑定介面 [apclii0]（索引：53）
1月25日 21:08:06 核心：HWNAT：解除绑定介面 [eth2]（索引：60）
1月25日 21:08:06 核心：HWNAT：<=== 所有介面已释放。引擎处於空闲状态。
下载连结：
https://reurl.cc/1kN2aD
1. 下载附件「padavan_pack_TPLINK_TL_C2-V1.zip」档案（6.64 MB）
2. 从压缩包中提取“TL_C2-V1_3.4.3.9L-102-0de6f2f424.bin”档案。
3. 检查「TL_C2-V1_3.4.3.9L-102-0de6f2f424.bin」档案的杂凑值 - MD5: ed8002b376c4c
（压缩档案「padavan_pack_TPLINK_TL_C2-V1.zip 档案（6.64 MB）」中包含「md5sum.txt
如果您需要在更新韧体之前检查杂凑值，
您可以在「md5sum.txt」档案的底部找到「TL_C2-V1_3.4.3.9L-102-0de6f2f424.bin」档案
4. 开启路由器的网页介面
（找到您的 IPv4 网关位址，并将该位址输入到浏览器的网址列中。）
5. 管理 > 韧体更新
（
http://192.168.0.1/Advanced_FirmwareUpgrade_Content.asp）
（例如，如果「192.168.0.1」是您的IPv4网关位址，您可以复制并贴上上面的链接，
如果「192.168.0.1」不是您的IPv4网关位址，则需要您自行变更「
http://192.168.0.1」?
否则，您在浏览器网址列输入连结後将不会收到任何回应。 ）
6. 选择 TL_C2-V1_3.4.3.9L-102-0de6f2f424.bin 文件，然後按一下「上传」按钮。
7. 尽情享受吧！ ！ ！
如果您的TP-Link Archer C2 V1 已经有Padavan 韧体了，您可以选择直接下载下方的压缩档
https://reurl.cc/MMKbQ4
[点这里下载 padavan_pack_TPLINK_TL_C2-V1.zip]
如果您的TP-Link Archer C2 V1 还是官方原厂韧体，请先依照下方步骤完成刷入别的开发?
https://reurl.cc/ORKpND
[点这里下载 ArcherC2V1_tp_recovery.zip]
Google繁体中文机器翻译(如果看不懂机器翻译的中文，请参阅英文原文交叉比对)：
资料来源：
https://4pda.to/forum/index.php?showtopic=900745&view=findpost&p=84602
嗯，在阅读了这里的帖子後，我终於找到了解决方案。如果有人像我一样，在刷固件後路由
我把它安装在 Archer C2V1 上，效果很好。
1. 下载韧体压缩套件：ArcherC2V1_tp_recovery.zip
2. 从压缩套件中提取韧体档案－ArcherC2V1_tp_recovery.bin
3. 将韧体 bin 档案复制到 Tftpd64 资料夹
4. 依照提供的说明进行配置，以管理员身分执行 Tftpd64，然後刷写韧体。
- 关闭路由器
- 将网路线连接到路由器的第 4 个连接埠
- 在网路卡属性中，设定静态 IP 位址：192.168.0.66，子网路遮罩：255.255.255.0
- 在 tftpd 程式的设定中，勾选「使用预处理视窗」选项，并将值设为 1000
- 在 Windows 的网路卡设定中，将网路模式设定为半双工（10 毫秒）
- 启动 TFTP 伺服器，选择韧体所在的资料夹
- 按住 WPS/重置按钮
- 按住 WPS/重置按钮的同时开启路由器
- 按住 WPS/重置按钮直到 WPS 指示灯亮起（约 10-15 秒），然後放开按钮
- 等待约 5 分钟
- 在网路卡属性中，设定动态 IP 位址（自动取得 IP 位址）
- 存取该网址192.168.1.1
=========================================================================
资料来源：
https://pikabu.ru/story/proshivka_tplink_archer_c2_na_openwrt_5525675
- 关闭路由器
- 将网路线连接到路由器的第四个端口
- 在网路卡属性中，设定静态 IP 位址：192.168.0.66，子网路遮罩：255.255.255.0
- 启动 TFTP 伺服器，选择韧体所在的资料夹
- 按住 WPS/重置按钮
- 按住 WPS/重置按钮的同时开启路由器
- 按住按住 WPS/重置按钮，直到 WPS 指示灯亮起（约 10-15 秒），然後放开按钮。
- 等待约 5 分钟。
- 在网路卡属性中，设定动态 IP（自动取得 IP 位址）。
- 存取网址 192.168.1.1。
- 完成！
英文说明：
Please visit the link below. You can get the latest firmware there.
https://github.com/TWShiyuLiou1997/padavan-builder-workflow/releases
If you are finding a stable release with Padavan + Linux kernel 3.4.113 with a l
+ Common Applications Kept Enhanced (CAKE) scheduler backport
This could be the world's first successful backport of "cake" to the Padavan wit
Taiwan No.1!!!
I believe this is something Dave Täht truly hoped for!!!
The code Dave contributed was always free and open source.
He turned down numerous lucrative contracts because he always put his principles
In memory of Dave Täht (1965–2025), whose work on bufferbloat helped make the5
https://libreqos.io/2025/04/01/in-loving-memory-of-dave/
PS: Dave is forever in our hearts and souls, in our routers and… in production.
+ Busybox 1.37.0 with CVE-2025-60876 & CVE-2025-46394 Security Patched
+ Iptables 1.8.11 with Upstream commit Patched
+ Arptables 0.0.5
+ Optimize WebUI for 16:9 wide screen with 1920x1080 resolution.
+ Patch MT7610E Driver (Anti-Disconnect & Fast Reconnect)
(Anti-Disconnect: The original Beacon Timeout is 12 seconds, after Beacon Timeou
it will be 60 seconds.
Fast Reconnect: Peer Disconnect Logic changed! Fast Reconnect Mode Enabled!)
+ HWNAT binding threshold set to 1.(HWNAT will integrate into your connection fa
+ HWNAT error fixed and improve the clarity of HWNAT Start Binding and Unbinding
Before my modifications, the displayed IP and port were completely incorrect due
I also additionally fixed the IP value retrieval logic within the original MTK c
HWNAT error fixed: Show All Foe Invalid Entry, Show All Foe Unbinded Entry, Show All Foe Binded Entry.
Input Command: hw_nat -e hw_nat -f hw_nat -g will print out the correct IP and port infomation now.
Improve the clarity of HWNAT Start Binding and Unbinding Interfaces workflows: For example, you will see the actions what HWNAT done in log.
Below is the transparent process you'll see in the logs, giving you a clear understanding of what HWNAT has done.
Logs of "Start Binding Interfaces" workflows just like:
Jan 25 01:48:58 kernel: HWNAT: ===> Start Binding Interfaces...
Jan 25 01:48:58 kernel: HWNAT: Bind Interface [ra0] success! (Index: 11)
Jan 25 01:48:58 kernel: HWNAT: Bind Interface [ra1] success! (Index: 12)
Jan 25 01:48:58 kernel: HWNAT: Bind Interface [wds0] success! (Index: 27)
Jan 25 01:48:58 kernel: HWNAT: Bind Interface [wds1] success! (Index: 28)
Jan 25 01:48:58 kernel: HWNAT: Bind Interface [wds2] success! (Index: 29)
Jan 25 01:48:58 kernel: HWNAT: Bind Interface [wds3] success! (Index: 30)
Jan 25 01:48:58 kernel: HWNAT: Bind Interface [apcli0] success! (Index: 31)
Jan 25 01:48:58 kernel: HWNAT: Bind Interface [rai0] success! (Index: 33)
Jan 25 01:48:58 kernel: HWNAT: Bind Interface [rai1] success! (Index: 34)
Jan 25 01:48:58 kernel: HWNAT: Bind Interface [wdsi0] success! (Index: 49)
Jan 25 01:48:58 kernel: HWNAT: Bind Interface [wdsi1] success! (Index: 50)
Jan 25 01:48:58 kernel: HWNAT: Bind Interface [wdsi2] success! (Index: 51)
Jan 25 01:48:58 kernel: HWNAT: Bind Interface [wdsi3] success! (Index: 52)
Jan 25 01:48:58 kernel: HWNAT: Bind Interface [apclii0] success! (Index: 53)
Jan 25 01:48:58 kernel: HWNAT: Bind Interface [eth2] success! (Index: 60)
Jan 25 01:48:58 kernel: HWNAT: <=== Binding Complete.
Logs of "Start Unbinding Interfaces" workflows just like:
Jan 25 21:08:06 kernel: HWNAT: ===> Start Unbinding Interfaces (Module Cleanup).
Jan 25 21:08:06 kernel: HWNAT: Unbind Interface [ra0] (Index: 11)
Jan 25 21:08:06 kernel: HWNAT: Unbind Interface [ra1] (Index: 12)
Jan 25 21:08:06 kernel: HWNAT: Unbind Interface [wds0] (Index: 27)
Jan 25 21:08:06 kernel: HWNAT: Unbind Interface [wds1] (Index: 28)
Jan 25 21:08:06 kernel: HWNAT: Unbind Interface [wds2] (Index: 29)
Jan 25 21:08:06 kernel: HWNAT: Unbind Interface [wds3] (Index: 30)
Jan 25 21:08:06 kernel: HWNAT: Unbind Interface [apcli0] (Index: 31)
Jan 25 21:08:06 kernel: HWNAT: Unbind Interface [rai0] (Index: 33)
Jan 25 21:08:06 kernel: HWNAT: Unbind Interface [rai1] (Index: 34)
Jan 25 21:08:06 kernel: HWNAT: Unbind Interface [wdsi0] (Index: 49)
Jan 25 21:08:06 kernel: HWNAT: Unbind Interface [wdsi1] (Index: 50)
Jan 25 21:08:06 kernel: HWNAT: Unbind Interface [wdsi2] (Index: 51)
Jan 25 21:08:06 kernel: HWNAT: Unbind Interface [wdsi3] (Index: 52)
Jan 25 21:08:06 kernel: HWNAT: Unbind Interface [apclii0] (Index: 53)
Jan 25 21:08:06 kernel: HWNAT: Unbind Interface [eth2] (Index: 60)
Jan 25 21:08:06 kernel: HWNAT: <=== All interfaces released. Engine is IDLE.
Download link:
https://reurl.cc/1kN2aD
1. Download the Attached file "padavan_pack_TPLINK_TL_C2-V1.zip" file (6.64 MB)
2. Extract the "TL_C2-V1_3.4.3.9L-102-0de6f2f424.bin" file from the archive
3. Check the hash of the "TL_C2-V1_3.4.3.9L-102-0de6f2f424.bin" file - MD5: ed8002b376c4cfc5c152f01aa3a2f58b
(In the archive "padavan_pack_TPLINK_TL_C2-V1.zip file (6.64 MB)" have a "md5sum.txt",
if you need to check hash before updating your firmware,
you can find out the hash of the "TL_C2-V1_3.4.3.9L-102-0de6f2f424.bin" file in the bottom of the "md5sum.txt".)
4. Go to the router's web interface
(Find out your IPv4 gateway address and enter the link to the address bar of your browser.)
5. Administration > Firmware update
(
http://192.168.0.1/Advanced_FirmwareUpgrade_Content.asp)
(For example, if "192.168.0.1"is your IPv4 gateway address, you can copy and paste the link above,
if "192.168.0.1"is "not" your IPv4 gateway address, "
http://192.168.0.1" is needed to be change by yourself,
otherwise you will not receive any responce after you enter the link to the address bar of your browser.)
6. Select the TL_C2-V1_3.4.3.9L-102-0de6f2f424.bin file and click "Upload" button.
7. Enjoy it!!!
英文说明：
From:ttps://4pda.to/forum/index.php?showtopic=900745&view=findpost&p=84602850
Well, after reading the posts here, I finally found a solution. If anyone else experiences a bricked router like me after flashing the firmware, where all the indicators simply blink and the router isn't detected in the system, I have a ready-made Padavan firmware mod from Linaro. You don't need to do anything with it. Just drop it into the Tftpd64 folder, configure its connection, and flash it.
I installed it on an Archer C2V1, and it works great.
1. Download the firmware zip archive: ArcherC2V1_tp_recovery.zip
2. Extract the firmware from the archive - the ArcherC2V1_tp_recovery.bin file
3. Copy the firmware bin file to the Tftpd64 folder
4. Configure according to the included instructions, run Tftpd64 as administrator, and flash it.
- Turn off the router
- Connect the cable to the 4th port of the router
- In the properties of the network card, set a static IP: 192.168.0.66, mask: 255.255.255.0
- In the tftpd program, in the settings, check the Use anticipation window of and the value 1000
- In the network card settings in Windows, set 10 half-duplex mode
- Start the TFTP server, select the folder with the firmware
- Hold down the WPS / Reset button
- Turn on the router (while holding the WPS / Reset button)
- hold the WPS / Reset button until the WPS indicator lights up (~ 10-15 seconds), then you can release the button
- Wait about 5 minutes
- In the properties of the network card, set a dynamic IP (Obtain an IP address automatically)
- Go to the address 192.168.1.1
===========================================================================
From:ttps://pikabu.ru/story/proshivka_tplink_archer_c2_na_openwrt_5525675
- Turn off the router
- Connect the cable to the 4th port of the router
- In the network card properties, set a static IP: 192.168.0.66, mask: 255.255.255.0
- Start the TFTP server, select the folder with the firmware
- Press and hold the WPS/Reset button
- Turn on the router (while holding the WPS/Reset button)
- hold the WPS/Reset button until the WPS indicator lights up (~ 10-15 seconds),
- We'll wait about 5 minutes.
- In the network card properties, set the dynamic IP (Obtain an IP address autom
- Go to address 192.168.1.1
- Profit!
========================================================
以下开始为Phicomm K2P A1 A2 Padavan 4.4.198+CAKE演算法移植+繁体中文台湾用语
========================================================
实测HWNAT+SFE+CAKE+限速85M/43M(WISP 2.4G连上上游AP的2.4G WiFi)
测速时，我连上的是 K2P 的 5G WiFi
以下为三次测速结果：
http://i.imgur.com/Pu7yRn5.jpg
http://i.imgur.com/4bWFzwe.jpg
http://i.imgur.com/tt7VOHB.jpg
下方是韧体下载连结：
https://reurl.cc/jmKk0D
您也可以从下方直接下载：
https://reurl.cc/bNKkp3
以下为韧体的MD5杂凑值以及对应的韧体档案名称，您也可以自行比对压缩档内的「md5sum.
您可以在「md5sum.txt」档案的顶部找到「K2P-Padavan-NG-20260123-2042.trx」这个档案
您也可以直接看下方我提供的，这是一模一样的东西：
4f60b924d7382946b4fbb039c6efcbb4 K2P-Padavan-NG-20260123-2042.trx
若您本来就在使用Padavan韧体，直接更新韧体就可以了，若您需要刷机，您可以自行Googl
若您已经不使用K2P A1或A2版本了，您愿意捐赠给我，也是可以的！
因为我也不知道手边这台K2P什麽时候会坏掉，若您愿意割爱，也有可能让这个开发延续下?
韧体特色：
原厂的 Linux kernel version: 未知，但推测可能是：2.6.36
(斐讯已倒闭，程式码也没有开源，根据MTK原始码推断，高机率是2.6.36)
此韧体 Linux kernel version: 4.4.198
路由器的网页管理介面截图如下：
http://i.imgur.com/gZ900DF.jpg
http://i.imgur.com/7glR2LN.jpg
http://i.imgur.com/qxgEKTK.jpg
http://i.imgur.com/tEhG1VR.jpg
http://i.imgur.com/XKPcBD2.jpg
http://i.imgur.com/Zzdr6RC.jpg
http://i.imgur.com/CRi8pRI.jpg
http://i.imgur.com/IAqJdBD.jpg
http://i.imgur.com/xOcO24J.jpg
http://i.imgur.com/BnaJFF4.jpg
http://i.imgur.com/jHrcL0f.jpg
http://i.imgur.com/IUzuqjE.jpg
+ 移植成功：通用应用程式增强版 (CAKE) 调度器
+ 针对 16:9 宽萤幕和 1920x1080 解析度最佳化 WebUI。
+ Busybox 1.37.0 已修正 CVE-2025-60876 和 CVE-2025-46394 安全漏洞(原始开发者搭配
存在堆叠溢位漏洞。在车联网环境下，此漏洞可利用来执行任意命令和任意程式码。不过在
Busybox 1.24.2所包含的CVE漏洞清单，请看：
https://reurl.cc/eVK6YK
这非常重要，路由器是以root权限运作，也就是最高权限在运行，一旦漏洞被利用，後果是
大部分的路由器是24小时不间断运行的，存在的漏洞越多，越可能会让骇客有机可趁！
+ libmnl 1.0.5，从原始开发者的程式码搭配使用的 1.0.4 提升到 1.0.5，改善 tc 与 CA
+ Iptables 1.8.7，已结合53个官方程式码patch 与 commit 修补完成(这边我个人能力有?
+ Arptables 0.0.5，开发者的程式码不包含此套件，arptables的主要用途之一是防范ARP?
此版本为2019-12-02发布的版本，已经是最新版了！
在Arptables 0.0.5发布後，只有新增一条commit log：
於2024-03-09修复了：Fix a couple of spelling errors：One mistake in a man-page,
白话文：就只是拼字错误而已，例如：
原为：-.SS MISCELLANOUS COMMANDS
改为：+.SS MISCELLANEOUS COMMANDS
原为：- printf("Warning: wierd character in interface"
改为：+ printf("Warning: weird character in interface"
结论：这不重要！所以我就不套用patch了！直接用Arptables 0.0.5的原始码套件编译完成
+ 将 HWNAT 绑定阈值设为 1。 （HWNAT 将更快地整合到您的连接中，并显着降低 CPU 负?
+ 改善 HWNAT 的IP取值逻辑，提升稳定性。
总结：以上两个韧体都是我个人修改的心血，都是花我自己的时间完成的作品，本来就是给
如果您是公司的人员，愿意帮我争取产品，包含：贵公司的开发板或新产品或试用产品，我
如果您和我一样是个普通人，愿意捐赠您的路由器给我，我也在此献上最高的感谢！因为您
如果您捐赠了一组邀请码给我，那意谓着：您可能会造福更多的人，因为我将会分享我的作
在此再次缅怀Dave Täht (1965–2025)！
Dave Täht 将永远活在大家的路由器里！
分享有趣的小故事：
Google繁体中文机器翻译：
Cake 常见问题解答
Cake 是 bufferbloat 专案自 2013 年以来一直在开发的综合伫列管理系统。它汇集了三年
Cake 这个名字的由来是什麽？
最初，它源自於电影《2010》，片中一位美国人试图向一位俄罗斯人解释「Easy as pie」?
後来，它又与游戏「Portal」（传送门）联系起来——在游戏结束时，人工智慧承诺：「每
它也（沿袭了红蓝对抗的传统）暗指「Pie」（派），後者是一种与蛋糕演算法竞争的AQM演
它被重新缩写为「Common Applications Kept Enhanced」（常用应用增强演算法）——而?
尽管我们很喜欢这个名字，但现在把它改成别的也为时不晚——在谷歌上搜寻「cake shape
英文原文：
Cake FAQ
Cake is the comprehensive queue management system the bufferbloat project has be
What was the origin of the name?
Initially it came from the movie 2010 where an American was trying to explain th
Later on it became a reference to the game “portal” - where, at the conclusion
It is also (in a grand tradition of RED vs Blue) a backhanded reference to “Pie
The backronym invented for it became “Common Applications Kept Enhanced” - whi
Despite our affection for the name there is still time to change it to something
来源：
https://www.bufferbloat.net/projects/codel/wiki/CakeFAQ/
参考资料：
https://www.bufferbloat.net/projects/codel/wiki/CakeRecipes/
本文章同步刊登於Mobile01论坛：
https://www.mobile01.com/topicdetail.php?f=110&t=7220226
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 36.225.152.62 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Broad_Band/M.1769426571.A.491.html
※ 编辑: Taiwan641 (36.225.152.62 台湾), 01/26/2026 19:28:58
※ 编辑: Taiwan641 (36.225.152.62 台湾), 01/26/2026 19:30:00
1F：推 ks031239: ? 01/26 19:39
※ 编辑: Taiwan641 (36.225.152.62 台湾), 01/26/2026 20:03:04
※ 编辑: Taiwan641 (36.225.152.62 台湾), 01/26/2026 20:23:59
2F：→ a330332003: ？01/26 20:15
※ 编辑: Taiwan641 (36.225.152.62 台湾), 01/26/2026 20:29:37
3F：嘘 wang7752: 不要发废文 01/26 20:28
※ 编辑: Taiwan641 (36.225.152.62 台湾), 01/26/2026 20:31:52
※ 编辑: Taiwan641 (36.225.152.62 台湾), 01/26/2026 20:33:10
4F：嘘 mars3712: md废文 01/26 21:28
5F：嘘 ctes940008: 工三小 01/26 22:03
6F：嘘 s25g5d4: 废话太多 01/26 22:11
※ 编辑: Taiwan641 (36.225.152.62 台湾), 01/26/2026 22:25:47
※ 编辑: Taiwan641 (36.225.152.62 台湾), 01/26/2026 22:41:13
※ 编辑: Taiwan641 (36.225.152.62 台湾), 01/26/2026 22:55:03
7F：嘘 lk86jeff: 你这个排版有一堆重复段落跟接不起来的句子 这不是伤眼 01/27 02:27
8F：→ lk86jeff: 是无法阅读.. 01/27 02:27
9F：嘘 vincewe: 废文 01/27 07:19
10F：嘘 asdfghjklasd: 有意义的是让 meraki 云管理的可以自主管理 01/27 08:44
11F：推 stark5566: 帮你推一个以免被人发现我看不懂 01/27 11:54
12F：嘘 ginlom: 还真的伤了我的双眼，有人可以翻译翻译是在说啥吗？ 01/27 11:56
13F：嘘 IOU9527: 看不懂 01/27 14:46
14F：推 gmkuo: 还好啦，要会讲重点 01/27 14:50
15F：推 jhjhs33504: 手边没发哥wifi机 kernel版本像中古机用的 连线数多少 01/27 15:48
16F：推 HiJimmy: 看起来就是类似在openwrt上，要帮忙写出适合的dts?? 01/27 19:37
17F：→ HiJimmy: 只不过作者用的是梅林？？ 01/27 19:38
18F：→ Taiwan641: 回覆jhjhs33504[15楼]：C2原厂用的kernel是MTK SDK的， 01/27 22:50
19F：→ Taiwan641: 所以2.6.36应该是直接用SDK的，根据维基百科，这个内核 01/27 22:50
20F：→ Taiwan641: 在2011年2月就被宣告EOL，Archer C2这款的Padavan韧体 01/27 22:50
21F：→ Taiwan641: ，原本是基於ASUS的rt-n56u的原始码改写的，2012年5月 01/27 22:51
22F：→ Taiwan641: 初版发布，2016年9月宣告EOL，CAKE是从4.19内核开始才 01/27 22:51
23F：→ Taiwan641: 被纳入上游核心的一部分，4.19内核是在2018年10月才发 01/27 22:51
24F：→ Taiwan641: 布的，CAKE是一种Linux qdisk、是一种最先进的主动伫列 01/27 22:51
25F：→ Taiwan641: 管理技术(AQM)，它结合了 scheduler 和流量整形器，可 01/27 22:51
26F：→ Taiwan641: 以有效地解决缓冲区膨胀。 01/27 22:51
27F：→ Taiwan641: 附图最清楚： 01/27 22:51
28F：→ Taiwan641: (前两张GIF，後两张JPG) 01/27 22:51
29F：→ Taiwan641: (第一张英文版，第二张中文版) 01/27 22:51
34F：推 jhjhs33504: 家用NAT用不太到或差异不明显 CAKE优势可能要RDMA情境 01/27 23:19
35F：→ Taiwan641: 连线数最高可以设到65536，问题是这台的HWNAT硬体转发 01/27 23:20
36F：→ Taiwan641: 上限是16384，只要成功走硬体转发的连线，CPU的使用率 01/27 23:20
37F：→ Taiwan641: 会降到个位数甚至是几乎是0%，这台特别的是用了MT7620A 01/27 23:20
38F：→ Taiwan641: [单核心CPU+2.4G]+MT7610E[5G]+RTL8367RB[Switch] 01/27 23:20
39F：→ Taiwan641: 这颗CPU支援使用REGMII连结到Switch，WAN to LAN 有线 01/27 23:21
40F：→ Taiwan641: 网路1Gbps的高速转发，成功加速的连线几乎不花CPU的效 01/27 23:21
41F：→ Taiwan641: 能，这台连线数最高应该只能到32768，因为这台的SPI Fl 01/27 23:21
42F：→ Taiwan641: ash 8MB+RAM 64MB[这也是瓶颈之一，RAM不够大当然撑不 01/27 23:21
43F：→ Taiwan641: 了更多的连线数] 01/27 23:21
44F：→ Taiwan641: 这台当年售价不到一千元，能上1G靠的就是CPU的REGMII和 01/27 23:21
45F：→ Taiwan641: 那颗Switch，如果没有那颗Switch就只能乖乖地用CPU内建 01/27 23:21
46F：→ Taiwan641: 的100Mbps Switch；如果没有REGMII也没办法做到让CPU跟 01/27 23:21
47F：→ Taiwan641: 外接的Switch连线， 01/27 23:21
48F：→ Taiwan641: 但K2P就不一样了，CPU是MT7621A内建1Gbps Switch，而且 01/27 23:21
49F：→ Taiwan641: 也支援HWNAT 连线数一样是16384，是双核心CPU，可以想 01/27 23:21
50F：→ jhjhs33504: 不然不知道有没那种不占线的Port forwarding容易应用? 01/27 23:22
51F：→ Taiwan641: 像成是升级版的MT7620A，这台SPI Flash 16MB+RAM 128MB 01/27 23:22
52F：→ Taiwan641: 一般使用情境，连线数不太可能爆表，所以移植CAKE的本 01/27 23:22
53F：→ Taiwan641: 质是改善网路连线品质，4.19内核开始是不用移植，内核 01/27 23:22
54F：→ Taiwan641: 有开就有，前提是编译韧体的时候有编为模组或直接写进 01/27 23:22
55F：→ Taiwan641: 去内核里面，移植到4.4.198还相对简单，但3.4.113的内 01/27 23:22
56F：→ Taiwan641: 核跟原厂的比虽然是比较新的，但事实上也算是个老古董 01/27 23:22
57F：→ Taiwan641: ，能用上fq_codel就很好了，但CAKE的指令很简单，只管 01/27 23:22
58F：→ Taiwan641: 离开介面的流量，这也是当初这套演算法的作者的杰作， 01/27 23:22
59F：→ Taiwan641: 那麽老的内核，能用得上这个演算法已经是奇蹟了！ 01/27 23:22
60F：→ Taiwan641: 回覆HiJimmy[16楼]：从原始码来看，这比较贴近您最後说 01/27 23:39
61F：→ Taiwan641: 的梅林，其实系出同源，都是ASUSWRT的改写版本。 01/27 23:39
62F：→ Taiwan641: 梅林的外观几乎就跟ASUS路由器长得一模一样，Padavan则 01/27 23:39
63F：→ Taiwan641: 是属於轻量化的分支，通常是MTK CPU的路由器才有支援， 01/27 23:40
64F：→ Taiwan641: 以现在来看都是年代久远的产品，但原厂不太可能在QoS加 01/27 23:40
65F：→ Taiwan641: 入CAKE这个演算法，每个人的网速上限不同，要有稳定不 01/27 23:40
66F：→ Taiwan641: 爆ping的网路环境，还是要损失5-10%的上限网速，限速越 01/27 23:40
67F：→ Taiwan641: 严格，效果越好，因为我走的是AP-Client+AP无线中继模 01/27 23:40
68F：→ Taiwan641: 式(WISP)，Starlink也是靠CAKE这个演算法来改善延迟问 01/27 23:40
69F：→ Taiwan641: 题的，本质上Starlink也是走WISP模式，这和WDS桥接还有 01/27 23:40
70F：→ Taiwan641: Mesh网状网路是完全不一样的东西， 01/27 23:40
71F：→ Taiwan641: 能用上这个演算法，还要会手动设定，作者有写出一个cak 01/27 23:48
72F：→ Taiwan641: e-autorate，但那个不适合家用网路，它会频繁测速来达 01/27 23:48
73F：→ Taiwan641: 到自动侦测连线速率，这比较适合不稳定网速的环境，像 01/27 23:48
74F：→ Taiwan641: 是4G和5G这样的情境，才要用到动态调节网速，缓解网路 01/27 23:48
75F：→ Taiwan641: 壅塞。 01/27 23:48
76F：→ Taiwan641: 回覆jhjhs33504：我个人觉得是差别蛮大的，上限网速降 01/27 23:52
77F：→ Taiwan641: 低是一定的，但延迟问题真的改善很多，以我的配置可以 01/27 23:52
78F：→ Taiwan641: 达到下载、上传、双向并发三者都能测出A级的成绩，能达 01/27 23:53
79F：→ Taiwan641: 到3A，这已经很强了！ 01/27 23:53
80F：→ Taiwan641: 另外，您说的不占线，其实HWNAT应该就做到了，建立连线 01/28 00:22
81F：→ Taiwan641: 是一定会占用RAM，维持连线也会持续占用，但只要进入硬 01/28 00:22
82F：→ Taiwan641: 体转发，就不太吃CPU的额外效能，像我用的是WISP无线中 01/28 00:22
83F：→ Taiwan641: 继，原本是全部都靠CPU去跑所有的流程和转发，但我的韧 01/28 00:22
84F：→ Taiwan641: 体还有导入SFE，也就是让封包走捷径，来达到快速转发， 01/28 00:22
85F：→ Taiwan641: 等於是用CAKE先从源头限速和流量整形(这会消耗CPU效能) 01/28 00:23
86F：→ Taiwan641: ，接着HWNAT会接管可以被硬体加速的连线，成功接管就会 01/28 00:23
87F：→ Taiwan641: 直接进入NAPT，也就是成功binding的连线，没被接管的会 01/28 00:23
88F：→ Taiwan641: 被踢回去给CPU，这时候SFE就派上用场了，封包走捷径也 01/28 00:23
89F：→ Taiwan641: 能达到快速转发，一般原厂韧体不太可能这样混血使用的 01/28 00:23
90F：→ Taiwan641: ，虽然我用起来是很稳定，但原厂不太可能实现这件事， 01/28 00:23
91F：→ Taiwan641: 当然不是做不到，但产品定位和消费者导向，一般能看到 01/28 00:23
92F：→ Taiwan641: 的QoS，绝大多数都是相对比较旧的算法，当然每个人的网 01/28 00:23
93F：→ Taiwan641: 路环境也不一样，原厂不可能帮每位客人都客制化一个量 01/28 00:23
94F：→ Taiwan641: 身订作的参数，用上新版的openwrt应该是有内建CAKE的， 01/28 00:24
95F：→ Taiwan641: 原厂写好的韧体，看起来越满意的，绝对是反应在价格上 01/28 00:24
96F：→ Taiwan641: ，网路用起来卡，有时候真的不是原厂的硬体不好，进来 01/28 00:24
97F：→ Taiwan641: 的封包和出去的封包塞车的时候，就是爆ping的时候，所 01/28 00:24
98F：→ Taiwan641: 以流量整形当然也很重要，就像上面我贴的GIF，想了解更 01/28 00:24
99F：→ Taiwan641: 多资讯，可以去看LibreQoS的官网： 01/28 00:24
101F：→ Taiwan641: 想要了解您的网路环境有没有存在缓冲区膨胀有两个网站 01/28 00:24
102F：→ Taiwan641: ，DSLReports倒站了，所以目前我只找到下面两个测试用 01/28 00:24
103F：→ Taiwan641: 的网站： 01/28 00:25
105F：→ Taiwan641: 另一个是： 01/28 00:25
107F：→ Taiwan641: 最好的状况当然是看中华电信或是您的ISP直接从源头导入 01/28 00:25
108F：→ Taiwan641: 这套系统，但好像不太可能。 01/28 00:25
109F：嘘 castiel652: 你 HWNAT 开着，Cake 不会有作用 01/28 20:47
110F：→ Taiwan641: 回楼上：我实测是CAKE生效，限速生效，HWNAT生效，你说 01/28 23:43
111F：→ Taiwan641: 的失效是你韧体的问题，我的韧体是正常生效，完美配合 01/28 23:43
112F：→ Taiwan641: 的，你用MTK原厂那个hw_nat -g就可以查到成功Bind的连 01/28 23:43
113F：→ Taiwan641: 线，但原厂早期版本的写法没这麽完善，取值没有挤一点 01/28 23:43
114F：→ Taiwan641: 会被硬塞字元，导致记忆体错位，显示出来的IP和port都 01/28 23:43
115F：→ Taiwan641: 会被塞0，後来的MTK原厂程式码已经改善了，所以这个问 01/28 23:43
116F：→ Taiwan641: 题不修也可以，但原厂取值的方式相对简单暴力，多数情 01/28 23:43
117F：→ Taiwan641: 况是不会促发bug的，因为多数人根本不会去看这个debug 01/28 23:43
118F：→ Taiwan641: 工具 01/28 23:43
119F：推 Windcws9Z: 哥们..上面有人讲了，HWNAT硬体加速跟QoS是相冲的 01/29 02:20
120F：→ Windcws9Z: 目前QoS只能靠CPU去辨识处理分类，没办法HW Offload 01/29 02:36
121F：→ Windcws9Z: 然後QoS功能也跟BW Limiter限速相冲 01/29 02:46
122F：→ Windcws9Z: 两者只有一个会动，即便韧体告诉你功能成功启用 01/29 02:48
123F：→ Windcws9Z: 还有..你那个测速结果不觉得很奇怪吗 01/29 02:54
124F：→ Windcws9Z: 我就先不说你用Wi-Fi去测，啊你两台AP中间居然用无线连 01/29 03:00
125F：→ Windcws9Z: 用无线WISP也就算了，2.4GHz测速出来比5GHz还好 一一？ 01/29 03:04
126F：→ Windcws9Z: 延迟 抖动还更低，这是什麽神奇巫术 01/29 03:07
127F：→ Windcws9Z: 限速85M也根本不需要用到HWNAT，比这两台更老更弱的 01/29 03:11
128F：→ Windcws9Z: RT-N16不开HWNAT，CPU都能扛到100-120Mbps了 01/29 03:13
129F：→ Windcws9Z: Archer C2官宣是说开HWNAT能摸到900Mbps左右，你再回去 01/29 03:18
130F：→ Windcws9Z: 测测吧 01/29 03:19
131F：→ Windcws9Z: 要先测机子的极限，也就是啥功能都别开 只开HWNAT 01/29 03:23
132F：→ Windcws9Z: 之後你才能知道各功能对效能是冲击多少 01/29 03:25
133F：→ Windcws9Z: 也别用无线去测速，因为无线加解密也会影响效能 01/29 03:26
134F：推 Windcws9Z: 不过还是推你有心 01/29 03:43
135F：→ castiel652: tc -s qdisc 贴出来就知道了 01/29 09:50
136F：→ asdfghjklasd: 那来时间搞..买买FG 就搞定了 01/29 12:10
137F：推 jhjhs33504: AR4031B时代就有QoS了 都到了2026还有戏喔? 01/29 18:24
138F：→ jhjhs33504: WISP条件相同还可参考不过网速减半网路品质考验较严苛 01/29 18:28
139F：→ Taiwan641: Padavan的传统QoS跟CAKE完全不同，而且我根本没开传统Q 01/29 20:05
140F：→ Taiwan641: oS，AI会告诉你这是冲突的，但WISP环境下，我多次实测 01/29 20:05
141F：→ Taiwan641: 的状况，确实是我这样配置是最稳定的，老旧的ra_nat.c 01/29 20:05
142F：→ Taiwan641: 里面的写法是把介面全都注册进HWNAT的硬体加速引擎，新 01/29 20:05
143F：→ Taiwan641: 版的则是针对不同无线晶片去找写死的介面名称。 01/29 20:05
144F：→ Taiwan641: 题外话是K2P Padavan 4.4.198 01/29 20:05
145F：→ Taiwan641: 这新版原始码是直接写死 01/29 20:05
146F：→ Taiwan641: 2.4G 和 5G WISP介面名称 01/29 20:06
147F：→ Taiwan641: apcli0 和 apclii0，但K2P介面对应的名称是： 01/29 20:06
148F：→ Taiwan641: apclix0 和 apcli0 01/29 20:06
149F：→ Taiwan641: 原版是对应不上的！ 01/29 20:06
150F：→ Taiwan641: 找不到介面就是注册失败，全靠CPU转发，不可能被HWNAT 01/29 20:06
151F：→ Taiwan641: 成功接管，不确定是原开发者还是MTK原厂程式码里面藏了 01/29 20:06
152F：→ Taiwan641: 一段直接跳过指定名称的注册流程 01/29 20:06
153F：→ Taiwan641: 只要介面名称有「apcli」五个字 01/29 20:06
154F：→ Taiwan641: 直接跳过注册介面流程，也就是说新版原本是绝对没机会 01/29 20:06
155F：→ Taiwan641: 让硬体接管连线，但经过我的修改，不论旧版还是新版都 01/29 20:06
156F：→ Taiwan641: 能成功注册介面且正常与硬体加速引擎正常沟通，只要能 01/29 20:07
157F：→ Taiwan641: 被硬体引擎接管的流量，进入转发就有可能达到上面有人 01/29 20:07
158F：→ Taiwan641: 提到的冲突，但这并不会导致当机或不稳，而是被硬体接 01/29 20:07
159F：→ Taiwan641: 管的连线就不归CPU管，队列管理就只有针对CPU转发的连 01/29 20:07
160F：→ Taiwan641: 线是有效的，但CAKE针对离开介面的流量控制，你只管上 01/29 20:07
161F：→ Taiwan641: 传流量当然就是半调子，不论是你的2.4G、5G、6G还是区 01/29 20:07
162F：→ Taiwan641: 域网路，离开介面对你来说就是下载，但上传的介面只有 01/29 20:07
163F：→ Taiwan641: 你的WAN介面，以我的状况就是WISP 2.4G介面。 01/29 20:07
164F：→ Taiwan641: 上面还有人提到2.4G怎麽会比5G快的疑问：因为我是上游A 01/29 20:07
165F：→ Taiwan641: P 2.4G，我WISP 2.4G接收，透过5G转发，另一台则是WISP 01/29 20:07
166F：→ Taiwan641: 5G接收，透过5G转发，通常同频段、同晶片转发会降低效 01/29 20:08
167F：→ Taiwan641: 能，跨频段能改善同晶片转发导致的塞车问题，同时处理 01/29 20:08
168F：→ Taiwan641: 接收和转发，尤其是老旧的晶片，更不可能达到相对稳定 01/29 20:08
169F：→ Taiwan641: 的网路环境，发生延迟爆表的状况是常有的事。 01/29 20:08
170F：→ Taiwan641: 我的状况刚好是无线中继，本来大部分就是透过CPU转发， 01/29 20:08
171F：→ Taiwan641: 同时开HWNAT+SFE反而是降低延迟和提高稳定性的手段，甚 01/29 20:08
172F：→ Taiwan641: 至在老旧硬体上，CPU使用率飙高，你再好的演算法都救不 01/29 20:08
173F：→ Taiwan641: 了，WISP转发就是双倍的流量，接收+转发就是原来的两倍 01/29 20:08
174F：→ Taiwan641: ，让硬体接管，降低CPU的负荷，反而让硬体的状态更稳定 01/29 20:08
175F：→ Taiwan641: 。 01/29 20:08
176F：→ Taiwan641: 这我都交叉测试比对过了，如果你是有线网路转无线的状 01/29 20:09
177F：→ Taiwan641: 况，只要成功进入硬体转发的连线有可能就会导致CAKE针 01/29 20:09
178F：→ Taiwan641: 对离开介面的速限失效，CAKE还改善了Starlink的延迟， 01/29 20:09
179F：→ Taiwan641: 如果你有兴趣研究，可以问问搜寻引擎CAKE WISP，基本上 01/29 20:09
180F：→ Taiwan641: 你应该能找到CAKE演算法作者的讨论串 01/29 20:09
181F：→ Taiwan641: CAKE成功套用，请看下方： 01/29 20:09
186F：推 Windcws9Z: 老哥..你还是不懂我的意思 01/30 13:45
187F：→ Windcws9Z: 我想看的是你Throughput有多少，而不是你用无线在那 01/30 13:47
188F：→ Windcws9Z: 转来转去的好吗 01/30 13:48
189F：→ Windcws9Z: 你都说老旧硬体了，怎麽还用无线桥接来增加负担 01/30 13:50
190F：→ Windcws9Z: 我是真心不懂 01/30 13:50
191F：→ Windcws9Z: 1. 我想看的是你开HWNAT能不能摸到900Mbps 01/30 13:52
192F：→ Windcws9Z: 2. 以及你CAKE是否有正常降低服务延迟 01/30 13:54
193F：→ Windcws9Z: 3. 再来是两者功能是否会相抵触？ 01/30 13:55
194F：→ Windcws9Z: 这很容易验证，要马Throughput直接剩1/3 要马服务延迟 01/30 13:57
195F：→ Windcws9Z: 无显着降低 01/30 13:57
196F：→ castiel652: 怎麽只贴 wireless interface 01/30 13:59
197F：→ Windcws9Z: CPU够强也不需要HWNAT来加速，这功能限制也是很多 01/30 14:03
198F：→ Windcws9Z: 人家HWNAT是要加速几百Mbps的，结果你弄个限速85Mbps 01/30 14:06
199F：→ Windcws9Z: 我也是黑人问号，重点限速85Mbps还摸不到80Mbps 01/30 14:07
200F：→ Taiwan641: 如果是有线网路连线，原厂能做到的，这一样能做到，但 01/30 18:41
201F：→ Taiwan641: 我的使用情境就只是拿来当WISP做无线中继，以目前这样 01/30 18:41
202F：→ Taiwan641: 就是相对最稳定，纯无线网路的环境下已经差不多极限了 01/30 18:41
203F：→ Taiwan641: ，我是自己用的满意分享出来，怎麽变成要我证明我说的 01/30 18:41
204F：→ Taiwan641: 是真的？ 01/30 18:42
205F：→ Taiwan641: 网速上限就100/40，在那边问的是真的不知道PPPoE的上限 01/30 18:42
206F：→ Taiwan641: 是94左右吗？开发者建议就是以最高速度保留5~10%，也就 01/30 18:42
207F：→ Taiwan641: 是94x0.9~0.95，用脑袋算不出来，不会用计算机？ 01/30 18:42
208F：→ Taiwan641: 分享出来的本意，就只是用得到的人自己可以用，没这两 01/30 18:42
209F：→ Taiwan641: 个型号的路由器或用不到的人，你去刷openwrt4.19内核之 01/30 18:42
210F：→ Taiwan641: 後的版本，只要编译有写好参数，你的韧体就内建CAKE演 01/30 18:42
211F：→ Taiwan641: 算法，就算有也不是每个人都会用，你指令没输或者是没 01/30 18:42
212F：→ Taiwan641: 给他自动用脚本挂载模组，一样是没用，Padavan3.4.113 01/30 18:42
213F：→ Taiwan641: 就是预设使用pfifo，虽然4.4.198预设已经用上了fq_code 01/30 18:42
214F：→ Taiwan641: l，不过如果没依照你的网速配置好，一样是没用，不管你 01/30 18:43
215F：→ Taiwan641: 用上再好的演算法都是白搭！ 01/30 18:43
216F：→ Taiwan641: 哦！对了！楼上那位c开头的乡民，是不是记忆力不太好？ 01/30 18:43
217F：→ Taiwan641: 你前面不是问qdisc吗？我贴了你问的，你又反问我贴无线 01/30 18:43
218F：→ Taiwan641: 介面干嘛？ 01/30 18:43
219F：→ Taiwan641: 你是没看到？还是你根本看不懂指令跟参数？ 01/30 18:43
220F：推 jhjhs33504: 有点类似Pipeline的bubble或hazard那个意味 现在半夜 01/30 20:53
221F：→ jhjhs33504: 浮动IP更换时中断变得不敏感很快维持连线可能有帮助吧 01/30 20:55
222F：嘘 castiel652: 因为 Cake 比较适合挂在 wired traffic 啊 01/31 01:37
223F：→ castiel652: 无线有 mac80211 的 airtime fairness 跟 AQL 01/31 01:37
224F：推 Windcws9Z: 很简单的逻辑的，就你觉得HWNAT+CAKE+限速能正常运作啊 02/01 04:59
225F：→ Windcws9Z: 那当然是你要证明你说的是真的啊 02/01 14:02
226F：嘘 Windcws9Z: 还有啊..谁跟你说网速100M/40M，PPPoE的上限是94左右？ 02/01 14:05
227F：→ Windcws9Z: 会剩94M是因为你小乌龟LAN孔就100M，1G LAN孔的小乌龟 02/01 14:09
228F：→ Windcws9Z: 没这问题，例如FTTH供装的 02/01 14:10
229F：→ Windcws9Z: 好啦即便按照你的逻辑，94x0.9进位算85好了 02/01 14:15
230F：→ Windcws9Z: 你限速85M，结果测速打出来最好才76M 最差到59M 02/01 14:53
231F：→ Windcws9Z: What happened..?你都不会觉得有那麽亿点点奇怪吗？ 02/01 14:56