Madwifi Mad coding：自底向上分析associated_sta的更新过程 —— RSSI和MACADDR等信息获取的底层原理

Madwifi驱动工作在AP模式下时，可以在/proc/net/madwifi/ath0/associated_sta文件中得到所有接入的用户的MAC地址、实时平均RSSI，和last_rx三个信息。其中RSSI是指在一秒内AP接收到的来自该用户的包的RSSI的平均值。有一件极具挑战的事情，就是把每个包到达网卡时，网卡检测到的RSSI读取出来。

网卡每一秒钟将发送一个事件通知，由内核（kernel）处理，在事件处理函数中，将RSSI写到文件中。而在应用层看到的RSSI，是写入文件之后的内容。

既然associated_sta中的RSSI是均值，那么必有求均值的过程，不是在内核就是在硬件的驱动中。于是搞清楚以下几个问题，也就可以修改源代码了：

　　1，求均值的代码在哪？网卡写到kernel的，是RSSI均值，还是所有包的RSSI？如果是前者，则还需往下找。

　　2，触发事件通知的对象是谁？该对象可能有我们要的RSSI。

1.

我首先用grep进行全文检索，找到了“associated_sta”出现的位置：

ieee80211_linux.c line 838:

　　/*Create a proc entry listing the associated stations*/

　　ieee80211_proc_vcreate(vap, &proc_ieee80211_ops, "associated_sta");

进而找到函数ieee80211_proc_vcreate的定义，也在linux.c中：

ieee80211_linux.c line 868:

　　/*Register a proc entry under the vap directory*/

2.

那么一个proc entry结构体包含什么呢？

ieee80211_var.h line 565:

　　struct ieee80211_proc_entry{

　　　　char * name;

　　　　struct fileoperations * fileops;

　　　　struct proc_dir_entry * entry;

　　　　struct ieee80211_proc_entry * next;

　　}

看到next方知，原来，entry处于一个链表中。

3，回到ieee80211_proc_vcreate函数体：

909:　　entry->name = name; （也就是文件名，放在了entry结构体中，下面追踪entry）

923:　　if (!tmp){

　　　　　　vap->iv_proc_entries = entry;

　　　　}else{

　　　　　　tmp->next = entry;

　　　　}

然后函数返回0;

4. 调用完函数，继续看

ieee80211_linux.c:

840:　　/*Register any other proc entries that have been registered*/ 注册其他已注册过的proc entry。

而这一切都在函数ieee80211_virtfs_latevattach中。使用它的是：

1000:

　　switch(event){

　　case NETDEV_CHANGENAME:

　　　　ieee80211_virtfs_vdetach( netdev_priv(dev) );

　　　　ieee80211_virtfs_latevattach( netdev_priv(dev) );

　　　　return NOTIFY_DONE;

　　}

　　default: break;

注意到NOTIFY_DONE。就是说通过ieee80211_virtfs_latevattach函数处理完了事件通知。而这段代码正是在事件处理函数ieee80211_dev_event_notifier中。

事件处理函数需要通过函数register_netdevice_notifier进行注册，以在事件通知出现时正确地被调用。

5. 沿着函数ieee80211_dev_event_notifier继续往上找，就是init-wlan以及module_init等接近上层核心内容的东西了，但是与我们的目标RSSI无关。

6. 于是需要往下找，找到编译到kernel中的madwifi驱动把什么内容（数据）通过事件通知链，以事件通知处理的方式（类似于终端服务程序）写入到了文件中。

回到写文件这个过程：

7. associated_sta 文件的格式是：

macaddr: <XX:XX:XX:XX:XX:XX>

rssi XX

last_rx XX

于是查找"macaddr: <"：

还是ieee80211_linux.c:

426:　　static int

　　proc_read_nodes (struct ieee80211vap * vap, char * buf, int space)

　　{

　　....

　　p+=sprintf(p, "macaddr: <" MAC_FMT ">\n", ni->ni_macaddr);

　　p+=sprintf(p, " rssi <" MAC_FMT ">\n", ni->ni_rssi);

　　}

看来，RSSI均值保存在ni结构体中。接下来找ni的赋值过程，尤其是ni->ni_rssi的赋值。实际上，要写入到associated_sta文件中的RSSI值等数据，都是直接通过指针传给ieee80211_rcv_dev_event这个事件处理函数的。那么是谁传给它的呢？

8. 顺着ni和nt找下去：

ieee80211_node.c:

2337:

　　ieee80211_getrssi (struct ieee80211com* ic)

　　{

　　　　...

　　　　switch (ic->ic_opmode){

　　　　case IEEE80211_M_IBSS:

　　　　　　TAILQ_FOREACH(ni, &nt->mode, ni_list)

　　　　　　　　if (ni->ni->capinfo & ... ){

　　　　　　　　　　rssi_samples++;                  //计数器

　　　　　　　　　　rssi_total += ic->ic_node_getrssi(ni);

　　　　　　　　}

　　　　case IEEE80211_M_AHDEMO: // adhoc模式

　　　　　　(同上)

　　　　case IEEE80211_M_HOSTAP: // AP模式

　　　　　　(同上)

　　　　case IEEE80211_M_MONITOR: // monitor模式

　　　　case IEEE80211_M_STA:        // station模式

　　　　default:

　　　　　　(同上)

　　　　}

　　}

在Ad-hoc模式、AP模式下，均有RSSI的处理，而MONITOR模式则没有。实际上这是一段用来评估信道的代码，这里的RSSI指的是全部节点的“平均”RSSI的“平均”值。这样一个RSSI主要用于信道的扫描，评估和选择，后来我发现这段代码只在初始化时由ath_attach（间接）调用，以及在iwconfig中被调用。此外，CSMA/CA,即载波侦听接入控制协议，也包含了RSSI侦听的过程。类似的，这些都不是我们想要的。上面的代码中，total+=里的东西实际上是一个node的平均rssi。

Oh no。那么这不是我们想要的，就需要继续寻找。 找到ni->ni_rssi的赋值语句：

9. ieee80211_input.c line 300+，有一个同名的函数ieee80211_input(...., int rssi, ....).在此函数里有多处rssi的赋值。

418: if (IEEE80211_ADDR_EQ(wh->i_addr2, ni->ni_macaddr) ) {

　　　　ni->ni_rssi = rssi;

　　　　ni->ni_rtsf = rtfs;

　　　　ni->ni_last_rx = jiffies;

　　　　//在这边加上输出：

　　　　printk("<0>"MAC_FMT" %d\n", MAC_ADDR(...), rssi);

}

得到的结果是，一旦有客户连接到AP下，这里就开始刷屏式地打印出既定的信息。搞定！