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

上一篇:SxsTrace工具使用方法(转)


下一篇:SVN查看提交日志的命令