ReiAC的 RSS 预览

使用 mimic + WireGuard 组网

2026-09-13 10:30:00

将一台腾讯云轻量和一台瓦工中, 通过 mimic 传输进行 WireGuard 组网

原来我是用 Phantun 的, 前两天听一个群友在研究这个, 也想玩一下

2026-09-27 更新

把 p330 改成了: wg直连腾讯云+ wg + mimic 连瓦工,顺带再研究一下上次没挖到底的 MTU 坑

2026-09-26 更新

把家里的 p330 也接进来了

拓扑与地址规划

项目	腾讯云	瓦工	本地 p330
系统	Debian 13 (trixie), kernel 6.12.107	Debian 13 (trixie), kernel 6.12.107	Debian 13 (trixie), kernel 6.12.107
虚拟化	KVM / virtio_net	KVM	物理机 / Intel e1000e
网卡可见地址	`10.0.X.X/22`（NAT 后）	`真实公网地址`	`家宽内网地址`（PPPoE, 外层 MTU 1492）
WireGuard 地址	`192.168.X.1/24`（wg0）+ `192.168.X.1/32`（wg1）	`192.168.X.2/24`	`192.168.X.3/32`（两条隧道共用）
监听端口	51820（mimic）+ 51821（直连）	51820	51820（mimic 到瓦工）+ 51821（直连腾讯云）
mimic 过滤条件	`local=腾讯云内网IP:51820`	`local=真实公网地址:51820`	`remote=瓦工IP:51820`

配置

`/etc/wireguard/wg0.conf`

腾讯云

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11



[Interface]
Address = 192.168.X.1/24
ListenPort = 51820
PrivateKey = 不告诉你
MTU = 1380

[Peer]
PublicKey = 不告诉你
AllowedIPs = 192.168.X.2/32
Endpoint = 瓦工IP:51820
PersistentKeepalive = 25

瓦工

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11



[Interface]
Address = 192.168.X.2/24
ListenPort = 51820
PrivateKey = 不告诉你
MTU = 1380

[Peer]
PublicKey = 不告诉你
AllowedIPs = 192.168.X.1/32
Endpoint = 腾讯云EIP:51820
PersistentKeepalive = 25

`/etc/mimic/eth0.conf`

腾讯云

1
2
3
4
5



log.verbosity = info
link_type = eth
xdp_mode = skb
max_window = true
filter = local=内网地址:51820

瓦工

1
2
3
4
5



log.verbosity = info
link_type = eth
xdp_mode = skb
max_window = true
filter = local=公网地址:51820

nftables

腾讯云 — /etc/nftables.conf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17



#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state vmap { established : accept, related : accept, invalid : drop }
        meta l4proto { icmp, ipv6-icmp } counter accept
        iifname lo accept
        iifname "wg0" accept
        tcp dport 22 accept
        tcp dport 51820 accept
        udp dport 51820 accept
    }
    chain forward { type filter hook forward priority filter; policy drop; }
    chain output  { type filter hook output  priority filter; policy accept; }
}

瓦工 — 这台机器是老机器, 所以追加这几行就好了

1
2
3



        iifname "wg0" accept
        tcp dport { 51820 } accept
        udp dport { 51820 } accept

踩到的坑

mimic 配置文件的 `filter` 只接受一个 origin

GitHub master 分支的 man page 写的是 {origin}={ip}:{port}，并举例可追加覆盖项，容易让人以为能写：

1

filter = local=腾讯云内网IP:51820,remote=瓦工IP:51820   # 0.7.0 报错

实际 0.7.0 会直接拒绝：

1
2

Error unsupported option type: 'remote'
Error failed to read configuration file

逗号后面只能跟 padding / handshake / keepalive 这类覆盖项，不能跟第二个 origin。

1

filter = local=腾讯云内网IP:51820

NAT

腾讯云的 mimic 过滤器必须写内网地址，而不是鹅提供的EIP。因为 eBPF 挂在 TC/XDP 上，看到的是 NAT 转换前的包。

MTU黑洞

mimic 官方文档推荐的隧道 MTU 是 1408，但在本环境中 100% 丢包。实测最大可用值为 1392，最终采用了个 1380, 我到现在还没彻底明白这个坑是怎么来的

mimic 文档给出的算法是"在 WireGuard MTU 基础上减 12"：以太网 1500 → WireGuard 1420 → mimic 1408。按此配置后现象是：

小包正常：ping 通、TCP 三次握手成功
大包全丢：iperf3 显示 0.00 Bytes、大量重传，随后 Connection refused
典型 MTU 黑洞（PMTUD 失效）特征

实测 DF 位探测（内层 IP 包大小 vs 连通性）：

内层 IP 包	结果
1380	通
1392	通
1393	不通
1400 / 1408	不通

最大可用内层 MTU = 1392。最终取 1380，留 12 字节安全余量（防 mimic 在特定情况下追加 TCP 选项导致外层包变大）。

排除掉的其它可能性：

公网基线路径 MTU 实测为 1500（ping -M do -s 1472 成功），排除腾讯云 overlay 封装
切换 XDP 模式无改善，排除 eBPF 处理问题
双向均验证（瓦工→腾讯云在 MTU 1380 下大包也全通）

推测原因为 mimic 生成的 TCP 报文头带选项（时间戳/SACK/窗口缩放等），使外层 TCP 头达到约 40+ 字节而非 20 字节，实际每包开销约 108 字节而非文档所述的 74 字节，故上限落在 1392 而非 1416。

XDP native 模式在 virtio_net 上触发连接中断

腾讯云是 KVM + virtio_net 网卡。mimic 以默认的 native 模式挂载 XDP 的瞬间，当前 SSH 会话被 RST（kex_exchange_identification: read: Connection reset by peer），但 ICMP 与重建连接均正常。

这与文档中提示的 issue #11 现象一致——部分宿主机阻断 guest 的 virtio_net native XDP。按文档建议改用：

1

xdp_mode = skb

由于腾讯云出口带宽只有 6 Mbps，skb 模式相对 native 的性能损失（generic XDP 走 skb 路径）完全无关紧要*

`max_window` 显著降低重传

mimic 伪造的 TCP 默认窗口约 13 KB。腾讯云↔瓦工的 RTT 是 130 ms，13 KB / 130 ms ≈ 0.8 Mbps，在高 RTT 链路上窗口会成为瓶颈并引发大量重传。

开启后（两端都要开）：

1

max_window = true

重传次数实测从 1525 降到 102（同样 6 Mbps 饱和链路、6~8 秒测试）。抓包可见窗口变为 win 65535。

