STM32网络调试避坑指南：LWIP的DHCP开了却没拿到IP？可能是HostName惹的祸

调试嵌入式网络功能时，最让人头疼的莫过于配置看起来一切正常，但设备就是拿不到IP地址。上周在调试一个STM32F407的项目时就遇到了这个问题：LWIP的DHCP功能已经开启，但设备始终无法获取IP，日志信息也不够明确。经过两天的排查，最终发现问题出在一个容易被忽略的细节——HostName的配置上。

1. DHCP协商失败的常见表象

当STM32使用LWIP协议栈并开启DHCP功能时，如果出现以下现象，很可能就是遇到了HostName相关的问题：

• 设备长时间处于"DHCP discovering..."状态，但始终无法进入"DHCP success"阶段
• 使用Wireshark抓包能看到DHCP Discover包发出，但收不到DHCP Offer响应
• 日志中没有任何错误提示，但就是无法获取IP地址
• 关闭HostName功能后，DHCP突然就能正常工作了

提示：在开始深入排查前，建议先用ping命令测试网络物理连接是否正常，并确认路由器DHCP服务已开启。

2. HostName为何会影响DHCP？

很多开发者会疑惑：HostName看起来只是个标识符，为什么会影响到IP地址的分配？这需要从DHCP协议的工作机制说起：

1. DHCP协议交互流程：

   • Discover → Offer → Request → Ack
   • 当设备发送Discover包时，会携带HostName选项（如果启用）

2. HostName的特殊性：

   • 在LWIP实现中，HostName功能依赖于netbiosns.c模块
   • 如果没有正确初始化该模块，DHCP协商可能会在协议栈内部失败

3. 常见兼容性问题：

   • 某些路由器对HostName字段有特殊要求（长度、字符集等）
   • 未初始化的HostName可能导致DHCP报文格式异常

c复制// 典型的HostName设置代码
netif_default->hostname = "STM32-123456";  // 必须在使用DHCP前设置
netbiosns_init();