如何在 PS 模式下检测站内 AP 重启导致的解除关联
我正在为无线卡编写一个相当低级的驱动程序，虽然大多数规范都相当简单，但我还没有解决一个问题：
如果我的工作站处于省电模式及其接收器在 DTIM 帧之间关闭较长一段时间（例如 10 秒），并且接入点同时重新启动，因此我的关联丢失，我如何检测到这一点？
我知道最常见的情况是同步完全丢失，以至于我会错过一些信标，然后简单地返回 AP 搜索，但如果有幸我能看到信标，是否有一些如何找出这是同一 AP 的新“实例”？
我可以想到
- 则允许 AP 缩短 TIM 信息
- 一个更短的 TIM 字段 - 但是我相信如果没有流量等待AP 时间戳意外更改，
- 。 “下一个 DTIM 的信标数量”字段发生意外变化。
作为一个完美主义者，我想知道是否有一种完全可靠的方法来检测 AP 是否已重新启动，而不是仅仅将线索放在一起。
I'm writing a fairly low-level driver for a wireless card, and while most of the spec is fairly straightforward, I haven't wrapped my head around a single question yet:
If my station is in power-save mode and its receiver is turned off for an extended period (say, 10 seconds) between DTIM frames, and the access point is rebooted in the meantime so my association is lost, how can I detect this?
I'm aware that the most common case will be that synchronisation is lost thoroughly enough that I will miss a number of beacons and simply go back to the AP search afterwards, but if by some lucky chance I get to see beacons, is there some way to find out that this is a new "instance" of the same AP?
I can think of
- a short(er) TIM field -- however I believe APs are allowed to shorten the TIM information if no traffic is waiting
- the AP timestamp changing unexpectedly.
- the "number of beacons to next DTIM" field changing unexpectedly.
Being a perfectionist, I'd like to know if there is an entirely reliable way to detect that the AP has been rebooted, rather than just putting together clues.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我建议您查看收到的信标帧中的 TSF 并
如果它与您期望的 TSF 差异太大，您将发送 NULL 数据
帧到 AP。如果 AP 重新启动，它应该响应
取消验证帧，原因是“从以下位置收到的 2 类帧”
未经身份验证的 STA”。
I would suggest that you look at the TSF in received beacon frames and
if it differs too much from the TSF you expected you send a NULL-data
frame to the AP. If the AP was rebooted it should respond with a
deauthenticate frame with reason "Class 2 frame received from
nonauthenticated STA".
我对这个级别的无线卡没有任何了解，但我会采取实用的路线并分析 AP 的通信，直到断开连接，以找到与典型关闭序列相匹配的模式；例如，“没有更多流量，DTIM 同步突然丢失，然后 AP 公告”。
我突然想到：也许可以研究一下 Kismet 的 AP 检测和分析代码来获得一两个想法。我敢打赌其他人以前也遇到过这个问题。
干杯!
I don't have any knowledge of wireless cards at that level, but I'd take a practical route and analyze the communication from the AP just leading up to the disconnect for a pattern that matches a typical shutdown sequence; for example, "no more traffic, a sudden loss of DTIM sync, and then an AP announcement".
Off the top of my head: maybe look into Kismet's AP detection and analysis code for an idea or two. I'd bet someone else has encountered this problem before.
Cheers!