防火墙必须同时放行 TCP 和 UDP

mimic 的透明改写发生在 eBPF 层，netfilter 在不同方向看到的东西不一样：

观测点	看到的协议
出口方向（TC 在 netfilter OUTPUT 之后执行）	UDP
入口方向（XDP 在 netfilter INPUT 之前执行，已还原）	UDP
链路中间的真实抓包	TCP（出口）

所以规则必须TCP/UDP都写

1
2

tcp dport 51820 accept
udp dport 51820 accept

实测抓包证据（腾讯云的 eth0）：

1
2

出: IP 腾讯云内网IP.51820 > 瓦工IP.51820: Flags [.], win 65535, length 128   ← TCP
入: IP 瓦工IP.51820 > 腾讯云内网IP.51820: UDP, length 128                    ← UDP

验证结果

连通性

1
2
3



$ ping -c 4 192.168.X.2          # 从 腾讯云
4 packets transmitted, 4 received, 0% packet loss
rtt min/avg/max/mdev = 130.352/163.151/261.358/56.699 ms

mimic 效果

腾讯云的 mimic show -c eth0：

1
2
3



Connection 腾讯云内网IP:51820 => 瓦工IP:51820
  State: Established
  Peer MSS: 1332

抓包证明出口全部为 TCP、UDP 捕获数为 0：

1
2
3
4



--- TCP 51820 ---
IP 腾讯云内网IP.51820 > 瓦工IP.51820: Flags [.], win 65535, length 128
--- UDP 51820 ---
0 packets captured

把家里的机器也接进来

前几天把家里的 p330 也接进了这个网, 分配 192.168.X.3。

	腾讯云	瓦工	本地 p330
角色	hub	海外hub	家用服务器
网络位置	公网 EIP, 网卡上是内网地址	真实公网 IP	家宽 NAT 后, PPPoE
网卡	virtio_net	—	Intel e1000e (其实还插了个82599ES, 但是这块卡不用来走这条路线)
XDP 模式	`skb`	`skb`	`skb`
mimic filter	`local=` 本机地址	`local=` 本机地址	`remote=` 对端地址

p330 侧

/etc/wireguard/wg0.conf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11



[Interface]
Address = 192.168.X.3/24
ListenPort = 51820
PrivateKey = 不告诉你
MTU = 1380

[Peer]
PublicKey = 不告诉你
AllowedIPs = 192.168.X.0/24
Endpoint = 腾讯云EIP:51820
PersistentKeepalive = 25

/etc/mimic/eno1.conf

1
2
3
4
5



log.verbosity = info
link_type = eth
xdp_mode = skb
max_window = true
filter = remote=腾讯云EIP:51820

p330 的地址是 DHCP 分的, 一旦 DHCP 换了地址, mimic 就匹配不上任何包, 所以客户端这边按对端匹配:

man page 里 stale 参数的说明也是围绕 remote filter 描述"客户端本地端口变化"的场景, 算是官方暗示了这种用法。

但是话又说回来了, 家里到腾讯云感觉直接跑wg就行了……一共6M带宽, 运营商也 QoS 不到哪里去

这次 p330 是物理机, Intel e1000e, 正好也在 mimic 文档点名的那份"原生 XDP 可能不稳定"的驱动列表里 (e1000/e1000e/igb/igc)。

所以直接写 xdp_mode = skb, 生效后 ip link show eno1 能看到 xdpgeneric:

1
2

2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 xdpgeneric ...
    prog/xdp id 200 name ingress_handler tag 394bf6a8d35f24d3 jited

腾讯云侧

之前在腾讯云的 filter 写的是

1

filter = local=内网地址:51820

它匹配的是"本机地址 + 端口", 跟对端是谁无关 —— 所以加第二个 peer 时, 这条 filter 天然就覆盖了新连接, 一行都不用动。

mimic show -c eth0 也确实直接变成两条:

1
2
3
4
5
6
7



Connection 10.0.X.X:51820 => 瓦工IP:51820
  State: Established
  Peer MSS: 1332

Connection 10.0.X.X:51820 => 家宽公网IP:3102
  State: Established
  Peer MSS: 1424

WireGuard 那边暂时用 live 的方式加 peer, 不重启接口，家宽后也没有什么 Endpoint 好写:

1

# wg set wg0 peer <p330公钥> allowed-ips 192.168.X.3/32

瓦工侧

要让 p330 能访问瓦工, 得把瓦工上"腾讯云"这个 peer 的 AllowedIPs 从 /32 放宽:

1

AllowedIPs = 192.168.X.0/24   # 原来是 192.168.X.1/32

/32 会同时卡住两件事: 不放行源地址是 .3 的包, 也不把去 .3 的回程路由进隧道

MTU 测试

上次在这条 腾讯云↔瓦工 链路上测出来的最大内层 MTU 是 1392, 当时还推测了一通"mimic 的 TCP 头带选项"云云。这次在 p330 这条链路上重新做 DF 位探测, 结果对不上。

先测外层路径本身 (直接 ping EIP, 不经隧道):

外层 IP 包	结果
1492	通
1493	不通

家宽是 PPPoE, 外层 MTU 是 1492 而不是 1500。

再临时把 p330 的 wg0 MTU 调大, 在隧道内测:

内层 IP 包	结果
1424	通
1425	不通

有个细节我还没完全想明白: 外层 1492 − 内层 1424 = 68 字节开销。按"mimic +12、TCP 头 20、IP 头 20"算是 52, 对不上, 中间差 16。大概率是 WireGuard 自己按 16 字节对齐 padding、或者 mimic 那个 fragment 的排布在起作用。

最终仍然用 1380, 没有跟着调到 1424。原因是 wg0 的 MTU 是 per-interface 的, 一个接口上所有 peer 共用一个值 —— 腾讯云那边 wg0 已经是 1380, 而且 腾讯云↔瓦工 那条链路的上限本来就是 1392。单独把 p330 调到 1424 就变成非对称 MTU, 迟早出问题。1380 在这条链路上留了 44 字节余量, 够用。

验证

连通性

三方两两互通。从 p330 出发:

1
2
3
4
5
6
7



# ping -c 4 192.168.X.1          # 腾讯云
4 packets transmitted, 4 received, 0% packet loss
rtt min/avg/max/mdev = 17.366/17.830/18.312/0.334 ms

# ping -c 4 192.168.X.2          # 瓦工
4 packets transmitted, 4 received, 0% packet loss
rtt min/avg/max/mdev = 148.251/148.379/148.493/0.086 ms

