发送 DHCP REQUEST 后没有 DHCP ACK
[已解决] 我作为 DHCP 服务器的客户端手动构建 DHCP 数据包。到目前为止，我能够发送 DHCPDISCOVER 数据包并从服务器接收 DHCPOFFER 作为回报。但是，当我发送 DHCPREQUEST 时，我根本没有收到预期的 DHCPACK。
DHCPDISCOVER： http://digitalphoenix.info/uploads/so/dhcpDiscover.jpg
DHCPOFFER： http://digitalphoenix.info/uploads/so/dhcpOffer.jpg
DHCPREQUEST：http://digitalphoenix.info/uploads/so/dhcpReq.jpg
（在上面的Honeypot守护进程是192.168.0.2，DHCP服务器192.168.0.1，客户端A (192.168.0.6) 尝试探测不存在的 192.168.0.106 尝试获取“192.168.0.106”的租约）
我推断 DHCP 服务器根本不发送 ACK，因为：
1) DHCP 服务器显示 192.168.0.106 没有有效租约
2) DHCP 服务器通常会在发送 ACK 来探测可用性（已测试）之前向所请求的 IP 发送 ARP 请求（未发送 ARP 请求），
因此问题在于 DHCP 请求数据包被丢弃或拒绝...？我什至没有得到 NACK
背景：我正在编写一个蜜罐守护进程，它代表虚拟高交互蜜罐 (VM) 动态分配 IP 地址。它侦听未答复的 ARP 请求，获取目标。 IP 并尝试租用该特定目标。来自 DHCP 服务器的 IP 地址，供下一个未绑定蜜罐使用。当租约被确认后，守护进程最终向源返回一个 ARP 回复。蜜罐存在于单独的子网上，目标是逻辑上将它们放置在与主机相同的子网中。从那时起，守护进程负责绑定蜜罐的所有传出/传入流量。以太网帧 src addr 是蜜罐守护进程/主机的 MAC。然而，bootp 中指定的 MAC 是完全任意的。
编辑：刚刚注意到 UDP 校验和为空，没有注意到这一点，因为wireshark 禁用了 udp 校验和验证。有这个必要吗？ DHCPDISCOVER 没有它但还是得到了响应？即使是关于可能导致问题的小建议也将受到赞赏，谢谢大家
编辑2：更正了UDP校验和，问题仍然存在
额外信息：192.168.0.0/24租用范围2-254wireshark
捕获/ pcap：http://digitalphoenix.info/uploads/so/honeyPotCapture.pcap（与上面相同，除了假MAC和目标IP是192.168.0.109而不是xxx106）
最终编辑：已修复。我是瞎子。事实证明，当 RFC 规定不要填写时，服务器 IP 地址字段已填写。睡个好觉的作用真是令人惊奇。
[Solved]
I am manually constructing DHCP packets as a client to the DHCP server. So far I am able to send a DHCPDISCOVER packet and receive a DHCPOFFER from the server in return. However, when I send DHCPREQUEST, I don't receive the expected DHCPACK at all.
DHCPDISCOVER: http://digitalphoenix.info/uploads/so/dhcpDiscover.jpg
DHCPOFFER: http://digitalphoenix.info/uploads/so/dhcpOffer.jpg
DHCPREQUEST: http://digitalphoenix.info/uploads/so/dhcpReq.jpg
(in the above the Honeypot daemon is 192.168.0.2, DHCP server 192.168.0.1, client A (192.168.0.6) trying to probe 192.168.0.106 which doesn't exist. Attempting to acquire a lease for '192.168.0.106')
I'm inferring that the DHCP server does not send an ACK at all because:
1) the DHCP server shows no active lease for 192.168.0.106
2) the DHCP server usually sends an ARP request to the requested IP prior to sending ACKs to probe availability (tested) (no ARP req sent)
therefore the problem lies in the DHCP Request packet being dropped or rejected...? I don't even get a NACK
Background: I am writing a Honeypot daemon that dynamically allocates IP addresses on behalf of virtual high-interaction Honeypots (VM). It listens for unanswered ARP requests, takes the dest. IP and attempts to lease that specific dest. IP address from the DHCP server for the next unbound Honeypot to use. When the lease has been acknowledged, the daemon finally returns an ARP reply to the source. The Honeypots exist on a separate subnet and the goal is to logically place them within the same subnet as the host machine. From thereon, the daemon is responsible for all outgoing/incoming traffic for the bound Honeypots(s). The ethernet frame src addr is the MAC of the Honeypot daemon / host. However, the MAC specified in the bootp is completely arbitrary.
edit: just noticed the UDP checksum is empty, didn['t notice this because of wireshark disabling udp checksum validation. is this necessary? the DHCPDISCOVER didn't have it but got response anyway? Even small suggestions as to what may be causing the problem would be appreciated, thanks guys
edit2: corrected the UDP checksum, problem still exists
extra info: 192.168.0.0/24 lease range 2-254
wireshark capture / pcap: http://digitalphoenix.info/uploads/so/honeyPotCapture.pcap (same as above except the fake MAC and target IP is 192.168.0.109 instead of x.x.x.106)
FINAL EDIT: Fixed. I'm blind. Turns out the server IP addr field was filled in when RFC says not to. Amazing what a good night's sleep can do.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论