二手区闲逛收来的K3，使用了半年感觉还是非常值的，前一篇主要是记录了为K3编译固件的过程以及OpenWrt 19.07更新的情况，本文记录了当时收集的信息，然后就是分享下使用体验；另外还补充了K3的160MHz测试

某一天在学校的二手区闲逛，看到了有K3，确认了K3即将得到OpenWrt官方的支持，并且网络上也有勉强可用的固件，加之一直很期待一台高性能的，无线强劲的OpenWrt路由器（价格要可以接受才行），最后抱着改善家里的无线网络覆盖的想法决定尝试一下

所幸“漏油”问题已经通过更换铜片+硅脂的解决了，解决下细枝末节的问题就好了；于是就有了个人Github的三个K3相关的仓库，之后也就是无心插柳地有人fork和编译了固件，为部分人解决了K3屏幕相关的问题，接着就是有人反馈了问题…莫名其妙就“维护”了一段时间，本来想着有朝一日能够为OpenWrt贡献下代码，一番了解之后还是觉得对这个了解的不多，于是再次公开下已知的情报吧

斐讯K3 A1版

• CPU: BCM4709C Cortex A9 1.4GHz 40nm制程
• RAM: 512MB DDR3-1600
• flash: 128MB NAND Flash
• 无线芯片: BMC4366 * 2, 4×4 MU-MIMO
• 功放: SKY2623L + PA5542
• 接口: 千兆 wan 口 + 千兆 lan 口 * 3 + USB 3.0

硬件上跟华硕的AC88U差不多，信号在acwifi的测试中相当强悍，做AP的效果不错，遗憾是K3没有160MHz的频宽，无法适配市场上现有的一批廉价的2x2的1.7G网卡；硬件上明显的缺点是芯片的制程太过落后，发热感人

存在的问题

最开始刷上的是Snapshot固件和论坛上的一些固件

1. K3的屏幕信息显示不支持而且只能常亮，据说添加了补丁，应该还是要自行编译安装k3screenctrl的

2. 开源的驱动的信号，可以说几乎没有，即使是在路由器旁边都只有10Mbps的速度，但是在调节频段之后勉强可用，就是协商速度不高，LuCI的无线界面显示的频宽仅有20MHz，考虑到稳定性一般还是不适合日常使用

社区有人已经针对snapshot做了修改和编译，解决了以上两个问题，作为路由器基本上已经可以用了，但是有以下遗憾：

1. 固件基于uclibc的c库编译，官方源软件部分不能使用，我尝试的opkg安装的大部分软件不能用

2. 自带的软件又太多，K3的发热本来就大，太多软件带来的负担更大

3. 作者的工作相当的出色，但是后续没有更新以及没有开源公布细节，想自己定制变得很困难（只想要个原生、纯净的版本）

最后还是要自己动手，但是完全可以参考上面的固件来编译，然后我就打开了Github，找K3的屏幕和无线方面可用的资源

主要解决的还是屏幕和无线信号两个问题，因为参考的东西比较杂（东拼西凑），但是还是想记录下这一段历史：

最早要追溯到2017年updateing的【测试】K3 的 LEDE（更新部分屏幕支持），最主要的是逆向做出了k3screenctrl使得屏幕显示有了开源支持

1. 所有代码的基础：

   • [2019-01-21]K3补丁已经提交合并到OpenWrt官方源码，附加自编译说明，K3补丁（基于updateing的创始代码）。补丁继承了LCD屏幕接口，增加了对USB3.0的支持

   • 2018.5 Hill-98/luci-app-k3screenctrl

   • [2019.03.26更新]K3 openwrt18.06.02 完美适配屏幕天气页，应该是天气显示支持的开端，我的仓库中的sh文件基于此修改，结合了在Github上找到的可能的开源实现zxlhhyccc/Hill-98-k3screenctrl

     修复因天气api超时导致程序进程卡死屏幕黑屏的问题， 不保证API的稳定可用

     因为自动识别天气城市的api用的阿里的一个api,最近抽风，脚本里没有超时设置，会导致进程卡死，屏幕会有错误或黑屏的问题，可以通过手动指定城市解决，有能力的自己改下脚本设置一下超时，后面有时间修复

     屏幕显示天气要以前刷过新版官方或官改固件，屏幕固件是新版的才行