p330→瓦工的 148 ms ≈ p330→腾讯云的 18 ms + 腾讯云→瓦工的 130 ms, 和上次测的 130 ms 对得上。从瓦工 traceroute 也确认是绕腾讯云过去的:

1
2
3



# traceroute -n 192.168.X.3
 1  192.168.X.1  130.639 ms
 2  192.168.X.3  148.209 ms

mimic 效果

p330 的 mimic show -c eno1:

1
2
3



Connection 家宽内网地址:51820 => 腾讯云EIP:51820
  State: Established
  Peer MSS: 1424

在 p330 的 eno1 上抓包, 出口 TCP / 入口 UDP 的分裂现象和上次完全一致:

1
2
3
4



--- TCP, 17 个 ---
IP 家宽内网地址.51820 > 腾讯云EIP.51820: Flags [.], win 65535, length 128
--- UDP, 16 个 ---
IP 腾讯云EIP.51820 > 家宽内网地址.51820: UDP, length 128

win 65535 说明 max_window = true 也生效了。

吞吐

方向	吞吐	说明
p330 → 腾讯云	88.0 Mbps	跑的是家宽上行, 重传 79
腾讯云 → p330	5.77 Mbps	6 Mbps 出口跑满了, 重传 676

下行那 676 次重传和上次的现象一致 —— 6 Mbps 出口被打满时, mimic 伪造的 TCP 会大量重传 (上次 max_window 没开的时候是 1525)。

p330 改直连腾讯云, 另开一条到瓦工

2026-09-27 更新

上次 p330 是经 mimic 连腾讯云, 去瓦工靠腾讯云中转。这样有两个问题:

RTT 白涨: p330→瓦工 148 ms = p330→腾讯云 18 ms + 腾讯云→瓦工 130 ms, 中间那一跳纯属绕路
去瓦工的流量得过腾讯云那 6 Mbps 出口, 直接被卡死

所以拆成两条独立隧道:

wg0 直连腾讯云, 不走 mimic
wg1 经 mimic 连瓦工

腾讯云的第二个接口

换个端口就完事, mimic 一行都不用改

/etc/wireguard/wg1.conf:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10



[Interface]
Address = 192.168.X.1/32
ListenPort = 51821
PrivateKey = 不告诉你
MTU = 1420

[Peer]
# p330 (NAT 后, 不设 Endpoint, 靠对端保活)
PublicKey = 不告诉你
AllowedIPs = 192.168.X.3/32

nftables 补两行:

1
2

iifname "wg1" accept
udp dport 51821 accept

p330: 两条隧道共用一个 IP, 必须改成 /32

p330 两条隧道都用 192.168.X.3。这里有个必须改的地方: wg0 原来是 /24, 现在得改成 /32。

因为 /24 会在 p330 上生成一条 192.168.X.0/24 dev wg0 的子网路由, 两条隧道会抢整段, 去瓦工的流量会被塞进连腾讯云的那条。

改成 /32 之后, 每条隧道只按对端的 /32 主机路由转发:

1
2
3
4



# ip route get 192.168.X.1
192.168.X.1 dev wg0 src 192.168.X.3     # 直连腾讯云
# ip route get 192.168.X.2
192.168.X.2 dev wg1 src 192.168.X.3     # 经 mimic 到瓦工

两个接口扛同一个 /32 地址是没问题的, 因为源地址恒为 .3, 不存在选择歧义。

/etc/wireguard/wg0.conf (直连腾讯云):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11



[Interface]
Address = 192.168.X.3/32
ListenPort = 51821
PrivateKey = 不告诉你
MTU = 1420

[Peer]
PublicKey = 不告诉你
AllowedIPs = 192.168.X.1/32
Endpoint = 腾讯云EIP:51821
PersistentKeepalive = 25

/etc/wireguard/wg1.conf (mimic 连瓦工):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11



[Interface]
Address = 192.168.X.3/32
ListenPort = 51820
PrivateKey = 不告诉你
MTU = 1380

[Peer]
PublicKey = 不告诉你
AllowedIPs = 192.168.X.2/32
Endpoint = 瓦工IP:51820
PersistentKeepalive = 25

mimic 过滤器跟着改成指向瓦工:

1

filter = remote=瓦工IP:51820

瓦工

加一个新 peer:

1
2
3



[Peer]
PublicKey = p330 的公钥
AllowedIPs = 192.168.X.3/32

WireGuard 的 allowed-ips 是最长前缀优先: 去 .3 命中 /32 走 p330 直连, 去 .4 还是走 /24 经腾讯云。

加 peer 用热加载, 不重启接口 (当时瓦工↔腾讯云正在传数据):

1

# wg set wg0 peer <p330公钥> allowed-ips 192.168.X.3/32

同时写进 /etc/wireguard/wg0.conf, 保证重启后还在。

验证

路径	方式	RTT
p330 → 腾讯云	直连, 明文 UDP	13 ms
p330 → 瓦工	mimic, 混淆成 TCP	139 ms
(上次) p330 → 瓦工, 绕腾讯云		148 ms

抓包确认两条隧道行为

1
2
3
4
5



--- 到腾讯云 :51821 (期望 UDP) ---
IP 家宽内网地址.51821 > 腾讯云EIP.51821: UDP, length 128          ← 明文 ✓

--- 到瓦工 :51820 (期望 TCP) ---
IP 家宽内网地址.51820 > 瓦工IP.51820: Flags [.], win 65535, length 128    ← 混淆 ✓

win 65535 说明 max_window 生效了。两条隧道都做了满包 DF 探测 + 真实 HTTP 请求 (200 / 301), 排除了 MTU 黑洞。

回看 MTU 问题

这次测下来的发现:

开销恒为 72 字节, 而且没有 padding

直接在腾讯云出口抓包, 量已知内层大小的包:

内层 IP	外层 TCP IP
1392	1464
1400	1472

差值恒为 72。而且内层 1400 发出去的就是 1472, 不是 1480, 说明 WireGuard 并没有做 16 字节对齐 padding。

符合理论: WG 头 32 + TCP 头 20 + IP 头 20

只有 TCP 包有这个限制

逐字节探边界:

内层 IP	外层 TCP IP	结果
1392	1464	通
1393	1465	不通

外层卡在 1464。

可是同一条路径:

ICMP: 两个方向都能过 1500 (1504 才失败)
UDP: 从腾讯云打向瓦工, 载荷 1472 (IP 1500) 0% 丢包

也就是说路径对 UDP/ICMP 是 1500, 对 mimic 的 TCP 却卡在 1464, 应该是腾讯云针对 TCP 的限制。

