f78fk的博客: 2026

2026年8月23日星期日

dig → drill 对照表

用途	dig	drill
A 记录	`dig example.com A @1.1.1.1 +tcp`	`./drill -t example.com A @1.1.1.1`
AAAA 记录	`dig example.com AAAA @1.1.1.1 +tcp`	`./drill -t example.com AAAA @1.1.1.1`
MX 邮件服务器	`dig example.com MX @1.1.1.1 +tcp`	`./drill -t example.com MX @1.1.1.1`
NS 权威 DNS	`dig example.com NS @1.1.1.1 +tcp`	`./drill -t example.com NS @1.1.1.1`
TXT	`dig example.com TXT @1.1.1.1 +tcp`	`./drill -t example.com TXT @1.1.1.1`
CNAME	`dig example.com CNAME @1.1.1.1 +tcp`	`./drill -t example.com CNAME @1.1.1.1`
SOA	`dig example.com SOA @1.1.1.1 +tcp`	`./drill -t example.com SOA @1.1.1.1`
PTR 反向解析	`dig -x 8.8.8.8 @1.1.1.1 +tcp`	`./drill -t -x 8.8.8.8 @1.1.1.1`
DNSSEC / RRSIG	`dig example.com A @1.1.1.1 +dnssec +tcp`	`./drill -t -D example.com A @1.1.1.1`
DS	`dig example.com DS @1.1.1.1 +tcp`	`./drill -t example.com DS @1.1.1.1`
DNSKEY	`dig example.com DNSKEY @1.1.1.1 +dnssec +tcp`	`./drill -t -D example.com DNSKEY @1.1.1.1`
查看版本	`dig -v`	`./drill -v`
查看帮助	`dig -h`	`./drill -h`

2026年8月12日星期三

RT Linux + ARM GPIO PPS 实现纳秒级 GPS 授时（Chrony RMS Offset 40ns）

在 Zynq-7000 ARM SoC 上，通过 GPS M8N 输出 PPS 信号，经 Zynq EMIO GPIO 接入 Linux PPS Framework，使用 Chrony 驯服系统时钟。

在 PREEMPT_RT 内核和 OpenWrt Snapshot 环境下，最终 RMS Offset 稳定在 40ns 左右。

Reference ID : 47505300 (GPS)
Stratum : 1
Ref time (UTC) : Thu Jun 25 22:11:38 2026
System time : 0.000000042 seconds slow of NTP time
Last offset : -0.000000018 seconds
RMS offset : 0.000000040 seconds
Frequency : 12.248 ppm slow
Residual freq : -0.000 ppm
Skew : 0.001 ppm
Root delay : 0.000000001 seconds
Root dispersion : 0.000017178 seconds
Update interval : 16.0 seconds
Leap status : Normal
root@OpenWrt:~#

RMS offset = 0.000000040 seconds

换成纳秒：= 40 ns

也就是 0.040微秒

硬件设备：MYS-7Z020-V2-0E1D-766-C

Linux kernel :7.0.1 为了尽可能减少抖动，编译了 PREEMPT_RT 模式

RootFS: OpenWrt Snapshot

GPS模组 u-blox NEO-M8N

PPS ：GPS PPS -> Zynq EMIO -> GPIO IRQ -> Linux PPS

Chrony:
Stratum-1

将 PPS 中断处理线程调整为 SCHED_FIFO 高优先级，
以降低系统负载下的调度抖动。

2026年8月3日星期一

TL-XDR5480 WPA2/WPA3混合模式存在WPA3 SAE认证异常

平时经常遇到手机一开始连接正常，但是用了一段时间，比如用了2天，iphone会提示无法加入网络。

重启iPhone无法恢复
修改iPhone私有Wi-Fi地址(更换一个MAC地址)后立即恢复

终端 iphone8 iphone15pro ipad9代都遇到过。

无线设置: 关闭双频合一，5GHZ 149信道 80MHZ 加密方式：WPA2/WPA3混合

固件版本：TL-XDR5480易展Turbo版 1.0.46 Build 251121 Rel.51162

抓包发现失败时，iPhone8持续发送WPA3 SAE Commit认证请求：

tshark -r debug-01.cap -Y "wlan.addr == ca:a5:3e:4e:bd:47"

└─# tshark -r debug-01.cap -Y "wlan.fc.type_subtype in {0x0000, 0x0001, 0x000a, 0x000b, 0x000c} || eapol"
Running as user "root" and group "root". This could be dangerous.
  172    9.117803 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=1083, FN=0, Flags=........
  221   10.117926 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=1084, FN=0, Flags=........
  252   11.118445 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=1085, FN=0, Flags=........
  263   12.118627 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=1086, FN=0, Flags=........
  281   13.306160 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=3905, FN=0, Flags=........
  311   14.306508 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=3906, FN=0, Flags=........
  320   15.306614 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=3907, FN=0, Flags=........
  327   16.306629 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=3908, FN=0, Flags=........
  369   23.068550 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=3559, FN=0, Flags=........
  372   24.068452 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=3560, FN=0, Flags=........
  395   25.068732 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=3561, FN=0, Flags=........
  452   26.069101 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=3562, FN=0, Flags=........
                                                                                                                         
