Zephyr RTOS网络协议栈基础：DHCP客户端从一次产线“断网”事故说起去年冬天，某客户产线突然报障——部署了Zephyr的200多台边缘网关，在凌晨3点批量掉线。远程抓日志发现，所有设备都在DHCP续约时卡死了。更诡异的是，同样的固件在实验室跑了一周都没事。排查到最后，问题出在DHCP客户端的重传机制上。产线交换机在凌晨做了一次固件升级，导致DHCP Offer报文延迟了300ms。Zephyr默认的DHCP重传超时是4秒，但我们的应用层在收到IP后启动了一个看门狗定时器，恰好比DHCP续约的超时短了0.5秒。于是设备在续约失败后直接复位，陷入“获取IP→复位→获取IP”的死循环。这个案例让我意识到，很多开发者把DHCP客户端当成“黑盒”来用，出了问题只能抓瞎。今天这篇笔记，我们就从Zephyr的DHCP实现源码入手，把这块“黑盒”拆开看看。Zephyr DHCP客户端的架构设计Zephyr的网络协议栈基于BSD套接字模型，但DHCP客户端并没有走套接字路径——它直接操作网络缓冲区，通过L2层收发报文。这样做的好处是：在IP地址还没分配时就能发送广播报文。核心数据结构是struct dhcp_client，定义在subsys/net/lib/dhcpv4/dhcpv4_internal.h里。注意这个文件是内部头文件，应用层不要直接包含它。我见过有人从zephyr/net/dhcpv4.h里找不到结构体定义