2. 指出问题：

   • 2019-10-21斐讯 K3 屏幕控制程序升级版 【6个页面】MAC显示修复 长按脚本，github内附了最详细的技术readme

   • （2020-1-8）netflixcn的裴讯 K3 OpenWrt LEDE刷机固件，k3的openwrt固件中用户最多的一个？也是直接指出了问题

     已知的一个致命问题: 屏幕会隔三差五的睡死，睡死时候，网路会出异常，变得非常慢，检查系统日志，会发现k3screenctrl大量的错误信息。硬重启后恢复正常。软重启无法激活屏幕。

     所有带k3screenctrl的固件都有睡死问题，据说是天气API导致的。但是也有人说一切正常，所以真实原因，自己刷了才知道。

屏幕包括四个部分：屏幕控制程序，luci-app-k3screenctrl，屏幕界面信息更新脚本以及综合以上的编译设置文件

在 zxlhhyccc/Hill-98-k3screenctrl 已经给K3屏幕开启了7屏的基础上，使用 K3 openwrt18.06.02 固件中的/lib/k3screenctrl/下的sh文件做了替换

搭配的 luci-app 是根据固件的LuCI文件修改的 lwz322/luci-app-k3screenctrl

最后使用修改自 lean/lede 中的编译文件 lwz322/k3screenctrl_build 编译

基本情况可以参考下图：

• 第一屏：升级界面
• 第二屏：型号(硬件版本型号H/W全部显示为A1)，MAC，软件版本
• 第三屏：USB与网口接入情况
• 第四屏：网速以及2.4G和5G WiFi的接入客户端数量
• 第五屏：天气，时间
• 第六屏：WiFi信息：SSID和密码（可选隐藏）
• 第七屏：已接入终端和网速（只统计IPv4转发）

上面主要是接近官方固件的屏幕信息显示，针对新版本通过修改脚本，添加了在前两屏更多信息的显示的选项，默认开启，如下

• U:0.14 R:8%：CPU负载 内存占用百分比（和第二屏的软件版本显示的一样）
• up 10:47：运行时间
• H/W: 48*C：CPU温度
• MAC地址: OpenWrt 19.07.0：系统版本号

直接使用了社区的无线固件，貌似和lean的仓库中的k3-brcmfmac4366c-firmware一样，

其他的固件可以参考/Hill-98/phicommk3-firmware做替换，固件在OpenWrt的/lib/firmware/brcm/目录下

当前想要作为无线路由使用的话是肯定要换无线固件的，我的7260AC网卡在近距离（同一个房间内）使用iperf3测试下载和上传速度，5G的实际传输速度300Mbp左右，5M，相隔两堵墙的情况下200Mbps左右，再远一点100Mbps，三堵墙就GG了，鉴于7260AC性能一般，而一般吹无线性能都列出的是遇到的最大速率，K3的这个值可以到500Mbps（2x2的情况下），在我使用的OpenWrt的路由器中是最好的（一般隔一墙就GG）

对比之前家里用的荣耀路由Pro（当时比较迷信华为的产品），在同样的位置K3可以满速，而前者已经是没有信号了，据说K3的无线功率相当的高（超出国标的那种），发热也很大，连接着两台设备的情况下，温度可以到70以上（还是改了散热的情况下）

尽管标称AC3150，参考简说各种wifi无线协议的传输速率，K3是 4X4 MIMO + 80MHz + 1024-QAM = 2100Mbps ，单设备连接下达到这个速度需要PCE-AC88这个级别的网卡，结合现在的无线网卡市场（2X2 160Mhz网卡廉价且产品多），信号和速率方面其实已经难以和现在中端以上的路由器（200+）拉开差距了，相比其他的OpenWrt路由，K3只有信号强度有较大的实用价值，剩下的没有绝对的优势（如果不考虑外观的话）