两个方向的上限还不一样

反方向 (瓦工→腾讯云) 再测:

内层 IP	外层 TCP IP	结果
1424	1496	通
1440	1512	不通

1512 > 1500, 这个失败就是路径 MTU 本身; 而 1496 能过。

所以:

腾讯云 → 瓦工: 上限 1464
瓦工 → 腾讯云: 上限 1496 (受路径 MTU 约束)

两个方向根本不是同一个机制。

(顺带一提, 中间点 1472 测到过一次 25% 丢包, 样本太小, 可能只是抖动, 没有深究。)

抓包

结论是: 1464 = 1424 + 20 + 20。而 1424 这个数在 mimic show 里出现过:

1
2
3
4
5
6
7
8
9



# 瓦工上
Connection 瓦工IP:51820 => 腾讯云EIP:51820
  Peer MSS: 1424          ← 瓦工认为腾讯云通告的
Connection 瓦工IP:51820 => 家宽公网IP:51820
  Peer MSS: 1452          ← 瓦工认为 p330 通告的

# 腾讯云上
Connection 腾讯云内网IP:51820 => 瓦工IP:51820
  Peer MSS: 1332          ← 腾讯云认为瓦工通告的

上次只能写"这个巧合很可疑"。这次直接把握手包抓下来了 —— 在腾讯云重启 mimic 触发一次新握手, 抓到的 SYN:

1
2

10.0.16.6.51820 > 220.185.230.26.37135: Flags [S], win 65535,
    options [mss 1460, nop,wscale 14,nop,nop,sackOK], length 0

mimic 通告的 MSS 是 1460 —— 1500 MTU 下的标准值, 本身完全正常。

可是瓦工那边收到的是 1424:

1

1460 − 1424 = 36 字节

中间有设备在握手路径上把 MSS 改写掉了, 砍了 36 字节。然后按这个值丢弃超长段 —— 于是外层上限 = 1424 + 20 + 20 = 1464, 和实测边界严丝合缝。

这也解释了为什么反方向没这个现象: 两个方向走的中间设备和策略不一样, 一边做了钳制, 一边没做。

附: 单侧重启 mimic 导致 mimic 断掉

这个地方我自己其实也没特别搞懂，因为时间很短，属于随便猜一下，主要是复述一下现象

我在给出这个列表之外还有一个老家那边的小电脑分配了 .4 地址, 通过 mimic + wg 连接到腾讯云

重启腾讯云的 mimic 抓到的SYN 包。抓完发现: 瓦工几秒内自己恢复了, 但 .4 家宽的的设备直接断了, 而且不会?自愈（感觉也不是, 不太容易自愈

盲猜的原因: mimic 的连接状态是两端的, 单侧重启只清掉一半。

腾讯云重启 → 忘了这条连接, 于是主动发 SYN 想重建
.4 没重启 → 它那边仍认为连接是 Established, 收到 SYN 也不理会, 继续按老连接发数据
腾讯云在 SYN_SENT 状态收到数据包 → 判定 invalid TCP state → 回 RST → 销毁重试

日志里就是这个循环:

1
2
3
4



Info  :: initializing connection
Warn  :: connection destroyed (invalid TCP state), retry in 10 seconds
Warn  :: connection destroyed (invalid TCP state), retry in 10 seconds
...

超时不会自愈 mimic 的 keepalive / stale 超时都以"对端无活动"为前提, 而腾讯云一直在发 SYN/RST —— 对 .4 来说这一直算"有对端活动", 超时永远不触发。死锁。

感觉最后是运气好: .4 的 NAT 出口端口正好换了 (37135 → 45733), 新五元组被 mimic 当成一条全新连接, 直接建起来, 把旧的那条晾在一边变成 Idle。

upd: 我傻逼了, reboot了腾讯云, 又断了, 可能只能使用 “叫妈妈重启家里云” 了

XiaomiEU 固件添加国行 NFC

2025-12-12 20:50:27

近期将手机从 AfterlifeOS 这一类原生刷回了 HyperOS3, 小米14 的类原生还是不够完善

不过国行版本的 HyperOS 不超过三天就让我想把手机摔了, 因此刷了基于国行固件的魔改版本 XIAOMI.EU

但是刷完之后, 国行的 NFC 功能用不了, 我的车钥匙/门卡/交通卡可还依赖这玩意呢

找了一下还没有适配当前版本的 Kernel SU 模块, 于是自己解包做了一个

解包国行系统包

先下载国行包并解压

1
2

wget https://bkt-sgp-miui-ota-update-alisgp.oss-ap-southeast-1.aliyuncs.com/OS3.0.5.0.WNCCNXM/houji-ota_full-OS3.0.5.0.WNCCNXM-user-16.0-306ce971bf.zip
unzip houji-ota_full-OS3.0.5.0.WNCCNXM-user-16.0-306ce971bf.zip payload.bin

现在的安卓刷机包大多会打成 payload.bin 这种包格式, 需要先解包

1
2
3
4



wget https://github.com/ssut/payload-dumper-go/releases/download/1.3.0/payload-dumper-go_1.3.0_linux_amd64.tar.gz
tar -xvf payload-dumper-go_1.3.0_linux_amd64.tar.gz
chmod +x payload-dumper-go
./payload-dumper-go -o ./ ./payload.bin

查看文件尺寸, 最大的是这个 product.img 用 file 指令查看后可以知道这是个 erofs 的单分区镜像包, 我们将其挂载

1
2
3



pacman -S erofs-utils erofsfuse
mkdir product
mount -t erofs -o loop product.img product

然后在挂载镜像的 app 目录下找到 MINextpay MITSMClient UPTsmService 三个必要组件, 将其打包成一个最简的 KernelSU module 刷入即可, 也就是只有 system/app/组件 和 module.prop 文件的最简包

1
2
3
4



cp -a ./product/app/MINextpay ./module/system/app/MINextpay
cp -a ./product/app/MITSMClient ./module/system/app/MITSMClient
cp -a ./product/app/UPTsmService ./module/system/app/UPTsmService
cp -a ./product/app/MIUISuperMarket ./module/system/app/MIUISuperMarket

为了方便后续更新版本, 做了个 Github Action 用来打包

其中奇怪的一点是, 在 Action 中使用 mount -t erofs -o loop product.img product 挂载镜像后拷贝之后, 执行到 cp 这一步的时候会报

看上去是内存超限了的样子

因此换成了 fsck.erofs product.img --extract=product 指令将镜像中的文件提取出来

最后成品可以在 https://github.com/ReiAccept/MiPay4XiaomiEU 中找到

