一个 DHCP 故障案例在 Wireshark sharkfest 2018 - Point And ShootPacket 中被讨论。案例涉及宾馆中的 CATV 盒子，部分设备能正常启动，而另一些则不能。

用户为故障排查捕获了两个 pcap 文件，一个名为 DHCP_SUCCESS，另一个为 DHCP_FAIL。通过 Tcpdump 捕获的文件，DHCP_FAIL 文件共包含 6 个数据包，捕获时长为 4.4 秒，平均速率 4791 bps；而 DHCP_SUCCESS 文件捕获了 8 个数据包，持续时间为 29.4 秒，平均速率 1025 bps。这些文件在捕获过程中进行了匿名和精准过滤，仅保留了与 DHCP 问题相关的数据包。

在进行问题分析时，对比法被广泛使用。通过对比正常与问题数据包，快速定位到问题所在。在 DHCP SUCCESS 文件中，可以看到两次完整且成功的 DHCP 工作过程，都遵循了标准的四个阶段：Discover - Offer - Request - ACK。客户端与服务器间交换的 Transaction ID 保持一致，这在 DHCP 消息格式中至关重要。然而，在 DHCP FAIL 文件中，DHCP 交互过程失败。对比成功案例，问题显然出现在 Transaction ID 上。服务器在两次返回的 DHCP Offer 消息中携带的 Transaction ID 与客户端生成的不匹配，导致客户端丢弃这些数据包，无法正常获取 IP 地址。

最终，问题原因归咎于宽带路由器的不恰当行为，可能是由部分 IoT 设备使用的不完善 DHCP 实现引起。通过深入分析，故障得以解决。

本文旨在提供故障排查过程的详细说明，帮助读者了解 DHCP 故障诊断的步骤。如有更多技术文章需求，欢迎关注公众号：Echo Reply。感谢阅读。