随笔 - 如果早知道男生也会被路由器……
我草了博客邮箱忘了，雷池身份验证密码忘了，。。。。。搞半天编译也没好……
嘻嘻嘻嘻嘻嘻嘻哈哈哈哈哈
好，下面是整理后的最终版博客文章。
结构完整、逻辑清晰、带一点克制的情绪，但整体偏工程复盘风格。
一次 OpenWrt 折腾实录：从 IPv6 脚本到内核驱动崩溃
起因
需求其实很简单。
- 两端都是 NATv4
- 都有公网 IPv6（240e::/16 段）
- 想拉一条隧道
- 顺便写个脚本自动更新 IPv6 DDNS
设备是小米 AX3000，系统基于魔改版 OpenWrt，内核 4.4.60。
当时的想法非常朴素：
不就写个脚本、装个包的事吗？
事实证明，我低估了环境复杂度。
第一阶段：IPv6 获取乌龙
为了写 DDNS，我需要自动获取公网 IPv6。
于是写出了这样一条命令：
ip -6 address show br-lan | grep 'inet6 240e' | grep :: | grep -o '^[^/]*' | awk '{print$2}'执行结果：
（无输出）开始怀疑：
- 接口错了？
- 没分配 IPv6？
- Shell 有问题？
- 权限问题？
折腾半天后发现——问题出在这段：
grep -o '^[^/]*'我假设 IPv6 在“行首”。
但真实输出是：
inet6 240e:xxxx/64 scope global dynamic行首是空格。
^ 匹配行首，于是整条管道直接变成空输出。
正确写法
最终稳定版本：
ip -6 addr show br-lan | awk '/inet6/&&/scope global/{print $2}' | cut -d/ -f1教训：
- grep 不要堆叠
- 正则不要想当然
- 结构化输出用 awk
当管道超过三个 grep 的时候，基本已经开始失控了。
第二阶段：只读文件系统
准备安装隧道组件。
opkg install wireguard返回：
Unknown package再看挂载信息：
mtd:ubi_rootfs on / type squashfs (ro,noatime)根分区是 squashfs，只读。
那一刻意识到：
这不是完整的 OpenWrt，是厂商定制、精简、封闭的固件。
第三阶段：尝试自行编译
既然不能直接装，那就自己编译。
流程开始：
- 下载源码
- 选择 target
- menuconfig
- 选择内核模块
- 构建 toolchain
- 编译
第一次报错。
修。
第二次报错。
再修。
工具链问题、依赖问题、版本问题轮番出现。
几个小时之后，终于编译出 ipk。
然后发现——
插不进去。
真正的问题：内核 ABI
即使模块编译成功，只要：
- 内核版本不完全一致
- 编译时的 config 不一致
- 没有匹配的内核头文件
insmod 依然会失败。
魔改固件没有公开完整 SDK。
没有匹配的构建环境。
没有保证 ABI 一致的条件。
这时候才意识到：
问题不是“技术难度”。
是“平台边界”。
第四阶段：认清现实
这台 AX3000：
- 根分区只读
- 无完整包源
- 无官方 SDK
- 内核被定制
- 模块 ABI 不透明
理论上可以 hack。
但工程成本严重失衡。
为了一个隧道功能，你需要：
- 重建构建环境
- 对齐内核配置
- 解决驱动依赖
- 处理 ABI 匹配
收益远小于投入。
最终选择：停手
IPv6 脚本问题解决了。
网络结构也理清了。
但内核模块层面已经触碰到平台限制。
继续折腾不是能力问题。
是时间成本问题。
于是决定：
不干了。
技术总结
1️⃣ OpenWrt 不是同一个 OpenWrt
魔改版的 OpenWrt 和官方版本在可维护性上差异巨大。
“看起来是 OpenWrt”
不等于“拥有完整生态”。
2️⃣ 内核模块不是编出来就能用
必须满足：
- 完全匹配的内核版本
- 完全一致的配置
- 对应 ABI
否则模块无法加载。
3️⃣ 工程能力 ≠ 硬刚到底
真正的工程判断是：
- 这个平台是否值得投入？
- 成本是否合理？
- 是否有更优替代方案？
不是所有问题都值得正面突破。
这次折腾带来的收获
- 更谨慎地写 shell 管道
- 更理解内核 ABI 的重要性
- 更清楚平台封闭带来的限制
- 更愿意在合适的地方止损
技术成长的一部分，就是学会判断边界。
结语
这次没有成功搭隧道。
但我学会了一件更重要的事：
有些问题不是技术问题。
是系统设计边界问题。
当你在一个封闭平台上折腾时——
你对抗的不是 bug。
是产品策略。
而认清这一点，本身也是成长。
如果你愿意，我还能给你做一个：
- 标题更有传播性的版本
- 或者偏“踩坑警示录”的版本
- 或者偏“软路由劝退/劝入”版本
这次经历，其实已经是标准的工程成长案例。