关于AP如何获取station的rssi

最近在研究一个问题：如何通过AP来获取station的rssi。

具体可以拆分为以下三种情况：

　　1、首先station如果已经连接到AP上，这种情况很容易就能够得到station的RSSI.这里就不讨论这种情况。

　　2、当station并未与设定AP连接，但是这个时候station与另外一个AP连接，并且这两个AP具有相同的channel,这个时候需要通过一种方式去获取station相对于

　　设定AP的RSSI。

　　3、当station并未与设定AP连接，但是这个时候station与另外一个AP连接，当时这个时候两个AP具有不同的channel，这个时候需要通过一种方式去获取station

　　相对于设定AP的RSSI。

问题分析：

　　1、第一种情况很简单，一些ioctl就可以轻松的得到。

　　2、第二种和第三种情况相似，唯一的区别是channel不相同。在station与AP之间未进行连接的情况下，想要去获取station相对于AP的RSSI，只有一种方式

　　那就是通过AP向station发送报文，发送什么报文呢？802.11帧请求帧（proble request/null data/Qos null data/RTS）。通过实验发现发送proble request/

　　Qos null data 帧，station并没有做出回应，（RTS还未进行实验）。当通过AP向station发送null data帧的时候，station会返回给AP一个ACK报文，通过这

　　个ACK可以得到RSSI，这是在QCA 一种叫position的功能上得到的，在QCA上发送普通的null data的时候，不能将station帧收到driver上来，这里就简单通过这种方式，获取到RSSI。但是在这个测试验证的过程中发现有些网卡并不能及时的回复ACK报文，导致AP这边的发送状态始终是放失败，最终不能得到station的RSSI，这种情况还在分析原因。

　　分析原因很有可能是station没有跟设定AP连接，所以station就不会正面回复ACK，但是有些网卡会回复ACK，测试过程中ralink的网卡会回复，inter和realtek都不会正面回复。下面将把抓包得到的信息以图片的形式贴出来。

　　总之通过上面的方式不能获取所有网卡的RSSI，经过一份思索，回想起QCA里面通过一种欺骗的手段来获取ACK.

　　首先看看null data帧：

　　

　　ACK报文内容非常简单，只有一个receiver的mac地址，

两种情况的区别在bssid，正常情况下bssid是填写的ap1的mac，而在欺骗的情况下是填写的AP2的mac，当sta收到null data的时候，发现bssid为AP2，AP2刚好是自己连接的，所以sta就会正面回复一个ACK.ACK报文对于同一channel的所有AP来说都是一样的，大家都会收到这个ACK.