知识点

这里与开启热点的设备有关，这里以安卓手机为例。来进行分析。

Android 手机热点通常用dnsmasq实现 DHCP 服务，其黑名单逻辑是：

• 先正常发送DHCP Offer（分配 IP）；

• 再通过iptables（防火墙规则）拦截黑名单设备的后续流量（包括DHCP Request和DHCP Ack）。
  因此，Offer会 “漏出”，但客户端因收不到Ack无法完成配置，只能反复发Discover。

流程

关于dhcp的正常流程可以查看以前发的2篇文章。

链接如下：

https://blog.csdn.net/qq78442761/article/details/151106959?spm=1001.2014.3001.5501https://blog.csdn.net/qq78442761/article/details/151106959?spm=1001.2014.3001.5501这里来看下，加到黑名单的情况。

这里使用手机开启热点，并把某windows机器放到黑名单后。使用Wireshark抓包如下：

从中可以看到客户端发送了大量的Discover包，但里面有时会包含Offer包，客户端收到Offer包后，就回了Request包。但没有Ack。

再次翻下，看看还有没有类似的。

现时不时会出现这种Offer包。那么为什么会有这种现象呢？

DHCP 协议的 “被动响应” 机制

DHCP Server（手机热点）的工作逻辑是 **“先响应，后验证”**：

• 客户端发送DHCP Discover（广播）后，Server 会被动接收并响应（发送DHCP Offer），因为 Server 无法提前判断 “该客户端是否在黑名单”，必须等收到 Discover 后才会去查询黑白名单。

手机热点黑名单的 “拦截阶段”

手机热点的黑名单功能，通常在 **“DHCP Offer 之后”** 才会拦截，而不是在 Discover→Offer 阶段直接阻断：

• 当客户端发送DHCP Request（请求确认 IP）时，Server 会检查 “该客户端是否在黑名单”，若在则**拒绝发送最终的DHCP Acknowledge（Ack）**（即不完成 IP 分配）。

• 但DHCP Offer的发送逻辑更 “靠前”，未被黑名单规则拦截 —— 相当于 “允许 Server 给黑名单设备‘临时提供 IP’，但不允许最终确认”。

DHCP 服务器（手机热点的 dnsmasq）对黑名单设备的 “动态抑制策略”

黑名单设备 “多发 Discover 才回一个 Offer”，是dnsmasq 的重复抑制、黑名单规则的动态匹配、硬件广播过滤和客户端重试策略共同作用的结果。核心目的是：在 “必须响应部分请求以维持协议表面流程” 的同时，通过减少Offer频率降低对热点资源的消耗，最终实现对黑名单设备的 “低效隔离”（让其始终无法完成配置，又不浪费过多服务器资源）。