方程豹钛7

2025-12-03 23:09:39

换车与选车

从 2019 年高中毕业拿到驾照到我工作两年，我开的车一直是家里的 Audi A6L 55TFSI Quattro 车型，说实话我相当喜欢这辆车，底盘稳定可靠，动力跟脚，机械结构上除了发动机烧机油外没见过啥问题，让我信心十足的度过了我的新手驾驶期。

不过工作两年后，我需要在杭州买一辆车，需要满足以下条件

品牌无所谓，家里一直开的是BBA，我自己没啥情怀
某方面的技术领先（这点其实淘汰了日系，只留下了德系（发动机/底盘技术领先）和国产车（三电技术领先））
买起来比较简单……别那种换电租电什么方案一堆的
我自己的现金流支持全款买

算了一下自己可以拿出来的流动资金，最开始的换车计划选了以下三台车（当然我实际上不止试驾了三台）

Xiaomi YU7 Pro
Tesla Model Y
Audi Q6L

一些试驾与感受

Xiaomi YU7 Pro

好开，好车，我各个方面都很喜欢，但是提车要38周，遂放弃

如果不是提车慢，这篇文章就是小米YU7了

Tesla Model Y

好开，底盘稳，动力强，操控灵

但是我不好说这是不是一辆好车

作为一个一直坐家中BBA传统油车长大的人，我认为，车内座舱的体验也是驾车很重要的一部分，特斯拉的内饰真不太行

老生常谈的屏幕换档方向盘按键转向灯也是我觉得难受的地方

Audi E5

不错，但是没有四个圈不好看

Audi Q6L

油改电真不行吧

焕新极氪7X

全车电动门很棒, 车机大屏和很棒, 整车加速, 操控都不错, 还有空气悬挂, 就是后排空间可能有点小

那这车那么好, 为什么不买呢？

家里人听说是吉利车：吉利车，天～窗～漏～水～啦～

哈哈，台州人对吉利的刻板印象来了

不过认真的说，吉利车不差，油的部分比BYD好，我觉得是无可争议的国产第一，底盘调教在国产车中也十分优秀, 但是电的部分确实比不上BYD

方程豹钛7

说起来我最开始不认识这个牌子，但是滨江展厅开在吉利店边上，路过的时候看到里面摆了一辆钛7，外观看上去很霸气，于是加了销售的微信，预约了第二天的试驾。

试驾后的体验确实还可以，问了一下知道是BYD的车

BYD的车到还有个好处，车机开adb折腾方便

福特智趣烈马（云）

这个车处于发布但是没有开售，不过我还挺喜欢的，所以在这里云一下

BRONCO 作为美系车驾驶方面不会差

但是他是个增程车，高速油耗比插混高（废话，你都买美系了还在意油耗？）

越野方面作为老牌美系车，给的比钛7多，还给了个全尺寸备胎

从已发布的信息上看是个好车但是还在预售中，买不到也试不到

确定购买与提车

说实话，试完之后感觉方盒子车真的视野好，且空间大更舒适，所以于 10.19下订, 11.04提车，相对于之前刚开始想的三台车（30W左右），实际上是省钱了哈哈

提车流程反正就那一套，方程豹的客餐还可以，不过橘子是酸酸的

主要是原先自己想要的三台车试驾后，都有些当时不可接受的问题，这个车正好还挺符合我各方面爱好和习惯的，而且比亚迪的三电技术也不错

1000KM 后

一千公里其实也没多少，开出去和朋友在钱塘江钓鱼玩玩之类的，然后从杭州开次高速回台州老家就差不多了。

底盘上，没有之前开A6L的信心足，跑一次高速就很明显能感受到，不过这两车也不在一个价位，这车二十来万，快一米九高，哪怕电池在车底带来天然的稳定性，和能买两台钛7的A6L对比确实有点欺负他了

动力上，不得不说这套插混系统真的是天才，太有力了兄弟，这也是电机系统领先于内燃机的地方

操控，灵活，好

银欣 CS382

2025-04-06 05:36:06

为什么要更换机箱

INWIN 的 MS04 作为 NAS 机箱在我这服役多年，承载了凄惨红H61 + i5-3470 和华擎H97M-ITX/ac + E3-1265Lv3 两代硬件，当我这几天想给他升级 B760I + i3-12100 时，机箱的原装电源终于是吃不太消，来自 1U 电源风扇轴承的声音到达了一个让人难以忍受的程度。

为了拯救这个老机器，我还尝试购买了一下海韵的 350M1U 电源更换上去，当时看中的是海韵的 50% 以下电源负载时风扇停转功能。但是这个电源，在 MS04 这个箱子里的散热有点问题，导致虽然时低负载情况下，依旧会在开启一段时间后积热，然后风扇开始转动，海韵给这个电源配备了恐怖的万转风扇，这个风扇在这种情况下并未全速运行，但是依旧有令人讨厌的声音。

还有一点就是，原机上是 4*14T 的 WD HC530 硬盘，其实也有点不够用

终于，在清明节晚上大半夜，我决定是时候光荣退役这台 MS04，换个新的 8 盘位 NAS 机箱。

机箱选型

考虑过以下几个机箱选型

迎广 MS08

那么大一个箱子，明明不缺空间，用的却是 1U 电源，排除

银欣 DS380

虽然是个8盘位箱子，但是硬件兼容性还是小机器那套，排除，不过体积确实小

宝藏盒 Pro

小作坊的定制产品，我还挺喜欢，用的曙光的金属盘架，不过非常贵，1399，排除

银欣 CS380

发布有些年头了，兼容 ATX 主板，塑料盘架，黄鱼400块，京东700块

银欣 CS382

最终选用了这款，兼容 mATX 主板，塑料盘架，京东899，单纯觉得看着比 CS380 顺眼就买了。

电源

电源没啥好说的，海韵和振华的十年质保系列看哪个便宜买哪个就好了。不过离谱的是，刚好赶上振华打折，750W比650W便宜，那就买个750W好了（不过说到底，这套配置哪怕硬盘插满可能连 200W 都到不了吧）

顺带说一下振华的新版电源，之前买HG850的时候，他的模组线有送个布袋，但是现在这个新版750W没了，不过附带的新版模组线，比以前的线软了很多很多，好插多了。

装机

很普通的装机，看我博客的人应该不需要看装机过程，很好装的机箱

MSI B760M 刀锋钛这张主板自带 6SATA，把芯片组自带的 SATA 接口全部引出。并且选择 MSI 的主板有个好处, BIOS 里面就可以直接把 RGB 灯光彻底关闭

