除了侦听探测请求之外，还可以使用哪些方法来查找 802.11 wifi 设备？
我正在编写一个 Python 模块来查找附近的 WiFi 客户端设备。我当前的扫描器所做的只是侦听探测请求并记录客户端 MAC 地址。
我遇到的问题是我完全依赖设备广播探测请求来让我发现它。
我想知道是否还有其他方法来发现设备。使用此网站作为802.11 指南，我提出了以下想法：
- 发送带有通用 SSID 的广播数据包以查看客户端是否响应。例如，发送以“Netgear”作为 AP SSID 的广播，并查看是否有任何具有已知“Netgear”配置文件的客户端响应
- 发送解除关联数据包以强制已连接的客户端重新扫描电波
我尚未测试这两个想法。只是吐球。
想法？
I'm writing a Python module for finding nearby WiFi client devices. All my current scanner does is listen for Probe Requests and logs the clients MAC address.
The problem I'm having is that I'm completely reliant on the device broadcasting a probe request for me to discover it.
I'm wondering if there is any other way to discover devices. Using this site as a 802.11 guide, I've come up with the ideas:
- Send out Broadcast packets with generic SSIDs to see if clients respond. For example, sending out a broadcast with 'Netgear' as the AP SSID and see if any clients with known 'Netgear' profiles respond
- Send out disassociation packets to force already connected clients to rescan the airwaves
I haven't tested these two ideas yet. Just spit balling.
Thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为广播的想法行不通。广播流量
802.11 未得到确认，因此站点没有理由响应
对于这样的流量。唯一的方法是如果您连接到 AP
问题在哪种情况下您可以执行广播 ICMP 回显请求或
类似的东西（但你只能从以下地区的电台得到回应
相同的 ESS）。
我认为分离数据包的想法也不会起作用，因为它
必须写给车站，而你可能不知道
那个地址。
我建议只是嗅探所有流量并跟踪哪些流量
您看到的 MAC 地址。您不必依赖站探测
但你确实依赖他们有时发送一些东西（任何东西）。
I don't think the broadcast idea will work. Broadcast traffic in
802.11 is not acked so there's no reason for the stations to respond
to such traffic. The only way is if you're connected to the AP in
question in which case you could do a broadcast ICMP echo request or
something similar (but you'd only get responses from stations in the
same ESS).
I don't think the disassociate packet idea will work either because it
will have to be addressed to the station and you presumably don't know
that address.
I would suggest just sniffing all traffic and keeping track of which
MAC-addresses you see. You don't have to depend on stations probing
but you do depend on them sending something (anything) sometime.
我实际上正在做同样的事情。据我所知，正如 @PerEkman 指出的那样，似乎没有办法从客户端设备引发响应。
您的第一个想法 - 使用通用 SSID 设置 AP - 与称为错误关联（以及其他名称）的 WiFi 黑客非常相似。查看 http://www.packtpub.com/article/backtrack-5 -attacking-the-client 了解有关恶意黑客如何使用此技术的更多信息。
如果您愿意，您可以等待来自附近客户端设备的探测请求，然后创建一个具有与客户端正在查找的 SSID 相匹配的 AP。当然，这种方法的主要缺点是可能需要与客户端设备一样多的接入点。
您也许还可以使用这里的一些想法： http: //hackaday.com/2011/10/04/wifi-jamming-via-deauthentication-packets/ 该信息有点稀疏，但似乎表明可以向广播发送解除身份验证数据包（ 255.255.255.255），并强制该通道上的所有客户端使用各自的 AP 重新进行身份验证（假设它们位于一个 AP 上）。然后你就可以等待结果并以这种方式获取你的信息。也许其他人可以证实这一点？
I'm actually working on the exact same thing. From what I can tell, as @PerEkman pointed out, there doesn't seem to be a way to elicit a response from a client device.
Your first idea - setting up an AP with a generic SSID - is very similar to a WiFi hack known as Mis-Association (among other names). Check out http://www.packtpub.com/article/backtrack-5-attacking-the-client for more information on how malicious hackers use this technique.
If you were so inclined, you could wait for probe requests from nearby client devices then create an AP with an SSID that matches what the client is looking for. Of course, the major downside to this approach is the possible need for as many APs as client devices.
You might also be able to use some ideas from here: http://hackaday.com/2011/10/04/wifi-jamming-via-deauthentication-packets/ The info is a tad sparse, but it would appear to suggest that it's possible to send a deauthentication packet to Broadcast (255.255.255.255) on a given channel and have all clients on that channel be forced to reauthenticate with their respective APs (assuming they were on one). Then you could just wait for the reauths and get your info that way. Maybe someone else can confirm this?
您还可以查找 Wi-Fi 客户端设备发送到接入点的数据帧和数据空帧。这些来自 STA 的上行链路帧在帧控制字段中将具有 ToDs=1 和 FromDs=0。即使客户端设备没有主动下载数据，大多数客户端设备也会频繁地定期发送数据空帧，作为保持活动状态或向接入点发出其当前省电状态的信号。
You can also look for data frames and data-null frames sent by the Wi-Fi client device to the access point. These uplink frames from the STA will have the ToDs=1 and FromDs=0 in the frame control field. Even if a client device is not actively downloading data, most will frequently send data-null frames periodically, either as a keep-alive or to signal its current power save state with the access point.
如果有疑问，请在 Github 上搜索 > > -- 那里已经有很多关于 802.11 协议的项目。
Do a Github search if in doubt > -- already lots of projects there regarding 802.11 protocol.