OpenWrt (LEDE) 编译记录

月初的时候组建了一台 All-in-One，想在里面装一台软路由，于是开始了漫漫选型与试错之旅。尝试了 OpenWrt 官方 21、22 版本，恩山论坛网友修改过的两个版本、OPNsense、LEDE 自动编译版本，最终选择了自编译 lean 发布的 LEDE。

踩坑史

下面简要说明一下选择的原因和遇到的问题。

• 官方 OpenWrt 发行版 官方的发行版最为精简，个人觉得除了插件需要安装外，很好用、放心，实测可以跑到最大带宽。主要问题：

  1. 安装完后默认可用空间大小不到 100M，如果需要安装 smartdns、AdGuardHome 及其他网络插件，将导致可用空间非常有限，并出现重启系统丢失的情况。
  2. 在安装一些网络插件时，由于系统版本过新/旧，导致 opkg 报错提示找不到依赖 libubus20220228 （openwrt 22 默认带 202206 的版本，而 openwrt 21 带有 2021 的版本，此时软件源中移除了 20220228 版本）。
  3. 在使用一些网络插件时，不知道是系统还是插件原因， dns 相关设置有严重 bug 导致无法使用。

  另外还有一个小坑：如果给软路由分配了多网卡，那么在你调整网卡后，也需要适当修改一下对应网卡的防火墙区域。如果没有正确地配置 LAN 和 WAN 防火墙区域，将导致 LAN 口客户端无法访问网络。

• 网友发布版本 这一部分中我使用过 koolshare 和 lusty 编译的版本。个人感觉问题如下：

  1. 由于不支持定制，两个版本均存在很多不需要的功能。作为软路由系统，界面略有花哨，尤其是 koolshare 使用的橙色+黑色主题，使用起来不方便。当然，这一点属于个人喜好。
  2. lusty 版本无法跑满带宽。
  3. lusty 版本上面的 l2tp 在 windows 10 下可以正常连接，但 Android 下遇到了困难。可能是我配置问题。

• OPNsense OPNsense 是一款基于 FreeBSD 内核的企业级防火墙系统。自己对 FreeBSD 简洁、低占用的印象很好，加之曾经使用过 pfSense, 在网上比较了 pfSense 和 OPNsense 之后选择了它。其优点是作为企业级系统，在“计算机网络学习”这一角度看功能全面，甚至有一些第三方软件（如 iperf3、speedtest）的 Web UI 集成，但缺点也较为明显，不支持一些中国特色的网络工具。

  OPNsense 总体资源占用比 OpenWrt 略大：CPU 占用在 30% 左右，内存占用至少在 300M，开启 IDS 后内存占用逼近 1G。相比之下，OpenWrt 内存占用在 100M 左右，CPU 使用率也很低。我比较喜欢的是它的防火墙支持实时预览 ACCEPT 和 DROP 的包的概要，有利于快速调整防火墙设置。尽管如此，配置它的防火墙仍然常让人摸不着头脑。

选择 LEDE

LEDE 是国人 lean 基于 OpenWrt 开发的、最后又合并到 OpenWrt 主线的版本，现在统一使用 OpenWrt 的名称。国内很多网友生成的固件都是基于它的代码制作的，因而它也最接近原生。我先开始使用了 LEDE 仓库 Release 的版本，感觉这就是我理想的 OpenWrt 发行版！但该版本缺少 IPv6 支持，后来便起了自己编译的念头。

编译步骤

源仓库 中有着完整的编译说明，在这一过程中只要网络通常，不大会出现莫名其妙的问题。lean 使用的是 Debian/Ubuntu，而我是在 Manjaro 上编译的，因此需要安装相关编译环境（issue 2309）：

yay -S openwrt-devel

接着可以按照官方的说明，克隆代码：

git clone https://github.com/coolsnowwolf/lede
cd lede