值得说的一点就是，硬盘笼上的 SATA/SAS 接口是不兼容右向弯头线材的

以及盘架是类似群晖那种，我并不喜欢，建议直接兼容戴尔的服务器盘架算了，不过相比群晖，给了一个螺丝孔加固

DELL 的 H730 卡在更新最新的固件之后可以直接在 BIOS 里面更改为 HBA 卡模式, TrueNAS 推荐使用 HBA 卡模式, 由 ZFS 直接控制硬盘, 如果是 OMV 之类或者其他 btrfs 的系统, 这里还是建议打开硬件 RAID

不过说实话之前那台 NAS 虽然用的是 TrueNAS 但是其用了 Intel RAID, 然后在 ZFS 里面直接选择条带模式。

其实用更便宜的 DELL H330 HBA 卡就行了, 用 H730 主要是因为这张卡现在可以设置为, 在非 RAID 模式下也使用 DDR Cache

用 storcli 查看, H730 工作在 HBA 模式下的温度只有 42 度

机箱前面板，我到手才知道，这个箱子不仅有一个标准的光驱位，还有个超薄光驱位

UPS

由于我现在住的公寓非常逆天，电费没了之后，不会给任何提示就断电，所以一台 UPS 还是很有必要的，地铁一小时按群友价去收了一台全新的 APC BK650M2-CH

在 TrueNAS 中选好驱动即可使用

装完后剩余槽位与后续改进

3.5盘位 1 个, 该盘位为内置盘位，没有背板，用SATA线直接连接
薄光驱位 1 个, 考虑后续真的放个光驱进去
厚光驱位 1 个, 考虑后面买个热插拔 2.5 硬盘拓展笼子或者 E1.S 笼子
2.5英寸盘位 2 个, 来点 U2 大船
主板，迟早要把这个 ITX 板子卖了换个大板子

附录

配件价格表

类型	名称	数量	来源	总价(CNY)
机箱	银欣 CS382	1	京东	899
电源	振华 LEADEX III GOLD 750W	1	京东	659
机械硬盘	WD HC530	4	上台NAS继承	0
机械硬盘	东芝 MG08	4	淘宝	3356
M2 SSD (Cache)	PM981a 1T	1	上台NAS继承	0
M2 SSD (OS)	SN750 500G	1	上台NAS继承	0
RAID 卡	DELL H730	1	咸鱼	279
SAS 线	安费诺一分四服务器拆机	2	咸鱼	38.8
主板	MSI B760M 刀锋钛	1	闲鱼	719
CPU	i3 12100	1	黄鱼	499
内存	阿斯加特 16G 7000Mhz DDR5	2	上台NAS继承	0
散热器	AXP90x53	1	上台NAS继承	0
网卡	华为 SP310	1	上台NAS继承	0
UPS	APC BK650M2-CH	1	杭州本地群友	299
总价				6748.8

红米 AX6000 刷入 OpenWRT 和 Uboot

2023-10-18 20:30:49

今日 OpenWRT23.05 正式版终于发了，MT7986 和 MT7981 系列芯片终于有 OP 的正式版支持了，于是就海鲜市场三百大洋收了一台 Redmi AX6000 应该是最便宜的 MT7986 路由器了（以及还是 openwrt.org 上文档最详细的一款 MT7986 路由器）

打开原厂固件的SSH

降级（如果您准备直接TTL刷可以不看这里）

首先先要将路由器降级到 1.0.48 版本固件在小米的升级界面可以直接选择旧版固件降级，然后系统会告诉你禁止降级，此时看到浏览器上方链接有个 downgrade= 如果后面的数字是 0 则改成 1，是 1（见于 1.0.64 版本固件）则改成 2

打开调试模式

进入 WebUI，登陆后看到的 URL 类似于

1

http://你的路由器IP/cgi-bin/luci/;stok={token}/后面一堆东西

然后将链接改成

1

http://你的路由器IP/cgi-bin/luci/;stok={token}/api/misystem/set_sys_time?timezone=%20%27%20%3B%20echo%20pVoAAA%3D%3D%20%7C%20base64%20-d%20%7C%20mtd%20write%20-%20crash%20%3B%20

这样将会在路由器中执行 echo pVoAAA== | base64 -d | mtd write - crash，然后使用

1

http://192.168.31.1/cgi-bin/luci/;stok={token}/api/misystem/set_sys_time?timezone=%20%27%20%3b%20reboot%20%3b%20

来重启路由器

修改 Bdata

重新登陆路由器 WebUI 此时 token 有变化，记得不要使用之前的链接操作

1

http://你的路由器IP/cgi-bin/luci/;stok={token}/api/misystem/set_sys_time?timezone=%20%27%20%3B%20bdata%20set%20telnet_en%3D1%20%3B%20bdata%20set%20ssh_en%3D1%20%3B%20bdata%20commit%20%3B%20

这条在路由器中执行 bdata set telnet_en=1 ; bdata set ssh_en=1 ; bdata commit

然后使用

1

http://192.168.31.1/cgi-bin/luci/;stok={token}/api/misystem/set_sys_time?timezone=%20%27%20%3b%20reboot%20%3b%20

来重启路由器

接着就可以 telnet 连接路由器了

打开 SSH

首先 telnet 连接到路由器，看到经典的 ARE U OK 彩蛋

然后用 vi 删除 /etc/init.d/dropbear 中 135 行到 137 行，其中内容是

1
2
3



if [ "$flg_ssh" != "1" -o "$channel" = "release" ]; then        
  return 0                                                           
fi

然后使用 /etc/init.d/dropbear start 来启动 dropbear 服务

接着用 passwd 来设置 root 账户的密码后就可以用SSH连接到路由器啦~

安装原厂分区的 OpenWRT

设置启动分区

首先我们使用 cat /proc/mtd 来查看原厂分区长什么样子

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13



root@XiaoQiang:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 08000000 00020000 "spi0.1"
mtd1: 00100000 00020000 "BL2"
mtd2: 00040000 00020000 "Nvram"
mtd3: 00040000 00020000 "Bdata"
mtd4: 00200000 00020000 "Factory"
mtd5: 00200000 00020000 "FIP"
mtd6: 00040000 00020000 "crash"
mtd7: 00040000 00020000 "crash_log"
mtd8: 01e00000 00020000 "ubi"
mtd9: 01e00000 00020000 "ubi1"
mtd10: 03200000 00020000 "overlay"

有两个启动分区，类似于 Android 的 AB 分区

然后使用 cat /proc/cmdline 来查看当前的启动分区，得到类似以下结果