┌──(root㉿kali)-[/home/kali]
└─#

┌──(root㉿kali)-[/home/kali]
└─# tshark -r debug-01.cap -Y "frame.number == 172" -V
Running as user "root" and group "root". This could be dangerous.
Frame 172: Packet, 128 bytes on wire (1024 bits), 128 bytes captured (1024 bits)
    Encapsulation type: IEEE 802.11 Wireless LAN (20)
    Arrival Time: Aug  3, 2026 15:56:12.129792000 UTC
    UTC Arrival Time: Aug  3, 2026 15:56:12.129792000 UTC
    Epoch Arrival Time: 1785772572.129792000
    [Time shift for this packet: 0.000000000 seconds]
    [Time delta from previous captured frame: 22.581000 milliseconds]
    [Time since reference or first frame: 9.117803000 seconds]
    Frame Number: 172
    Frame Length: 128 bytes (1024 bits)
    Capture Length: 128 bytes (1024 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: wlan]
    Character encoding: ASCII (0)
IEEE 802.11 Authentication, Flags: ........
    Type/Subtype: Authentication (0x000b)
    Frame Control Field: 0xb000
        .... ..00 = Version: 0
        .... 00.. = Type: Management frame (0)
        1011 .... = Subtype: 11
        Flags: 0x00
            .... ..00 = DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0 From DS: 0) (0x0)
            .... .0.. = More Fragments: This is the last fragment
            .... 0... = Retry: Frame is not being retransmitted
            ...0 .... = PWR MGT: STA will stay up
            ..0. .... = More Data: No data buffered
            .0.. .... = Protected flag: Data is not protected
            0... .... = +HTC/Order flag: Not strictly ordered
    .000 0000 0011 1100 = Duration: 60 microseconds
    Receiver address: TpLinkTechno_a8:70:bf (f8:6f:b0:a8:70:bf)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Destination address: TpLinkTechno_a8:70:bf (f8:6f:b0:a8:70:bf)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Transmitter address: Apple_4e:bd:47 (c0:a5:3e:4e:bd:47)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source address: Apple_4e:bd:47 (c0:a5:3e:4e:bd:47)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    BSS Id: TpLinkTechno_a8:70:bf (f8:6f:b0:a8:70:bf)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    .... .... .... 0000 = Fragment number: 0
    0100 0011 1011 .... = Sequence number: 1083
    [WLAN Flags: ........]
IEEE 802.11 Wireless Management
    Fixed parameters (104 bytes)
        Authentication Algorithm: Simultaneous Authentication of Equals (SAE) (3)
        Authentication SEQ: 0x0001
        Status code: Successful (0x0000)
        SAE Message Type: Commit (1)
        Group Id: 256-bit random ECP group (19)
        Scalar: 65913c740176dfc6121118ee5676fd87f6c155fc2ac5e640ed682d82e9c8d2fc
        Finite Field Element: 21f1187582cfd2b7ca85884b982e53f31b4b48c32046e7a5fb6e85ba0145197ce3912f50df200cbb8af7dd35aea65b62f0d60bde75086d26b6442d8f1a29c8a6

                                                                                                                         
┌──(root㉿kali)-[/home/kali]
└─#

抓包中未发现5480回复对应的SAE Commit/Confirm帧。

可能的原因：
WPA2/WPA3混合模式下，AP侧WPA3 SAE认证状态机或相关缓存释放异常，导致该STA MAC后续SAE认证流程无法继续。

解决方法：
由于TPLINK 没有提供 WPA2 Only 或 WPA3 Only 模式，
所以妥协的方案，使用WPA-PSK / WPA2-PSK 混合模式。(我自己是更换了其他支持 WPA2 Only 和 WPA3 Only 的无线路由器)。

从极简工程与减少驱动 Bug 的角度来看，更合理的界面加密选项其实只需保留 3 种：

 1. WPA2-PSK (AES)
   默认模式，兼容性最好，适合 2006年至今绝大多数 Wi-Fi 设备，
   包括大量旧款智能家居设备（IoT摄像头、扫地机器人、打印机等）。
 
2. WPA3-SAE
   新一代个人无线安全标准，2019年至今的新款主流设备普遍支持，
   提供更强的密码安全保护。
 
3. Open
   无密码开放网络，适用于访客或公共访问场景。

要99.999%的兼容性+安全选择WPA2-PSK(AES)，家里没有老设备，想要更安全的选择WPA3-SAE。

2026年6月27日星期六

中兴F7015TV3光猫删除TR069

// 查看TR069的数字

sendcmd 1 DB p WANC

// 删除TR069

sendcmd 1 DB delr WANC 0

2026年4月30日星期四

CVE-2026-31431 漏洞验证和临时修复方案

昨天披露了一个漏洞，CVE-2026-31431。

简单说就是普通用户一旦拿到shell，就可以利用该漏洞直接提权到root。