注：多设备连接的MU-MIMO的情形，现在的OpenWrt还不支持，从这方面来说OpenWrt路由器不适合做高性能的AP

下面就是问题：

• 据说无线的功率一直会固定在一个较高的值，在夏天温度比较高，而OpenWrt无法读取无线的温度
• 另外一个已经查不到在哪里看到的了，但是偶尔出现过：在一段高速传输之后会出现无线不稳定的情况，只有重启无线才能恢复，具体表现就是在做无线测速的时候，突发的无线丢包，跳ping；

不怎么影响使用但是存在的问题

• 无线偶尔会出现Not Associate的情况，需要重启（用过的OpenWrt都有这个问题）
• 查看无线连接部分都只有20MHz的频宽（实测发现是80MHz）

很多人说屏幕非常鸡肋，这么说没有问题，具体表现在：

• 路由器是属于那种被遗忘的设备，被置于角落，只要不出问题，没有人会想起来，
• 屏幕能够显示信息的极为有限，屏幕固件本身已经写死了部分模版，能够自行定制的只有几行的几个字节
• 有人存在屏幕睡死甚至是屏幕组件导致的资源占用过高之类的问题

再说下脚本部分提供的功能的缺陷：

• 屏幕流量统计基于iptable的IPv4 Forward，然而再开启硬件转发的时候是统计不到的
• 屏幕路由网速监测基于默认的WAN的流量
• 天气API受限

最后对我来说，在学校生活还是有点用的：

• 流量统计与速度监控在宿舍共享宽带下有用
• 部分显示功能可以用来显示：电费用量以及余额，流量使用情况之类的信息

当然还是需要写脚本来获得

CPU运算性能

就以专门为ARM设计的ChaCha20算法以及常用的AES-256-CBC测试，[email protected]的单线程openssl加解密速度测试结果如下

root@K3:~# openssl speed -elapsed -evp chacha20
#k3
 type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
 chacha20         41251.72k    88523.18k    93098.98k    98190.37k    92384.53k    93584.75k          
 aes-256-cbc      24429.85k    27700.11k    30198.27k    30665.23k    29156.44k    29420.67k    

对比近几年主流的MT7621@880MHz以及更早的MT7620@580MHz单线程测试结果

#K2P
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
chacha20         15635.27k    25852.26k    29409.89k    30429.13k    30748.58k    30835.67k
aes-256-cbc       7234.99k     8504.77k     8930.74k     9059.51k     9071.08k     9090.13k
#Y1
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
chacha20         10284.77k    17029.01k    19675.48k    18671.27k    20179.63k    20025.49k
aes-256-cbc       4877.62k     5635.73k     5527.98k     6159.36k     5644.29k     6100.31k

AES的测试结果大幅领先应该是得益于架构上的优势（BCM4709是ARMv7架构，不支持AES硬件加速，但是相比MIPS还是有优势的），就是日常使用温度比较高（40nm制程落后）

这里顺带提一下ARMv8架构的斐讯N1，Amlogic S905，ARM Cortex-A53 x [email protected]

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
chacha20         62175.16k   129886.44k   258250.75k   283707.39k   298423.64k   299641.51k
aes-256-cbc      90619.15k   257628.35k   466210.05k   598629.38k   655471.96k   659952.98k

N1的CPU因为有AES硬件加速，对比上面就是吊打了

先说个有趣的事情，因为自带的电源适配器太占插座了，我使用了 QC2.0的手机充电器 + 诱骗器 + USB-DC线 提供一个12V的供电，然而诱骗失效了，5V的电压下，路由器居然可以正常的工作，这意味着可以使用USB-DC线接到高输出的USB插座上给K3供电，这个也和功耗有关：

实测，开机及待机状态下功率在10W左右，如果遇到CPU占用较高或者高速无线传输峰值功耗可以到18W（360插座依然强而有力），使用5V和12V USB-DC的时候出现过几次无法开机的情况，所以稳定性还是一般的