（可选）注意，如果需要集成一些官方源中没有的软件，克隆仓库后应当修改根目录下的 feeds.conf.default，在其后添加一行：

src-git helloworld https://github.com/fw876/helloworld

拉取软件源并配置：

./scripts/feeds update -a
./scripts/feeds install -a
make menuconfig

（强烈建议）（issue 3797）如果需要完整的 IPv6 支持，请在 make menuconfig 时，选择 Extra packages —> ipv6helper，此时下面几项也会自动选择上：

• Network —> odhcp6c
• Network —> odhcpd-ipv6only
• LuCI —> Protocols —> luci-proto-ipv6
• LuCI —> Protocols —> luci-proto-ppp

接着就可以编译了：

make download -j8
make V=s -j1

官方编译说明上建议第一次编译时使用单线程（即 -j1），我在编译时直接使用了全部 16 个核心，好像问题也不大。 download 过程受网络影响较大，编译过程在我的机器上花费了约半小时，二次编译时只需 3 分钟左右。

导入 PVE

将 bin/targets/x86/64/openwrt-x86-64-generic-squashfs-combined-efi.img 上传到 PVE 中，使用 importdisk 导入磁盘即可，存储名称一般为 local-zfs 或 local-lvm：

qm importdisk 虚拟机号 /var/lib/vz/template/iso/openwrt-x86-64-generic-squashfs-combined-efi.img 存储名称

和其他编译版本一样，默认用户名/密码为 root/password, IP 地址 192.168.1.1, 可在 /etc/config/network 中修改。

（建议）如果官方软件源不能满足自己的要求，可以在 feeds 设置中添加一个第三方软件源：src/gz openwrt_kiddin9 https://op.supes.top/packages/x86_64。由于该源为个人用户创立，使用时需要删除 option check_signature 以关闭签名验证。

后话

偶然发现在 2019 年底的时候，lean 发了一个 issue，其中是这样写的：

终归到底，这个又是一个失败的项目而已 #2648

我一直想象的那种人人为我，我为人人，大家一起来维护一个项目的景象始终没有出现，也没有出现的迹象。

维护这个项目的过程中，主动分享的同学并不多。很多来汇报问题的人是以一种小白求大大免费解决问题，解决完就走人的方式来的。

然而既不愿提供足够的信息，截图日志什么都没有，也不愿写一些自己尝试的过程供后人参考。

issues 那边，一堆随随便便的一句话问题，却想着别人认认真真的去帮他分析解决的，比比皆是。

退一步来说，就算有些 issue 是很简单的问题，5000 多个 fork ，却也没有多少人愿意回复下，就好像这个完全就是作者一个人服务所有人的项目一样。

更别提pulls 区那边的一堆垃圾 yml 了，关都关不过来。

互帮互助的气氛就是搞不起来。对比下国外的社区差好远。

国内的开源环境到底是什么样呢？他们使用现成的开源的成果，却很少有人遵守开源协议。

更有甚者，毫无贡献、拿来就用，然后宣传开源后就属于全人类的了，然后说是自己的成果（即使不是公开说出来，也是暗示性的影响。为数不多的人遵守 GPL ，更别提哪怕在 Credit 注明一下来源的人），甚至反骂开源的作者。

这个项目已经让我觉得越来越无趣，罢了吧。

庆幸作者至今仍然坚持了下来。看到这么好的开源项目的作者被逼到如此境地，不禁有些难过。其实，专业刷路由器固件的同学恐怕也只是一少部分，更多的人在实现功能后便“撤离”也无可厚非。在这个 issue 下，一些评论建议区分专业用户和非专业用户，便是一个不错的思路。

其实 lede 项目本身，乃至这个仓库，知道的人还是有限的。仅浏览一下恩山上的帖子，红火的往往是各路“大神”基于 lede 所做的固件，而甚至有些还对用户收费——这也难怪 lean 会生气。

感叹自己错过了手机和路由器刷机最火的时候，谨纪念第一次编译路由器固件。