漏洞验证：

git clone https://github.com/rootsecdev/cve_2026_31431.git

cd cve_2026_31431

python3 test_cve_2026_31431.py

echo $?

返回 0 ：无漏洞，安全的。

返回 2：有漏洞

返回 1：测试错误

目前 Ubuntu 官方还没有推送补丁，

临时解决方案:

sudo tee /etc/modprobe.d/disable-algif-aead.conf <<<'install algif_aead /bin/false'

sudo rmmod algif_aead 2>/dev/null

官方推送新内核后，恢复模块:

sudo rm /etc/modprobe.d/disable-algif-aead.conf

sudo modprobe algif_aead

2026年4月29日星期三

ARM Cortex-A53 (无AES)平台加密网络转发性能测试与对比分析

1. 测试背景

本文基于 XG-140G-TF 设备（ARM Cortex-A53 四核，无AES硬件加密加速单元），测试其在不同网络数据转发架构实现方式的性能表现，用于评估其在局域网数据转发场景下的性能表现。

2. 测试环境

设备：XG-140G-TF
CPU：ARM Cortex-A53(1.2Ghz) ×4
加密能力：ARMv8 无 AES 硬件指令扩展
网络环境：千兆局域网
TLS加密套件：TLS_AES_128_GCM_SHA256（TLS 1.3）

3. 测试方案说明

方案A：内核级透明转发架构

基于操作系统网络栈的透明转发机制，实现数据包在内核层处理与转发。

方案B：用户态虚拟网络接口架构

基于用户态网络虚拟化技术，通过虚拟网卡进行数据封装与转发。

4. 性能测试结果

转发架构	吞吐性能
内核级透明转发架构	≈ 170 Mbps
用户态虚拟网络接口架构	≈ 120 Mbps

2026年4月22日星期三

固件发布 XG-140G-TF 极简 OpenWrt | 修复2.5G | NPU硬件加速

20260422：

【设备信息】

设备型号：Nokia Bell XG-140G-TF
系统版本：OpenWrt
Linux 内核：6.12.80

【固件简介】

本固件基于 OpenWrt 6.12 内核，针对 Nokia XG-140G-TF 进行 2.5G PHY 修复与 NPU 硬件 NAT 加速优化，可实现千兆满速下极低的 CPU 占用转发，系统结构保持极致精简。

【核心特性】

1. 完美修复 2.5G 网口
LAN1 默认作为 WAN (2.5GbE)
LAN2 / LAN3 / LAN4 为正常千兆 LAN
解决了市面部分固件 2.5G 网口无法驱动的问题，驱动已手工修复，测速稳定正常工作。

2. NPU 硬件 NAT 加速
可启用 nft flowtable + hw offload，支持 NPU 硬件加速转发。
固件已集成最新驱动：en7581-npu-firmware (20260410-r1) 与 en8811h-firmware (20260410-r1)。
实测 WAN → LAN NAT 满速 1Gbps 时，CPU 占用极低（不超过10%）。

3. 极致精简，纯净稳定
保留基础路由功能，拒绝臃肿。
仅内置：LuCI 中文界面、htop、iperf3。

4. 官方软件源支持
全面支持 apk update / apk add，实测官方软件源正常可用。

5. 性能与并发优化
默认连接数优化至 131072，大幅提升 NAT 并发连接能力。

6. 内存占用极低
开机仅占用约 100MB，空闲 RAM ≥ 200MB，极度适合做主路由长时间稳定运行。

【刷机方法】

1. 原始固件备份（非常重要）
官方固件开启 Telnet 后，请务必备份 mtd0-mtd17。由于该设备无 USB 口，需使用 TFTP 方式备份。
注意：请勿只备份 mtd18，实测因分区过大备份后的 MD5 校验不通过，必须逐个备份 mtd0-17。

# 备份命令示例（192.168.1.2 为你的 TFTP 服务器地址）

dd if=/dev/mtd0 | tftp -p -l - -r mtd0.bin 192.168.1.2

dd if=/dev/mtd1 | tftp -p -l - -r mtd1.bin 192.168.1.2

# 依此类推备份至 mtd17

2. 刷入 uboot
具体操作流程可参考：https://nwrt.kuroneko.host/flashdocs/XG-040G-MD.html

3. 刷入固件
设备通电等待 2 秒，用卡针长按 Reset 键不松手。
观察 LED 闪烁 5 次后松手，浏览器访问 192.168.1.1 进入刷机页面。
上传 openwrt...factory.bin 固件进行刷写。
后期更新：直接在 OpenWrt 管理后台“备份与更新”中上传 sysupgrade.bin 即可。

【使用说明：开启硬件 NAT】
注意：为保持系统初始纯净，默认未开启硬件 NAT 转发。
请在 OpenWrt 管理页面依次点击：网络 -> 防火墙 -> 路由/NAT 卸载，在“流量卸载类型”中选择“硬件流量卸载”即可生效。

【固件下载地址】

https://mbd.pub/o/bread/mbd-YZWcmJxpZg==

订阅：博文 (Atom)