对比MT7261的K2P，峰值功耗15W，但是平时使用就只有6W左右，K3的电费有些不太划算

K3 160MHz

测试固件来自恩山论坛:解锁160MHz？发一个从华硕RT-AC88U提取的最新驱动

• 只能说K3有160MHz了，可以使用（80MHz的设备也可以连接），9260AC上协商速度可以到1.73G，但是测试的速率优势不显著，最糟糕的是160MHz下的信号覆盖不如现在主流价位的路由器（200+）
• 论坛里有人用AX200跑出了800Mbps+的下行速率，这个有待进一步测试（非常抱歉本文没有激动人心的结果）
• 稳定性，就测试期间而言都是可以的，没有出现速度突然崩盘的情况，但是这个需要长期的使用来体验
• 实用性，个人觉得新固件的实用性暂时不如旧固件，160MHz启动慢（5G信号不能被搜索到），并且80MHz下使用AC9260测速时，会有一段时间速率在100Mbps以下，一段时间后才能达到满速

因为是居家环境，测试期间有诸多不可控因素，这里仅模拟日常使用的场景，部分量化的结果仅供参考

路由器是K3的A1版本，已改散热

1. 台式机的Intel 9260AC网卡：2T2R支持160MHz 1.73Gbps
2. 移动端测试：iPad Pro 10.5：2T2R 866Mbps
3. 笔记本的Intel AC7620网卡：2T2R 866Mbps，这块网卡比较老了，感觉不是很好

路由器无线地区设置为澳大利亚（AU），80MHz的频段为149，36频段的速度和信号覆盖和149差别很大，附近只有一个36频段的其他信号干扰，无线功率默认（31dbm？有人说20dbm吞吐量最大是怎么回事）

160MHz的情况与说明

• 国内只有设置为36频段时160MHz才可用，按理来说地区选为AU的情况下100频段应该也可以用160MHz，但是实测加密部分空白，故判定为日常不可用
• 160Mhz在切换后，需要一段时间（几分钟）才可以被搜索到，并且新固件的两种频宽下，测试达到300+都需要等一段时间（刚开机测速70+，一段时间后才能到较快的速度）
• 在9260AC连接K3的情况下，5G WiFi的协商速率可以达到1.73Gbps，但是条件比较苛刻，如：2m左右，无遮挡物，调到一定的天线夹角，一般不超过1.5Gbps，但是对固定位置的台式机而言，测速表现和协商速率无明显关系

• 测速采用的是iperf3，参数为-P5 -R，即五个线程的TCP下行测速（去掉-R就是上行了）
• 延迟测试采用atkkping，以最快的速度ping 5000个包
• 信号覆盖测试采用Netspot绘图

信号覆盖测试

首先是大家最关心的160MHz下的速度情况，先让我们看下160MHz模式下的7620AC的信号表现（左起图一）：

左起图二和图三分别是新旧无线固件在149频段，80MHz频宽下的信号表现，两者是非常接近的，都属于比较优秀的水平

注：路由器放在图二红色区域位置，MD5:18eef 的固件名称如图，可以在Hill98的仓库找到，cad5e为新无线固件

因为两次测试的时间间隔较长，采点情况不一样，加上各种随机因素的影响，信号覆盖仅供参考，可以说的是此图还是可以看出部分明显的信号强度差距的

使用iperf3测试上图的A， B， C三个点位（下载/上传 Mbps），多次测试，按照合理性综合了下结果，总体来说能够得到的结论就是：160MHz的覆盖不佳（比现在200+价位的路由器相比应该没什么优势），与上面的信号覆盖测试相符

A点就是近距离，主要是上探峰值速率（取多次测试的最大平均值），B点隔一堵墙（但是没有关门，其实开关门对信号影响挺大的），C点就是家里信号最差的地方

1，2，3分别是AC9260，iPad以及AC7620

丢包与时延测试

多次测试所有固件和设置在B点的平均时延1ms以内，丢包率为0，我认为出现延迟波动一般是AC7620的问题