☰

DHCP 客户端的行为

tag-icon • tag-icon networking dhcp standards
DHCP 客户端的行为

这是关于互联网协议标准的问题。

  • DCHP 客户端（Android 4.x 上的 dhcpcd-5.2.10）初始化接口
  • DHCP 客户端发送 DHCPDISCOVER 消息
  • DHCP 服务器发送 DHCPOFFER 消息
  • 然后，客户端发送一个 DHCPREQUEST 消息，该消息包含除来自 DHCPOFFER 的“您的 IP 地址”之外的“请求的 IP 地址”，并且不包含“DHCP 服务器标识符”。

我看到数据包捕获（可以用Wireshark打开）在dhcp-server设备上。

RFC 2131 规定：

The client broadcasts a DHCPREQUEST message that MUST include 
the 'server identifier' option to indicate which server 
it has selected, and that MAY include other options specifying 
desired configuration values.  
The 'requested IP address' option MUST be set to the value
of 'yiaddr' in the DHCPOFFER message from the server.

问题：DHCP 客户端的行为是否正确？标准可能已更改？

答案1

我要回答...（更多空间；）

首先要问一个问题。您是否遇到从服务器获取正确 IP 的延迟？据我所知，获取正确 IP（192.168.1.33）需要一分半钟以上。如果是这种情况，也许我们应该仔细查看请求。

我认为现在的协议是正确的。

我只过滤了 LenovoMo 和 MS-NLB-PhysServer 之间的流量。（至少我认为我这样做了；）
我使用了过滤器
((((eth) && !(bootp.hw.mac_addr == 00:bb:3a:89:67:be)) && !(bootp.hw.mac_addr == b4:98:42:d6:63:c1)) && !(bootp.hw.mac_addr == e0:69:95:74:b2:43)) && !(bootp.hw.mac_addr == 78:e4:00:9d:fd:6b)

这是我得到的（右键单击并选择“在新选项卡中打开”以获得更大版本）：

在此处输入图片描述

  • 查看客户端请求的第一个 DHCP 请求（第 1 行）192.168.1.35。

在此处输入图片描述

  • 它从服务器获取 DHCP NAK（没有正确的 IP）。
  • 客户端进入 DHCP 发现模式并发送几个数据包进行发现（应该如此）。
  • 服务器发送 DHCP 提供（也多次），我认为它提供的是 192.168.1.33。

在此处输入图片描述

  • 在第 9 行，客户端再次尝试获取 192.168.1.35使用 DHCP 请求
    （两次，为什么？也许它很固执；）（允许客户端发送多个请求）
  • 服务器再次以 DHCP NAK 响应。
  • ...
  • 这持续了一分钟。
  • ...
  • 最后在第 63 行，客户端发出一个 DHCP 请求，IP 192.168.1.33
    使用“选项：（54）DHCP 服务器标识符”（理所应当）。（见下文）

我不确定为什么需要这么长时间，但客户端发出的所有 DHCP 请求（直到第 63 行）都是请求 192.168.1.35因此请求续约同一 IP初始化-重启。

问题：DHCP 客户端的行为是否正确？标准可能已更改？

但是...我认为这个问题的答案是...
是的，这是客户端的正确行为
，并且不，标准没有改变；）


在此处输入图片描述

相关内容