1
2

root@XiaoQiang:~# cat /proc/cmdline
console=ttyS0,115200n1 loglevel=8 firmware=1 factory_mode=1 uart_en=1

如果 firmware=1 当前启动分区为 ubi1，如果 firmware=0 ，当前启动分区为 ubi

以我手上这台 firmware=1 为例，设置下一次的启动分区为 ubi 也就是 mtd8

1
2
3
4
5
6
7
8



root@XiaoQiang:~# nvram set boot_wait=on
root@XiaoQiang:~# nvram set uart_en=1
root@XiaoQiang:~# nvram set flag_boot_rootfs=0
root@XiaoQiang:~# nvram set flag_last_success=0
root@XiaoQiang:~# nvram set flag_boot_success=1
root@XiaoQiang:~# nvram set flag_try_sys1_failed=0
root@XiaoQiang:~# nvram set flag_try_sys2_failed=0
root@XiaoQiang:~# nvram commit

刷入 initramfs

然后为路由器刷入 initramfs 后重启，我这里为了确保不受到国际互联网连接的影响，直接在本机起了一个 Nginx，互联网连接好的话也可以直接 wget op 的官方源

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13



root@XiaoQiang:/tmp# wget http://本机IP/AX6000/openwrt-23.05.0-mediatek-filogic-xiaomi_redmi-router-ax6000-stock-initramfs-factory.ubi
Connecting to 本机IP (本机IP:80)
openwrt-23.05.0-medi 100% |*********************************************************************************************|  8320k  0:00:00 ETA
root@XiaoQiang:/tmp# ubiformat /dev/mtd8 -y -f /tmp/openwrt-23.05.0-mediatek-filogic-xiaomi_redmi-router-ax6000-stock-initramfs-factory.ubi 
ubiformat: mtd8 (nand), size 31457280 bytes (30.0 MiB), 240 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 239 -- 100 % complete  
ubiformat: 240 eraseblocks have valid erase counter, mean value is 0
ubiformat: flashing eraseblock 64 -- 100 % complete  
ubiformat: formatting eraseblock 239 -- 100 % complete  
root@XiaoQiang:/tmp# reboot
root@XiaoQiang:/tmp# Connection closing...Socket close.

Connection closed by foreign host.

其实这一步之后就可以直接跳到 uboot 然后刷入 ubootmod 固件，但是这样风险比较高，如果想这样做的话，这里直接刷入 ubootmod-initramfs-factory.ubi 固件然后直接跳到下一步

设置 uboot-env

这里用于设置总是于 system 0 启动

1
2
3
4
5
6
7
8



fw_setenv boot_wait on
fw_setenv uart_en 1
fw_setenv flag_boot_rootfs 0
fw_setenv flag_last_success 1
fw_setenv flag_boot_success 1
fw_setenv flag_try_sys1_failed 8
fw_setenv flag_try_sys2_failed 8
fw_setenv mtdparts "nmbm0:1024k(bl2),256k(Nvram),256k(Bdata),2048k(factory),2048k(fip),256k(crash),256k(crash_log),30720k(ubi),30720k(ubi1),51200k(overlay)"

然后随意使用 WebUI 或者是 sysupgrade 指令安装 OpenWRT

这一步做完当 AP 什么的就已经可以用了，如果你要在上面安装 114514 个软件或者只是觉得官方分区傻逼，想来点开源的 Openwrt U-boot 的话可以接着往下看

安装 ubootmod 分区的 OpenWRT

备份

可以用 WebUI 的备份或者 cat 后 ZMODEM 传输

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21



root@OpenWrt:~# opkg update
# 这里太长略过
root@OpenWrt:~# opkg install lrzsz
Installing lrzsz (0.12.21-1) to root...
Downloading https://downloads.openwrt.org/releases/23.05.0/packages/aarch64_cortex-a53/packages/lrzsz_0.12.21-1_aarch64_cortex-a53.ipk
Configuring lrzsz.
root@OpenWrt:~# cat /dev/mtdblock0 > /tmp/BL2.bin
root@OpenWrt:~# sz /tmp/BL2.bin 

root@OpenWrt:~# cat /dev/mtdblock1 > /tmp/Nvram.bin
root@OpenWrt:~# sz /tmp/Nvram.bin 
rz
root@OpenWrt:~# cat /dev/mtdblock2 > /tmp/Bdata.bin
root@OpenWrt:~# sz /tmp/Bdata.bin 

root@OpenWrt:~# cat /dev/mtdblock3 > /tmp/Factory.bin
root@OpenWrt:~# sz /tmp/Factory.bin 
rz
root@OpenWrt:~# cat /dev/mtdblock4 > /tmp/FIP.bin
root@OpenWrt:~# sz /tmp/FIP.bin 
rz

查看当前分区（非必须，但是保险起见看一眼）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11



root@OpenWrt:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "BL2"
mtd1: 00040000 00020000 "Nvram"
mtd2: 00040000 00020000 "Bdata"
mtd3: 00200000 00020000 "Factory"
mtd4: 00200000 00020000 "FIP"
mtd5: 00040000 00020000 "crash"
mtd6: 00040000 00020000 "crash_log"
mtd7: 01e00000 00020000 "ubi_kernel"
mtd8: 05000000 00020000 "ubi"

刷入 ubootmod initramfs

依旧是本地起的 Nginx

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12



root@OpenWrt:~# wget http://本机IP/AX6000/openwrt-23.05.0-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-initramfs-factory.ubi
Downloading 'http://本机IP/AX6000/openwrt-23.05.0-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-initramfs-factory.ubi'
Connecting to 本机IP:80
Writing to 'openwrt-23.05.0-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-initramfs-factory.ubi'
openwrt-23.05.0-medi 100% |*******************************|  8320k  0:00:00 ETA
Download completed (8519680 bytes)
root@OpenWrt:~# ubiformat /dev/mtd7 -y -f ./openwrt-23.05.0-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-initramfs-factory.ubi 
ubiformat: mtd7 (nand), size 31457280 bytes (30.0 MiB), 240 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 239 -- 100 % complete  
ubiformat: 240 eraseblocks have valid erase counter, mean value is 2
ubiformat: flashing eraseblock 64 -- 100 % complete  
ubiformat: formatting eraseblock 239 -- 100 % complete  

重启

再次查看当前分区（非必须，但是保险起见再看一眼）

1
2
3
4
5
6
7
8



root@OpenWrt:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "BL2"
mtd1: 00040000 00020000 "Nvram"
mtd2: 00040000 00020000 "Bdata"
mtd3: 00200000 00020000 "Factory"
mtd4: 00200000 00020000 "FIP"
mtd5: 07a80000 00020000 "ubi"

