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下,这里就开始刷屏式地打印出既定的信息。搞定!