关于K3的OpenWrt - TimeForget

link管理

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

存在的问题

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

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

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

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

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

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

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

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

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

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

所有代码的基础：

[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,最近抽风，脚本里没有超时设置，会导致进程卡死，屏幕会有错误或黑屏的问题，可以通过手动指定城市解决，有能力的自己改下脚本设置一下超时，后面有时间修复

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

已知的一个致命问题: 屏幕会隔三差五的睡死，睡死时候，网路会出异常，变得非常慢，检查系统日志，会发现 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 编译

基本情况可以参考下图：

直接使用了社区的无线固件，貌似和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
 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单线程测试结果
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
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提取的最新驱动
以下出现中划线（形如：160Mbps）的结论，为23年重测后推翻的原结论，新结论用括号备注
  只能说K3有160MHz了，可以使用（80MHz的设备也可以连接），AX200协商速度可以到1.73G，但是测试的速率优势不显著，最糟糕的是160MHz下的信号覆盖不如现在主流价位的路由器（200+）
  论坛里有人用AX200跑出了800Mbps+的下行速率，这个有待进一步测试（非常抱歉本文没有激动人心的结果），我23年用AX200在紧挨着路由器的情况下也测出来了
  稳定性，就测试期间而言都是可以的，没有出现速度突然崩盘的情况，但是这个需要长期的使用来体验（在家用了一两天还行，没有出现故障）
  实用性，个人觉得新固件的实用性暂时不如旧固件，160MHz启动慢（开机后5G信号不能被搜索到，这个是正常的），并且80MHz下使用AC9260测速时，会有一段时间速率在100Mbps以下，一段时间后才能达到满速（这一点我用了AX200和其他设备之后，觉得应该是9260的问题）
因为是居家环境，测试期间有诸多不可控因素，这里仅模拟日常使用的场景，部分量化的结果仅供参考
路由器是K3的A1版本，已改散热
  台式机的Intel 9260AC网卡：2T2R支持160MHz 1.73Gbps
  移动端测试：iPad Pro 10.5：2T2R 866Mbps
  笔记本的Intel AC7620网卡：2T2R 866Mbps，这块网卡比较老了，感觉不是很好
23年使用的无线终端：
  台式机的AX200网卡：2T2R最高支持160MHz 2.4Gbps
  移动设备：
      
华为Mate40 2T2R最高支持160MHz 2.4Gbps
      小米13 2T2R最高支持160MHz 4K-QAM 2.8Gbps
路由器无线地区设置为澳大利亚（AU），80MHz的频段为149；160MHz只能用36信道频段，36频段的速度和信号覆盖和149差别很大，附近只有一个36频段的其他信号干扰，无线功率默认（界面上显示31dbm）
有人说20dbm吞吐量最大是怎么回事（实测用iwconfig wlan1 txpower 20调整5G WiFi功率后，测速确实有改善）
160MHz的情况与说明
WiFi 在5.1GHz~5.8GHz的频段划分：
  国内只有设置为36频段时160MHz才可用，按理来说地区选为AU的情况下100频段应该也可以用160MHz，但是实测加密部分空白，故判定为日常不可用
  160Mhz在切换后，需要一段时间（几分钟）才可以被搜索到，并且新固件的两种频宽下，测试达到300+都需要等一段时间（刚开机测速70+，一段时间后才能到较快的速度）
  在9260AC连接K3的情况下，5G WiFi的协商速率可以达到1.73Gbps，但是条件比较苛刻，如：2m左右，无遮挡物，调到一定的天线夹角，一般不超过1.5Gbps，但是对固定位置的台式机而言，测速表现和协商速率无明显关系
23年更新：为了方便移动端测速，在局域网内其他Linux机器上部署了网页版的speedtest；另外发现如果在K3上运行iperf3服务端的话，测速会存在CPU的性能瓶颈，即使不在K3上部署iperf3服务端，千兆左右的转发也会让K3的CPU占用较高（Flow offloading在LAN to 5G上效果似乎不明显）
  测速采用的是iperf3，参数为-P5 -R，即五个线程的TCP下行测速（去掉-R就是上行了）
  延迟测试采用atkkping，以最快的速度ping 5000个包
  信号覆盖测试采用Netspot绘图
23年更新：在除了C点之外，23年测试使用的160MHz的终端绝大多数情况下能跑500+Mbps，对比的话参考22年推出的相对高端的TP-Link XDR6088 （4*4 MIMO 160MHz），可以跑900Mbps左右
使用iperf3测试房间的A， B， C三个点位（下载/上传 Mbps），多次测试，按照合理性综合了下结果，总体来说能够得到的结论就是：160MHz的覆盖不佳（比现在200+价位的路由器相比应该没什么优势），与上面的信号覆盖测试相符
  A点就是近距离，主要是上探峰值速率（取多次测试的最大平均值），B点隔一堵墙（但是没有关门，其实开关门对信号影响挺大的），C点就是家里信号最差的地方
  1，2，3分别是AC9260，iPad以及AC7620