修改分区

安装并加载 kmod-mtd-rw 内核模块

1
2
3
4
5
6



root@OpenWrt:~# opkg update && opkg install kmod-mtd-rw
# 太长略过 
Installing kmod-mtd-rw (5.15.134+git-20160214-2) to root...
Downloading https://downloads.openwrt.org/releases/23.05.0/targets/mediatek/filogic/packages/kmod-mtd-rw_5.15.134%2bgit-20160214-2_aarch64_cortex-a53.ipk
Configuring kmod-mtd-rw.
root@OpenWrt:~# insmod /lib/modules/$(uname -r)/mtd-rw.ko i_want_a_brick=1

删除所有的崩溃转储文件以防止 OpenWRT Uboot 启动到恢复模式

1

rm -f /sys/fs/pstore/*

格式化 ubi 并且创建新的 uboot-env 分区

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17



root@OpenWrt:~# ubidetach -p /dev/mtd5; ubiformat /dev/mtd5 -y; ubiattach -p /dev/mtd5
ubidetach: error!: cannot detach "/dev/mtd5"
           error 19 (No such device)
ubiformat: mtd5 (nand), size 128450560 bytes (122.5 MiB), 980 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 979 -- 100 % complete  
ubiformat: 880 eraseblocks have valid erase counter, mean value is 1
ubiformat: 96 eraseblocks are supposedly empty
ubiformat: warning!: 4 of 980 eraseblocks contain non-UBI data
ubiformat: warning!: only 880 of 980 eraseblocks have valid erase counter
ubiformat: mean erase counter 1 will be used for the rest of eraseblock
ubiformat: use erase counter 1 for all eraseblocks
ubiformat: formatting eraseblock 979 -- 100 % complete  
UBI device number 0, total 980 LEBs (124436480 bytes, 118.6 MiB), available 954 LEBs (121135104 bytes, 115.5 MiB), LEB size 126976 bytes (124.0 KiB)
root@OpenWrt:~# ubimkvol /dev/ubi0 -n 0 -N ubootenv -s 128KiB
Volume ID 0, size 2 LEBs (253952 bytes, 248.0 KiB), LEB size 126976 bytes (124.0 KiB), dynamic, name "ubootenv", alignment 1
root@OpenWrt:~# ubimkvol /dev/ubi0 -n 1 -N ubootenv2 -s 128KiB
Volume ID 1, size 2 LEBs (253952 bytes, 248.0 KiB), LEB size 126976 bytes (124.0 KiB), dynamic, name "ubootenv2", alignment 1

创建 OpenWrt U-Boot 的 NAND 恢复模式分区并刷入 ubootmod-initramfs-recovery.itb

这一步可选，不做也有 tftp 恢复模式可以用，可用空间也大一点

1
2
3
4
5
6
7
8
9



root@OpenWrt:~# ubimkvol /dev/ubi0 -n 2 -N recovery -s 10MiB
Volume ID 2, size 83 LEBs (10539008 bytes, 10.0 MiB), LEB size 126976 bytes (124.0 KiB), dynamic, name "recovery", alignment 1
root@OpenWrt:~# wget http://本机IP/AX6000/openwrt-23.05.0-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-initramfs-recovery.itb
Downloading 'http://本机IP/AX6000/openwrt-23.05.0-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-initramfs-recovery.itb'
Connecting to 本机IP:80
Writing to 'openwrt-23.05.0-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-initramfs-recovery.itb'
openwrt-23.05.0-medi 100% |*******************************|  7104k  0:00:00 ETA
Download completed (7274496 bytes)
root@OpenWrt:~# ubiupdatevol /dev/ubi0_2 ./openwrt-23.05.0-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-initramfs-recovery.itb 

刷入 OpenWRT U-boot

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20



root@OpenWrt:~# wget http://本机IP/AX6000/openwrt-23.05.0-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-preloader.bin
Downloading 'http://本机IP/AX6000/openwrt-23.05.0-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-preloader.bin'
Connecting to 本机IP:80
Writing to 'openwrt-23.05.0-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-preloader.bin'
openwrt-23.05.0-medi 100% |*******************************|   200k  0:00:00 ETA
Download completed (205560 bytes)
root@OpenWrt:~# mtd write ./openwrt-23.05.0-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-preloader.bin BL2
Unlocking BL2 ...

Writing from ./openwrt-23.05.0-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-preloader.bin to BL2 ...     
root@OpenWrt:~# wget http://本机IP/AX6000/openwrt-23.05.0-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-bl31-uboot.fip
Downloading 'http://本机IP/AX6000/openwrt-23.05.0-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-bl31-uboot.fip'
Connecting to 本机IP:80
Writing to 'openwrt-23.05.0-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-bl31-uboot.fip'
openwrt-23.05.0-medi 100% |*******************************|   718k  0:00:00 ETA
Download completed (735409 bytes)
root@OpenWrt:~# mtd write ./openwrt-23.05.0-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-bl31-uboot.fip FIP
Unlocking FIP ...

Writing from ./openwrt-23.05.0-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-bl31-uboot.fip to FIP ...     

最后，用 WebUI 或者 sysupgrade 指令刷入 ubootmod-squashfs-sysupgrade 固件即可

解决 RouterOSv7 中的 PMTU 黑洞问题

2023-07-30 19:40:38

当我刚刚用 RB5009 替换掉之前的老 E3 后并配好了 IPv6

结果大概一小时后，室友突然闯进了我的房间，用我的电脑测试打开了 mail.qq.com

恐怖故事就此发生，我的电脑对此响应缓慢，而室友的电脑直接就无法打开

试了一下让猫猫头软件启用全局模式之后，世界又好了起来

我的第一反应是：鹅炸了？

那显然不是……

第二反应是 DNS 的问题，解析到了神必目标，遂把室友电脑的 DNS 改到 114

结果没用，不是这个原因（要不然也不会有这篇了……）

接着试了一下 ping mail.qq.com 发现解析到了IPv6地址，遂反应过来，是不是 PMTU 黑洞了

赶紧打开 http://icmpcheckv6.popcount.org/ 来测一下，结果全绿

不过还是死马当成活马医了一下（主要是有点懒的监看一下流量，抓包看一眼）

1

/ipv6 firewall mangle add chain=forward out-interface=pppoe-out1 protocol=tcp tcp-flags=syn action=change-mss new-mss=clamp-to-pmtu

结果……结果真的活了！

问了下群友

ReiAC修改