PVE安装openwrt后, lan口DHCP服务未工作, 设备无法获取IP
问题描述: 在PVE安装Openwrt后, DHCP服务器未工作, 但是管理界面明确配置了运行且在运行中, 到底有没有运行呢? 需要排查
通过命令行，可以清楚地看到 DHCP 服务到底是在“偷懒”，还是在“空转”。
请打开 OpenWrt 的 终端 (Console)，依次执行以下 3 个步骤进行诊断：
检查DHCP
检查 DHCP 进程活着吗？(查看端口)
DHCP 服务必须监听 UDP 67 端口。如果没人监听这个端口，说明服务挂了。
输入命令：
netstat -ulpn | grep 67
分析结果：
-
正常情况：会看到类似下面的一行，有
dnsmasq字样。udp 0 0 0.0.0.0:67 0.0.0.0:* 2854/dnsmasq -
异常情况：没有任何输出。
- 这意味着 DHCP 服务根本没启动！可能配置文件写错了导致服务崩溃。
查看实时日志
可以开启实时日志监控，然后在电脑上操作“获取 IP”，看看 OpenWrt 到底收到了没有，以及它为什么不回话。
-
输入监控命令：
logread -f | grep -i dhcp(这条命令会卡住不动，等待新的日志产生)
-
触发动作：
现在去操作笔记本电脑，打开 CMD 输入：
ipconfig /renew -
观察 OpenWrt 屏幕上的输出：
-
现象 A：完全静默，屏幕一行字都没跳出来。
-
结论：OpenWrt 根本没收到请求。
-
原因：虽然物理通了，但包被 PVE 防火墙、网桥 STP 或者 VirtIO 校验和错误给拦截了，没传到
dnsmasq手里。
-
-
现象 B：有日志，显示
DHCPDISCOVER(br-lan) ... ignored-
结论：收到了，但被忽略了。
-
原因：就是之前提到的 “强制 (Force)” 没开，或者 IP 地址池不够了。
-
-
现象 C：有日志，显示
DHCPDISCOVER ...和DHCPOFFER ...-
结论：OpenWrt 说“我回话了啊！”。
-
原因：OpenWrt 发出了 Offer，但包在回得路上被电脑拒收了（典型的 VirtIO 校验和错误）。
-
按
Ctrl + C可以退出日志监控模式。 -
检查配置文件 (确认“强制”是否生效)
有时候网页上勾选了，后台文件没变。
输入命令：
cat /etc/config/dhcp
找到 config dhcp 'lan' 这一段：
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv6 'server'
option ra 'server'
list ra_flags 'managed-config'
list ra_flags 'other-config'
option force '1' <--- 关键看有没有这一行！
分析结果：
-
如果有
option force '1'：说明强制模式已开启，配置没问题。 -
如果没有这一行，或者值为 '0'：说明强制没开。必须加上去，或者去网页上再保存一次。
建议操作顺序
-
先运行
logread -f | grep -i dhcp。 -
电脑运行
ipconfig /renew。
修复DHCP
netstat 输出显示：没有任何进程监听 UDP 67 端口。
-
正常情况：必须有一行显示
0.0.0.0:67 ... dnsmasq。这是 DHCP 服务员在窗口等待客户（电脑）喊话。 -
当前的情况：DHCP 服务（Dnsmasq）挂了，或者根本没启动！
怪不得之前换网卡、抓包、改防火墙都没用。因为 OpenWrt 的“DHCP 部门”直接关门大吉了，电脑喊破喉咙也没人理。
修复配置文件
造成服务挂掉可能是配置文件有语法错误。
查看报错信息
需要看看它为什么起不来。请在终端输入：
/etc/init.d/dnsmasq restart
观察输出：
- 如果显示
syntax error(语法错误) 或者failed，说明配置文件改坏了。
检查配置文件语法
输入这个命令，让 dnsmasq 自己检查一下配置有没有错：
dnsmasq --test
- 如果报错，它会告诉错在哪一行。
重启并验证
修改改回原样后，再次尝试启动：
/etc/init.d/dnsmasq enable
/etc/init.d/dnsmasq restart
验证是否复活：
再次输入刚才的命令：
netstat -ulpn | grep 67
只要看到类似下面这行：
udp 0 0 0.0.0.0:67 0.0.0.0:* 2854/dnsmasq
那就是通了
重置 DHCP 配置
为什么 DHCP 还是不启动？
既然脚本没坏，日志显示 dnsmasq 也启动了（但只加载了 DNS，没加载 DHCP），说明问题出在“生成配置”的环节。
简单说：启动脚本运行了，但它在“检查网络环境”后，决定不生成 DHCP 相关的配置参数（比如 dhcp-range）。所以 dnsmasq 以为只需要它做 DNS 服务器，不需要发 IP。
最大嫌疑：/etc/config/dhcp 配置文件可能有逻辑冲突或隐藏的格式错误。
重置 DHCP 配置
用 OpenWrt 标准的 UCI 命令把 LAN 口的 DHCP 配置删除并重建。这能清除所有乱七八糟的错误设置。
请在 OpenWrt 控制台依次执行以下命令（直接复制粘贴）：
# 1. 删除现有的 lan DHCP 配置 (防止残留错误)
uci delete dhcp.lan
# 2. 重新创建一个干净的 lan DHCP 配置
uci set dhcp.lan=dhcp
uci set dhcp.lan.interface='lan'
uci set dhcp.lan.start='100'
uci set dhcp.lan.limit='150'
uci set dhcp.lan.leasetime='12h'
# 3. 开启最关键的“强制模式” (解决虚拟化不发包的核心)
uci set dhcp.lan.force='1'
# 4. 提交保存 除非手动去删除它，否则无论断电、重启多少次，这个配置都会一直存在。
uci commit dhcp
# 5. 重启服务
/etc/init.d/dnsmasq restart
验证是否成功
执行完上面一套组合拳后，马上输入下面这个命令检查：
netstat -ulpn | grep 67
-
如果看到了 0.0.0.0:67 ... dnsmasq：
恭喜！通了！ 现在电脑和 AP 下的所有设备应该都能立刻获取到 IP 了。
-
如果还是空的：
请执行 cat /var/etc/dnsmasq.conf.* 并截图给我，我要看看系统到底生成了什么鬼配置。
然后[[20251118-抓包检测DHCP服务器是否开启]] 可以再测试一下DHCP
![[2325b4979db304da09614bba9fb0dc1e_MD5.jpg]]
原因分析
大概原因：
PVE运行Openwrt，默认旁路由模式，当时另一个网口被PVE休眠了，导致DHCP服务初始化时只做了DNS。
正确做法：联想来酷Mini主机的螃蟹网卡需要全部启动，禁止休眠，然后再创建网卡网桥，安装PVE。
根本原因是一个“连锁反应”，主要由 虚拟化环境 (PVE) 和 DHCP 服务 (Dnsmasq) 的保守策略 共同导致：
-
核心原因 A：DHCP 服务“太怂了” (没开强制模式)
-
在物理机上，网线一插，状态就是确定的。但在 PVE 虚拟机里，网桥 (
vmbr0) 的状态在启动瞬间可能还没准备好，或者存在微小的波动。 -
OpenWrt 里的 DHCP 服务检测到环境“不够完美”或者“好像有干扰”，为了防止造成网络风暴，它选择了自我阉割（不启动 DHCP 功能，只做 DNS）。
-
证据：这就是为什么之前用
netstat查看时，67 端口是关闭的。 -
修复：刚才输入的
uci set dhcp.lan.force='1'，就是拿着枪指着它的头说：“别管环境怎么样本，强制给我发 IP！”
-
-
辅助原因 B：配置文件的“隐形”错误
-
虽然觉得“什么都没改”，但在之前的折腾过程中（比如试图添加 ipv6，或者修改 lan 口设置），
/etc/config/dhcp文件里可能残留了一些逻辑冲突的脏配置。- 修复：刚才执行了
uci delete dhcp.lan，相当于把旧房子的烂地基全挖了，重新建了一个最标准的配置。
- 修复：刚才执行了
-
-
iStoreOS (基于 OpenWrt) 是一个非常优秀的系统。但是，绝大多数 OpenWrt 固件默认是为 硬路由（物理机） 设计的。当把它搬到 PVE 虚拟机 里时，它对“网口状态”的判断标准就显得太严格了。
-
结论：镜像没问题，只是在虚拟化环境下，“开启 DHCP 强制模式”是必须做的标准动作，不做就容易出现这种“时通时不通”的怪病。
本文来自博客园，作者：舟清颺，转载请注明原文链接：https://www.cnblogs.com/zqingyang/p/19242727
浙公网安备 33010602011771号