今天进入本篇博客的总结整理阶段 = = 2012.8.3
前言
在2012年6月10日至7月25日的一个半月的时间里，实验室对基于802.11n的Mesh测试平台的搭建进行了一个初步的探索。
如果读者对Mesh网络尚不了解，可以先去阅读一下对应的维基百科条目。简单的说，Mesh网络在各方面和Ad-hoc网络都很类似，两者都能够将一个无线网络透明地整合起来，实现互通，因此一个Ad-hoc / Mesh网络在实现效果上类似于一个交换机。
然而在具体应用时，两者也有一个显著的区别：一个Ad-hoc节点总是对应于一个单一的设备，从该节点发出的二层报文的源MAC地址始终是唯一的；而一个Mesh节点则可能同时作为一个AP向周围的设备提供接入服务，因此从该Mesh节点送出的二层报文的源MAC地址可能有多个。这个区别也造成了一个配置时可能遇到的困扰：在新的Linux内核下，是无法将Ad-hoc模式的无线网卡与其它设备桥接的，因为一旦进行桥接，就意味着源MAC地址不止一个，而Mesh模式则没有这个限制。
之前提到的Mesh测试平台又是一个什么东西呢？对于一个Mesh网络来说，采用的路由算法是其核心，而对Mesh路由算法（如AODV、DSDV、DSR、TORA）的研究通常以离散事件仿真器为主要平台。本问中提到的Mesh测试平台则是一个由嵌入式设备构成的模拟测试平台，路由协议代码以内核模块的形式工作在Linux系统之上，所有的报文都将通过真实的设备转换为电磁波进行发射，通过真实的设备和较为真实的环境对整个网络的性能进行评估。
虽然模拟测试强调真实性，但是仍然不同于真实环境测试。如果整个Mesh网络的覆盖范围达到数百米，那么就很难在实验室中进行操作了。所以，为了便于模拟测试的进行，必须对整个网络拓扑结构进行微缩处理，而进行这个处理的主要方式就是对设备的发射功率进行调节。
在对测试平台进行配置的过程中，集中精力解决了几个问题，而这些问题在Internet上通常很难搜索到比较完整的解答。这些问题包括以下几个：
- 在Linux下，对于Atheros 802.11n系列网卡，应该选用什么驱动程序
- 在Linux下，与无线配置相关的程序都有哪些
- 在Linux下，如何强制以HT40模式启动AP
- 在Linux下，如何强制以HT40模式启动Mesh节点
- 在Linux下，如何强制以HT40模式启动Ad-hoc节点
- 对于一个802.11n 2x2 MIMO无线网卡，应当如何安装天线才能使速率达到一个比较理想的值
Questions and Answers
下面逐一对这些问题进行解答。
Q1: 在Linux下，对于Atheros 802.11n系列网卡，应该选用什么驱动程序
这里基本上总共有三个选择：使用内核中集成的ath9k驱动、安装compat-wireless版ath9k驱动，或者安装MadWifi驱动。ath9k支持Atheros所有的802.11n芯片组，而MadWifi对Atheros 802.11n的支持则非常有限，因此ath9k总是首选驱动。
即使选择使用ath9k，也有两个不同的方式：使用内核中集成的驱动，或者安装compat-wireless。那么之前一直提到的compat-wireless到底是个什么东西呢？如果打开ath9k官网，你会看到如下的描述：
ath9k backported for older kernels
也就是说，compat-wireless使得你可以在较老的内核上安装最新的ath9k驱动程序。
举个例子，在更新本节时，Linux内核的最新版本是3.5-rc6，而你使用的嵌入式Linux发行版的最高内核只有3.2，而3.2内核中集成的ath9k在对Mesh、Ad-hoc HT40等模式的支持上尚存在问题，那么应该如何解决呢？可以下载Linux 3.5-rc6版源码，然后配置内核、编译、安装，这个过程一般至少需要3个小时；另外一个途径则是下载compat-wireless，然后编译、安装。在安装完成后，新编译的无线驱动模块将自动替换原模块，因此就可以快速地在3.2内核下运行3.5内核集成的驱动程序了。
如果打开compat-wireless的stable release页面，http://linuxwireless.org/en/users/Download/stable/，你会发现同一个版本的驱动仍有不同的子版本：
其中不同标志（s、n、p、c）的含义分别如下所示：
- -s - get and apply pending-stable/ from linux-next.git
- -n - apply the patches linux-next-cherry-picks directory
- -p - apply the patches on the linux-next-pending directory
- -c - apply the patches on the crap directory
如果不熟悉Linux内核的开发模式，那么以上描述可能会相当令人疑惑（好吧其实我也不太熟悉）。但是大致的意思就是，当开发者向社区提交一份代码（补丁）时，其有效性、稳定性需要得到评估，不同等级的补丁被划分在不同的类别下。pending-stable依照其字面意思，就是即将发布为稳定版的版本；而linux-next-cherry-picks、linux-next-pending和crap下的代码则需要更多的时间才能被正式包含进内核。
这里对驱动选择问题进行一个总结：在大多数情况下，compat-wireless的最新版都是一个不错的选择，如果你确实需要一些最新开发的特性，那么可以尝试snpc版，否则就使用稳定版。
compat-wireless的安装还是非常简单的：
tar xjf compat-wireless-3.5-1.tar.bz2 cd compat-wireless-3.5-1.tar.bz2 ./scripts/driver-select ath9k make sudo make install
Q2: 在Linux下，与无线配置相关的程序都有哪些
在使用ath9k驱动程序时，常见的用户空间(user space)配置程序有3种：
- hostapd: 用于建立AP的用户空间程序（hostapd is a user space daemon for access point and authentication servers）
- iw: 一个基于nl80211的命令行控制程序（iw is a new nl80211 based CLI configuration utility for wireless devices. It supports almost all new drivers that have been added to the kernel recently）
- iwconfig / iwlist / iwpriv: 一系列基于Linux Wireless Extension的无线配置工具（Wireless tools for Linux is a package of Linux commands (simple text-based utilities/tools) intended to support and facilitate the configuration of wireless devices using the Linux Wireless Extension.）
刚接触Linux无线配置的同学大概会很容易迷失在一大堆名词之中：madwifi、ath9k、ath5k、prism54、wlanconfig、iw、iwconfig、iwlist、nl80211、cfg80211、mac80211、hostapd……这些东西之间到底有什么关系呢？
不论当前关于Linux无线的解决方案有多少个，它们都逃不出一个模式：为了使用户能够控制无线设备，需要一个运行在用户空间的配置程序，而这个配置程序则通过访问内核中的驱动程序对硬件进行操作。
此外，为了统一接口并方便用户进行无线配置，开源社区还提供了一些通用的API，作为整个无线配置的中间层。关于这些通用无线API最初的建立思想，可以参考Jean Tourrilhes提供的文档：
2 Philosophy & Goal
It all started when I tried to install a Wavelan network on Linux computers. I was having a ISA and a PCMCIA versions of the Wavelan, and the two drivers were using totally different methods for the setup and collection of statistics (and in fact fairly incomplete...). As my small hard disks didn't allow me to reboot to DOS to set up those missing parameters, I started to modify the driver code.I decided to define a wireless API which would allow the user to manipulate any wireless networking device in a standard and uniform way. Of course, those devices are fundamentally different, so the standardisation would only be on the methods but not on the values (a Network ID is always a parameter that you may set and get and use to distinguish logical networks, but some devices might use 4 bits and others 16 bits, and the effect of a change may be immediate or delayed after a reconfiguration of the device...).
This interface would need to be flexible and extensible…
Linux Wireless Extension是其中的一个早期分支。Linux Wireless Extension由三个部分组成：第一部分是用于操作这个Extension的用户接口iwconfig、iwlist、iwpriv等，第二部分是在内核中添加对Extension的相应支持，第三部分位于各硬件的驱动程序中，将Extension定义的标准操作转换为具体的硬件操作。
由于一些问题，目前Linux Wireless Extension已经停止开发，取而代之的是nl80211和cfg80211。cfg80211是下一代的Linux无线配置API，即将取代Wireless Extension，而nl80211（头文件）则用于控制cfg80211设备。
mac80211是一个用于开发SoftMAC无线设备驱动的框架，关于mac80211、cfg80211、nl80211和Wireless Extension之间的关系，可以在mac80211的文档页面找到大致的解答：
mac80211 implements the cfg80211 callbacks for SoftMAC devices, mac80211 then depends on cfg80211 for both registration to the networking subsystem and for configuration. Configuration is handled by cfg80211 both through nl80211 and wireless extensions.
关于这几者之间的关系，暂且就用这张图来描述一下吧。
kernel | user space
|
+---------+ +--------------+ +--------------+ | +-------------+
| | | | | | | | | hostapd
| | | mac80211 |--| cfg80211 | | | nl80211 | iw
| | | | | | | | |
| | +--------------+ +--------------+ | +-------------+
| drivers | |
| | +--------------------------------+ | iwconfig
| | | | | iwlist
| | | Wireless Extension | | iwpriv
| | | | | iwspy
+---------+ +--------------------------------+ | iwevent...
Q3: 在Linux下，如何强制以HT40模式启动AP
从官方网站下载源码hostapd-1.0.tar.gz。在编译之前，首先安装相应的头文件libnl-dev和libssl-dev。
然后打开源码src/ap/hw_features.c，禁用检测判断：
if (!oper40) { // 修改为 if (0) wpa_printf(MSG_INFO, "20/40 MHz operation not permitted on " "channel pri=%d sec=%d based on overlapping BSSes", iface->conf->channel, iface->conf->channel + iface->conf->secondary_channel * 4); iface->conf->secondary_channel = 0; iface->conf->ht_capab &= ~HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET; }
然后重新编译，此时的hostapd会在启动时跳过干扰源检测。
顺便附上以HT40模式启动AP的配置文件：
interface=wlan0 driver=nl80211 channel=3 hw_mode=g ssid=MeshAP wme_enabled=1 ieee80211n=1 ht_capab=[HT40+][SHORT-GI-40][DSSS_CCK-40]
Q4: 在Linux下，如何强制以HT40模式启动Mesh节点
为了以HT40模式启动Mesh节点，首先请安装最新版的compat-wireless驱动（嗯？如果你的网卡不是Atheros的话那也先把驱动更新到最新版试试，至于结果我就不知道了）。然后将iw更新到最新版，顺便提一下，在更新本节时iw的最新版为3.5。
首先强制以HT40模式启动AP（关于这一条可能需要再确认一下）。
然后输入以下命令：
iw phy phy0 interface add mesh0 type mesh iw dev mesh0 set meshid mymesh iw dev mesh0 set channel 3 HT40+ ifconfig mesh0 hw ether 00:1C:11:11:11:11 ifconfig mesh0 up
注意一点：mesh0的mac地址不能与wlan0的mac地址重复，否则设备是无法正常启动的。
Q5: 在Linux下，如何强制以HT40模式启动Ad-hoc节点
类似于上一条，你需要最新版的compat-wireless，最新版的iw，准备完成后输入以下命令即可：
ifconfig wlan0 down iw dev wlan0 set type ibss iw wlan0 set channel 3 HT40+ ifconfig wlan0 up iw wlan0 ibss join adhoc 2422 HT40+
Q6: 对于一个802.11n 2x2 MIMO无线网卡，应当如何安装天线才能使速率达到一个比较理想的值
在802.11n传输中，速率通常都是由一个MCS索引值来描述的，如下表所示。对于一个2x2 MIMO的网卡来说，两个空间流（Spatial Stream）并行传输数据，因此我们通常看到的300M消费级无线产品通常至少有两根天线，其速率通常也差不多是150M产品的两倍。
使用两根天线实现空间多路传输（Spatial Multiplexing）时，需要保证两根天线接收信道的独立性较强，也就是使两者相互干扰造成的影响较低。
在实际测试中，当外接两根棍状天线时（淘宝上搜2db / 5db天线大概就能找到一大堆），发现天线间距对速率有着非常大的影响。假设你有两块802.11n网卡A和B，每块网卡各接两根棍状天线1和2。
D A1 <-------------------> B1 | | d | | | | A2 <-------------------> B2
整个传输系统如图所示，其中距离d和D对于传输性能的影响是至关重要的。根据之前的配置经验，建议将d设置为13cm或者25cm，而D至少大于1m。
Mesh模拟测试平台搭建指南
为了对整个无线网络进行微缩处理，最简单的方式是对发射功率进行调节，但是仅仅依靠命令调节功率是完全不够的。
在空旷区域，将发射功率设置为默认值27dBm，两个相距80米的802.11n节点间的传输速率约能达到50Mbps。而将发射功率设置为最小值0dBm之后，两个相距80米的802.11n节点间的传输速率仍然有2Mbps。
所以呢，仅仅依靠命令调节功率，而要在实验室十几米的范围内搭建一个多跳的Mesh测试环境会是相当困难的。必须进一步降低发射功率才行。
通常，wifi设备都会采用SMA接口，而目前在市场上可以买到成品SMA接口衰减器（attenuator）。Mini Circuits的原装SMA接口衰减器大概一个售价的￥200左右，而淘宝上比较便宜的衰减器售价大概在￥80左右。
实际模拟测试中面对的Mesh网络拓扑环境通常是较为复杂的，但是对于前期研究来说，通常需要测试的一个基本网络拓扑结构是一个链状多跳结构：
P1 <------> P2 <------> P3 <------> P4 <------> P5 <------> P6 <------> P7 <------> P8 <------> P9 <------> P10 …
这个网络的搭建有哪些具体要求呢？假定每个节点Pn都可以收到来自其它节点的信号，信噪比用SNR(i, j)来表示，那么对于这个网络的一个基本要求是：
- 当| i – j | = 1时，SNR(i, j) > R1
- 当| i – j | ≠ 1时，SNR(i, j) < R2
其中，R1是一个较大的值，保证相邻两节点能够以一定的速率通讯；而R2是一个较小的值，保证不相邻的两节点互相不可见。于是，参数R1、R2的确定与场景布置就成了核心的问题。
最后再顺便提一点：2x2 MIMO传输对天线的配置非常敏感，在测试中，设计一个阻抗不匹配的微带天线同时作为衰减器可能是一个更好的选择。
下面是工作日志部分，其中可能有不少重复的、无关紧要、遗漏的甚至部分错误的内容，仅留作纪念了
开发平台概览
开发板全景。
VIA VT6105M以太网控制芯片，10M/100M自适应接口。
无线网卡WLM200N2-26。
四颗海力士64MB DDR400内存颗粒，CPU型号是AMD Geode ALXD800EEXJ2VD，主频500MHz，一级缓存64KB + 64KB，二级缓存128KB。
Mini PCI网卡WML200N2-26
Datasheet可以在Compex网站上下到：http://www.compex.com.sg/fullDescription.aspx?pID=31，下面是概要描述的截图。
注意到其天线接口类型是MMCX，因此配合常见的SMA接口天线使用时需要一根转接线。通常MMCX接口的阻抗还是常见的50Ω，恩山论坛上有人曾发帖怀疑MMCX转SMA存在阻抗匹配问题导致信号不稳定，不过最后确认是馈线质量的问题。
300M无线网卡Netcore NW362
开发系统多机互联测试时很容易将不同的因素纠缠在一起而难以确定问题的根源。为了更好地控制各干扰因素，首先购买了一个成品网卡。NW362采用2T2R设计，内置双天线，其在Windows下的驱动程序同时支持基站模式和接入点模式。
Voyage Linux
Voyage是一个基于Debian的用于嵌入式x86的Linux发行版。关于安装方法在网站的Get Started页面有比较详细的介绍，这里就不再重复了。需要注意的一点是安装时系统类型应该选择Generic X86 (选择ALIX会导致系统无法启动)，这个配置下的对应内核有三十几MB，所以和通用PC内核相比似乎没有进行大量的剪裁。
Voyage发行版主要对大量的GNU相关工具进行了裁剪，因此在安装完成后占据的存储空间不超过128MB。
在更新本日志时，Voyage Linux的最新版是0.8.5，对应的内核版本是3.2.17。另外Voyage Linux 0.7的内核版本是2.6.32，Voyage Linux 0.8的版本是3.0。不同版本的Linux内核在对相关无线模块的支持上都没有明显的问题。6月10日更新：2.6.32内核中的ath9k驱动不支持WDS模式，也不支持Mesh HT模式。
测试日志
前言
之前的一段时间里断断续续地进行了一些调试工作，但是缺少记录和归纳，下面先对之前的工作进行一个回顾。
- 驱动支持：较新的Linux内核都整合了AR9223的驱动(ath9k)，根据相关文档，ath9k的最低内核推荐版本是2.6.32。Linux同时还包括一个MadWifi驱动程序，官方文档并不推荐使用该驱动。
- HT40模式下802.11n基站的建立：在Linux下建立基站需要使用一个用户空间程序hostapd，hostapd在启动时会检测周围的信号强度，如果信号过多则会自动禁用HT40模式。
实验室周围的干扰源还是较多的，因此AP通常都以HT20模式启动。为了以HT40模式启动，一个解决方法是在启动前把天线拆下来，等启动完成后再安装天线，但是有时即使不安装天线也会检测到干扰源。
- 开发板双机互联的传输速率曾经达到过100Mbps，当时使用的操作系统版本似乎一个是0.7，另一个是0.8。
2012年6月9日
把EnGenious M5000设备拆了，内置的5GHz天线的增益目测有18dbi，设备虽然采用PoE供电，但是电压不是标准的48V，而是24V（实测值22.9V），电路版上的实际元件所用的电压基本上都是3.3V。
PoE端口布局如下所示：棕白棕两根线互相短路，电压24V；蓝白蓝两根线互相短路，电压0V。所以应该可以用个9V干电池做个移动电源。
回到x86开发板的调试。目前桌上一共有3个x86开发板，安装的系统都是Voyage 0.7，另外还有4根MMCX转SMA外螺内孔馈线，4根貌似是3dbi增益的SMA内螺内针偶极子天线。
首先让x86开发板建立802.11n基站，NW362网卡该基站，在基站启动前卸除天线，然后安装馈线1、馈线2、天线1、天线2。基站的IP地址是192.168.100.1，USB网卡的IP地址是192.168.100.4。
使用iperf进行测试，时间长度设置为18秒，客户端统计间隔设置为1秒，接收端TCP窗口和发送端TCP窗口大小都设置为1MB。结果最小传输速率为69.1Mbps，最大传输速率为118Mbps，平均速率为93.8Mbps。
因为x86系统用起来比较方便，顺便也用IxChariot测了一下。Endpoint 5.1 for Linux可以在这个页面下载到，IxChariot Console的版本是5.4。
使用脚本Throughput，把字节数稍微改大些，One Pair测试的结果和iperf差不多。
Eight Pairs测试下的吞吐量折线图。
总吞吐量基本上能够维持在iperf单线程TCP的最高水平(118Mbps)，平均吞吐量比iperf单线程高出约20%。
关闭开发板1号。开发板2号接馈线1、馈线2、天线1、天线2，吞吐量类似于之前的测量值。
开发板2号接馈线3、馈线4、天线3、天线4，吞吐量依旧在100Mbps左右。
2012年6月10日
开发板2在启动完成后会自动进入Managed模式，其相应的配置文件项为：
auto wlan0
iface wlan0 inet static
address 192.168.100.1
network 255.255.255.0
broadcast 192.168.100.255
输入命令切换至ad-hoc模式：
ifconfig wlan0 down iwconfig wlan0 mode ad-hoc essid test channel 3
iw dev wlan0 set channel 3 HT40+ ifconfig wlan0 up
然后运行iperf进行测试。此时传输速率会自动保持在54Mbps，实际吞吐量约20Mbps。OpenWRT论坛和一些其它论坛同样存在相关的讨论，用户通常会发现在Ad-hoc模式或Mesh模式下链路速率只能达到54Mbps。
根据ath9k的文档，目前支持的模式包括一下几个：
- Station Mode
- AP Mode
- IBSS Mode
- Monitor Mode
- Mesh point with HT support, as well as RSN
- WDS (as of >= 2.6.37)
支持WDS的最小内核版本是2.6.37，而支持Mesh HT的最小内核版本在ath9k的开发者邮件列表中暂时还未找到。
在Mesh速率无法达到11n标准的情况下，目前还存在一些替代的解决方案
路由器Linux发行版DD-WRT在其Web UI上直接提供了Repeator / Repeator Bridge模式的选项，其x86固件应该也提供了相应的功能。DD-WRT使用MadWifi作为无线驱动程序，而ath9k仅支持上述方案中的第三项wds。由于以上四个方案均需要建立基站，有理由相信其速率能够达到100Mbps的级别。
[19:53] 为了避免可能存在的问题，首先把Voyage版本升级到0.8.5 (3.2.17 Kernel)。
在升级之前，重新对开发板Station – Access Point互联速率进行了测试。开发板1运行hostapd，开发板2作为客户端，USB网卡同样作为客户端接入开发板1。存在的问题有以下几个：
- 开发板1和2之间的传输速率不稳定，在10Mbps到30Mbps间浮动
- 速率受天线位置的影响似乎比较严重
- 有时转动天线后，链路会断开，重启网卡或系统后可恢复
- 链路速率显示不正常
- 开发板1和USB网卡间的速率始终维持在100Mbps以上
推测可能存在的问题有以下几个：
- 2.6.32版的驱动程序(Managed模式)存在问题
- MIMO天线的布局存在问题
2012年6月11日
在Anywlan论坛转了转，发现犯了一个低级错误。
mimo是多极化天线。双极化 是水平+垂直极化两个方向，可以同时工作，效率高体积小
相关的帖子有以下几个：
推测之前两开发板Station / Access Point模式互联速率达到100Mbps时两个偶极子天线的角度恰好交错到了一个合适的角度。而使用300M无线网卡NW362进行速率测试时，由于收发两端至少有一端的极化方向配置正确，因此速率总能达到100Mbps。
目前淘宝上有出售成品MIMO天线，不过为了节省成本暂时考虑使用14 dbi平板天线改制的MIMO天线方案，DIY天线的主要成本在PCB板，馈线、热缩管等材料能以很低的价格买到。
2012年6月11日 小结
1. x86开发板的速率测试
- HT40模式下，开发板（接两根偶极子天线，角度随机）与NW362之间的传输速率约100Mbps
- HT20模式下，开发板（接两根偶极子天线，角度随机）与NW362之间的传输速率约50Mbps
- 11g模式下，开发板（接两根偶极子天线，角度随机）与NW362之间的传输速率约20Mbps
- HT40模式下，开发板（接1根偶极子天线）与NW362之间的传输速率约50Mbps
- HT20模式下，开发板（接1根偶极子天线）与NW362之间的传输速率约20Mbps
- HT40模式下，开发板1（接两根偶极子天线，角度随机）与开发板2（接两根偶极子天线，角度随机）之间的速率波动非常大，最高速率约100Mbps，大部分时间在10Mbps到30Mbps之间
- Mesh模式下，开发板1（接1根偶极子天线）与开发板2（接1根偶极子天线）之间的速率为14Mbps左右，比HT20模式稍低
注：以上列表中的前6条是Station / Access Point模式下的测试，相关图片稍后补上。
2. 存在的问题
- 天线选择存在错误
- Mesh模式的速率相对于Station – Access Point模式而言较低（如前文所述，ad-hoc / mesh模式下的速率较低是一个存在了一段时间的问题）
3. 近期计划
- 在9V电池和9V电池扣到货以后，首先确认供电正常，然后进行EnGeniou M5000的测试。由于有移动电源，测试地点的选择可以更灵活一些。首先测试3跳传输：M5000-1 –> M5000-2 –> M5000-3 –> Laptop with an 802.11a wifi adapter, e.g., Intel 3945ABG
- 最近手头上正好有个14 dbi平板，可以参照帖子改造成MIMO天线
- 重写hostapd，使其跳过周边信号检测
- WDS模式的测试（如果在MIMO天线已就绪，开发板Station / Access Point模式互联速率能够达到100Mbps，而ad-hoc / mesh速率依然无法达到100Mbps时，一个替代的解决方案是使用WDS。在隧道中，节点构成一个链状结构：WDSNODE1 –> WDSNODE2 –> WDSNODE3 –> … Gateway。假设设备无任何异常，那么一个静态的WDS链配置足够满足传输需求；而当其中某个节点损坏后，下级节点应当能够动态连接到下一跳。如节点2损坏时，节点1自动连接到节点3。检测及修复的过程可以在应用层实现）
- 继续翻阅Internet上的相关讨论，确认ath9k下ad-hoc / mesh模式下可达到的速率
- 编译NW362的Linux驱动，若其支持mesh模式则可进行NW362到x86开发板的传输速率
2011年6月12日
首先修改hostapd，从官方网站下载源码hostapd-1.0.tar.gz。在编译之前，首先安装相应的头文件libnl-dev和libssl-dev。
然后打开源码src/ap/hw_features.c，禁用检测判断：
if (!oper40) { // 修改为 if (0) wpa_printf(MSG_INFO, "20/40 MHz operation not permitted on " "channel pri=%d sec=%d based on overlapping BSSes", iface->conf->channel, iface->conf->channel + iface->conf->secondary_channel * 4); iface->conf->secondary_channel = 0; iface->conf->ht_capab &= ~HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET; }
然后重新编译，此时的hostapd会在启动时跳过干扰源检测。
从Realtek官网下载编译了NW362中的RTL8192CU的Linux启动程序，发现支持的模式只有Station / Access Point / Ad-hoc，因此无法进行mesh测试。估计ad-hoc模式下最大速率依旧是54M，具体细节稍候再测试。
9V碳性电池和3.7V 18650锂离子电池均无法使M5000正常工作，推测M5000内部使用的降压电路需要输入电压恰等于24V。移动电源的制作暂时中止。
从Debian软件库下载的mips版iperf无法运行在M5000下，提示信息如下：
iperf: not found已联系EnGenius请求提供一个可运行的mips-iperf。
最后回到x86开发板的调试，目前修改版的hostapd经确认已经可以成功跳过干扰源检测。
6月13日
虽然淘宝上14dbi平板的售价基本上都在￥30以下，但是要将其改装成MIMO天线还缺少部分工具，因此MIMO天线的改造工作暂缓。
今天主要对M5000三设备互联的传输速率进行了测试。
首先打开设备1的管理页面。设备1无法发现设备3，设备2的信号也较弱。
设备2能同时发现设备1和设备3，设备3虽然距离较远，但是由于中间无障碍，其信号强度较高。
设备3仅能发现设备2，信号强度同样较高。
设备1接实验室中的PC，设备3接笔记本，运行IxChariot Endpoint 5.1进行4 Pairs吞吐量测试，结果似乎还是在预期内的。由于存在两段链路，同时其中一段又有钢筋水泥阻挡，因此实际速率只有8Mbps左右。
Telnet到192.168.254.102（设备2）发现传输的字节数有415MB，说明数据确实通过设备2转发。
接着进行下半部分的测试：把设备1从实验室搬到外面的走廊里。
此时三个设备都能互相发现对方。设备1和设备2的定向天线直面对方，RSSI居然达到了-36。设备1和设备2之间距离较大，定向天线方向平行，RSSI测量值-55也算比较理想了。
设备2检测到的信号强度：
设备3检测到的信号强度：
还是4 Pairs测试，此时速率已达到达到24 Mbps。考虑到802.11a 54Mbps的理论值，这个值已经相当高了。
网卡统计数据。此时设备2转发的字节数增加了50MB，说明有少量报文似乎还是通过设备2转发的，但是大部分直接由设备1发往设备3。
6月14日
目前AODV协议的相关实现包括以下几个：
- KERNEL-AODV
- AODV-UU
- AODV-UIUC
- AODV-UCSB
- Mad-hoc
其中项目AODV-UU的最后更新时间是2010年，支持Linux 2.6.x内核，相比较之下其它项目在相当长的一段时间内没有得到维护。在需要引入AODV协议的前提下，AODV-UU无疑是最佳的二次开发基础。
和常见的AODV模块一样，AODV-UU需要一块支持ad-hoc模式的网卡，因此同样存在链路速率无法超过54Mbps的问题。
目前能够搜索到的唯一一个不完美解决方案来自OpenWRT论坛。
因此考虑将开发平台的操作系统暂时迁移到OpenWRT x86。
6月16日
为了引入来自OpenWRT论坛的非官方ad-hoc补丁，需要下载、编译OpenWRT源码。OpenWRT的wiki地址是http://wiki.openwrt.org/doc/start，有时访问这个地址会遇到无法打开的问题，通常通过设置一个HTTP代理或者启用Opera Turbo即可解决该问题。
该wiki列表的Building子项包括以下子页面：
- OpenWRT Buildroot – About
- OpenWRT Buildroot – Installation
- OpenWRT Buildroot – Usage
- Build VM
- Feeds
- Image Generator
- SDK
为了应用来自OpenWRT论坛的两个补丁，首先需要下载源码，安装相应的工具链，编译，制作镜像，然后测试在该补丁生效时ad-hoc模式的实际传输速率。
关于ad-hoc模式的HT支持目前还查阅到另外两个邮件列表中的回复（其意义尚待确定）：
- [RFC v2] ibss: Added channel type in order to create HT IBSS
- Re: [PATCH 4/4] mac80211: Add HT operation modes for IBSS
通常不同Linux发行版的x86内核及对应工具链的源码都是统一的，因此当OpenWRT下ad-hoc模式能够工作在HT40模式时，Voyage下ad-hoc模式同样应当能够工作在HT40模式；然而Voyage内核的编译开销会明显大于OpenWRT，通常一个标准x86内核的编译将消耗8GB的存储空间及2~3个小时的时间。因此如非绝对必要，不会考虑将补丁应用的基于Debian的Voyage系统下。
6月17日 ~ 6月18日
久违地参加了各种毕业活动，大概还要持续两三天吧。剩下的时间里对OpenWRT源码进行了初步的编译。编译过程可以完全参考OpenWRT Buildroot - Installation这个Wiki页面。
编译前首先下载各必须的软件：
sudo apt-get install subversion build-essential bash binutils fastjar flex git-core g++ gcc util-linux libgtk2.0-dev intltool zlib1g-dev make libncurses5-dev libssl-dev patch perl-modules python2.6-dev ruby sdcc unzip wget gettext xsltproc zlib1g-dev检出OpenWRT源码：
- mkdir ~/openwrt
- cd openwrt
- svn co svn://svn.openwrt.org/openwrt/trunk/
- cd trunk
安装更新：
- ./scripts/feeds update -a
- ./scripts/feeds install -a
配置编译选项：
make menuconfig编译过程将产生一个TUI界面，其中大多数项目保留默认值即可，但是需要将目标平台类型修改为x86。
最后开始编译：
make编译过程将产生一个非常紧凑的输出，如果读者曾经学习过LFS，或许会对输出信息感到比较熟悉。在执行部分步骤时，OpenWRT BuildRoot将从网络上下载源码，因此整个过程非常缓慢，总耗时预计有10小时左右，之后进行的重编译则不存在这个问题。
6月19日～6月22日
各种毕业活动终于告一段落了，宿舍从B9搬到了B16，然后办了个临时宽带。铝板已下单，预计明天发货，发票需要等到星期一再发货；MIMO天线和转接线准备明天再订。
6月23日
天线和MMCX转接线已订，准备开始测试OpenWRT补丁下ad-hoc ht模式的传输速率。
6月24日
之前订的铝板今天中午刚收到，铝板的发票和MIMO天线估计明后天才能到。
再次作个小结。目前的主要目标是解决ad-hoc / mesh网络多跳高速传输问题，各节点构成一个链状结构，各节点同时产生视频数据流，预计总流量将达到60 ~ 90Mbps。开发板的处理器类型为嵌入式x86，无线芯片类型为Atheros AR9223。开发板使用的操作系统是Voyage Linux。
1. 关于驱动程序
Atheros无线网卡在Linux下可用的驱动程序有两个：ath9k / mac80211和madwifi。ath9k支持的模式有以下几个：
- Station
- AP
- IBSS
- Monitor
- Mesh
- WDS
其中IBSS (ad-hoc)仅支持54Mbps操作，Mesh(根据文档)支持更高的速率，所需的内核版本目前还不确定，而WDS模式仅在2.6.37之后的内核中得到支持。ath9k驱动程序所需的最低内核版本为2.6.32。
2. 关于天线的选用
在之前进行的测试中，MiniPCI网卡接两根普通天线与NW362通讯，速率可达100Mbps，但是两块MiniPCI网卡互相通讯速率极不稳定。推测MIMO系统对天线有特殊要求。目前已经订购若干MIMO天线，收货后开始相关测试。
3. 关于IBSS的速率问题
目前Linux下的IBSS模式不支持HT，速率最大只能达到54Mbps，而在Station / AP模式下链路速率可达到300Mbps。发行版OpenWRT提供了一个用于iw的HT补丁。由于开发板互联速率尚不能达到100Mbps，开发板ad-hoc模式互联的速率测试仍未开始。
4. 关于Linux下AODV协议的实现
多个开源项目实现了AODV协议，其中较新的一个是AODV-UU。AODV-UU实现了一个支持AODV协议的内核模块，支持Linux 2.6内核。AODV-UU需要无线设备支持IBSS (ad-hoc)模式，由于天线问题尚未解决，IBSS HT模式速率测试尚未开始，AODV-UU的实际吞吐测试也仍未开始。
5. 链状ad-hoc / mesh网络的替代方案
使用WDS Repeator模式，一块网卡可以在连接到一个基站的同时作为一个基站供其它设备接入，当各个节点级联时即可构成一个WDS链。使用WDS链的一个优势是无需关心IBSS / Mesh模式的速率问题。目前尚未进行有关WDS链的相关测试。
6月25日
重新确认了一遍，iw不支持NW362 (Realtek 8192CU)，所以NW362 / 开发板IBSS HT模式互联测试暂时取消。目前静候MIMO天线中。
6月26日
花了两个小时用AB胶把隔离单元粘起来了，然后依次摆在桌上。
每个隔离单元由四块240 × 240 × 5 mm的1060铝板组成，粘和后构成一个方形管道结构。隔离板共12块，包括 250 × 260 × 1mm 和 250 × 260 × 2mm 铝板各6块，用以调节各单元间的信号衰减。
今天也向通信专业的一位老师请教了一些关于MIMO天线的问题。为了提高信道独立性，天线间距的一个合适取值是λ / 2，对于2.4 GHz电磁波来说，也就是6.25 cm。在之前的测试中可能并未注意这一点，而造成了速率不稳定的情况。
6月27日
中午收到天线后首先进行了Station / Access Point模式下的速率测试。
经过简单的距离和角度调整后，TCP的发送和接收窗口大小设置为4M时，单线程传输速率可以达到约80Mbps，这个速率已经比较正常了。但是当两对天线的间距非常小时，传输速率依然较低。
之后进行了ibss (ad-hoc) HT模式的测试。下载iw的源码iw-0.9.22.tar.bz2，和来自OpenWRT backfire分支的补丁：001-nl80211_sync.patch、100-rx_rate.patch、110-fix_rate_calculation.patch和120-ibss_ht.patch并编译。然后输入以下命令
./iw wlan0 set type ibss ./iw wlan0 set channel 3 HT40+ ./iw wlan0 ibss join test 2422 HT40+ ifconfig wlan0 up
此时双机的连接速率依然是54Mbps。
而后再次进行了mesh point HT模式的测试：
iw wlan0 set type mesh iw wlan0 set meshid mymesh iw wlan0 set channel 3 HT40+ ifconfig wlan0 up
连接速率依然是54Mbps。由于并不清楚速率异常的原因，抽时间在ath9k的开发者邮件列表里发了个帖子。
6月28日
下午对AR9223 WDS模式的配置进行了初步的探索。OpenWRT backfire 10.03.1并不支持AR9223；而在Voyage 0.7.5 (Kernel 2.6.38) 中，Linux Wireless文档中描述的指令
iw phy phy0 interface add wds0 type wds
iw dev wds0 set peer <MAC address>
并不能正确执行。下一步考虑升级内核后在此对其进行配置测试。
7月2日
之前提到OpenWRT社区提供了iw的ibss ht模式补丁，而ath9k邮件列表中则提到了iw的mesh ht模式补丁。因此猜测用户空间程序iw在对HT的支持上处于一个相当重要的位置。
iw 0.9.22源码共5775行，完整阅读预计需要一到两周的时间。
其中文件nl80211.h提供了一份较为详尽的接口文档。
View Code
#ifndef __LINUX_NL80211_H #define __LINUX_NL80211_H /* * 802.11 netlink interface public header * * Copyright 2006-2010 Johannes Berg <johannes@sipsolutions.net> * Copyright 2008 Michael Wu <flamingice@sourmilk.net> * Copyright 2008 Luis Carlos Cobo <luisca@cozybit.com> * Copyright 2008 Michael Buesch <mb@bu3sch.de> * Copyright 2008, 2009 Luis R. Rodriguez <lrodriguez@atheros.com> * Copyright 2008 Jouni Malinen <jouni.malinen@atheros.com> * Copyright 2008 Colin McCabe <colin@cozybit.com> * * Permission to use, copy, modify, and/or distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. * */ #include <linux/types.h> /** * DOC: Station handling * * Stations are added per interface, but a special case exists with VLAN * interfaces. When a station is bound to an AP interface, it may be moved * into a VLAN identified by a VLAN interface index (%NL80211_ATTR_STA_VLAN). * The station is still assumed to belong to the AP interface it was added * to. * * TODO: need more info? */ /** * DOC: Frame transmission/registration support * * Frame transmission and registration support exists to allow userspace * management entities such as wpa_supplicant react to management frames * that are not being handled by the kernel. This includes, for example, * certain classes of action frames that cannot be handled in the kernel * for various reasons. * * Frame registration is done on a per-interface basis and registrations * cannot be removed other than by closing the socket. It is possible to * specify a registration filter to register, for example, only for a * certain type of action frame. In particular with action frames, those * that userspace registers for will not be returned as unhandled by the * driver, so that the registered application has to take responsibility * for doing that. * * The type of frame that can be registered for is also dependent on the * driver and interface type. The frame types are advertised in wiphy * attributes so applications know what to expect. * * NOTE: When an interface changes type while registrations are active, * these registrations are ignored until the interface type is * changed again. This means that changing the interface type can * lead to a situation that couldn't otherwise be produced, but * any such registrations will be dormant in the sense that they * will not be serviced, i.e. they will not receive any frames. * * Frame transmission allows userspace to send for example the required * responses to action frames. It is subject to some sanity checking, * but many frames can be transmitted. When a frame was transmitted, its * status is indicated to the sending socket. * * For more technical details, see the corresponding command descriptions * below. */ /** * enum nl80211_commands - supported nl80211 commands * * @NL80211_CMD_UNSPEC: unspecified command to catch errors * * @NL80211_CMD_GET_WIPHY: request information about a wiphy or dump request * to get a list of all present wiphys. * ...
7月3日
对nl802.11h进行了初步的解读。该文件用60%的篇幅对nl80211中的命令(Commands)和参数(Attributes)进行了描述。
Commands即驱动程序/硬件可接收的指令。
View Code
enum nl80211_commands { /* don't change the order or add anything inbetween, this is ABI! */ NL80211_CMD_UNSPEC, NL80211_CMD_GET_WIPHY, /* can dump */ NL80211_CMD_SET_WIPHY, NL80211_CMD_NEW_WIPHY, NL80211_CMD_DEL_WIPHY, NL80211_CMD_GET_INTERFACE, /* can dump */ NL80211_CMD_SET_INTERFACE, NL80211_CMD_NEW_INTERFACE, NL80211_CMD_DEL_INTERFACE, NL80211_CMD_GET_KEY, NL80211_CMD_SET_KEY, NL80211_CMD_NEW_KEY, NL80211_CMD_DEL_KEY, NL80211_CMD_GET_BEACON, NL80211_CMD_SET_BEACON, NL80211_CMD_NEW_BEACON, NL80211_CMD_DEL_BEACON, NL80211_CMD_GET_STATION, NL80211_CMD_SET_STATION, NL80211_CMD_NEW_STATION, NL80211_CMD_DEL_STATION, NL80211_CMD_GET_MPATH, NL80211_CMD_SET_MPATH, NL80211_CMD_NEW_MPATH, NL80211_CMD_DEL_MPATH, NL80211_CMD_SET_BSS, NL80211_CMD_SET_REG, NL80211_CMD_REQ_SET_REG, NL80211_CMD_GET_MESH_CONFIG, NL80211_CMD_SET_MESH_CONFIG, NL80211_CMD_SET_MGMT_EXTRA_IE /* reserved; not used */, NL80211_CMD_GET_REG, NL80211_CMD_GET_SCAN, NL80211_CMD_TRIGGER_SCAN, NL80211_CMD_NEW_SCAN_RESULTS, NL80211_CMD_SCAN_ABORTED, NL80211_CMD_REG_CHANGE, NL80211_CMD_AUTHENTICATE, NL80211_CMD_ASSOCIATE, NL80211_CMD_DEAUTHENTICATE, NL80211_CMD_DISASSOCIATE, NL80211_CMD_MICHAEL_MIC_FAILURE, NL80211_CMD_REG_BEACON_HINT, NL80211_CMD_JOIN_IBSS, NL80211_CMD_LEAVE_IBSS, NL80211_CMD_TESTMODE, NL80211_CMD_CONNECT, NL80211_CMD_ROAM, NL80211_CMD_DISCONNECT, NL80211_CMD_SET_WIPHY_NETNS, NL80211_CMD_GET_SURVEY, NL80211_CMD_NEW_SURVEY_RESULTS, NL80211_CMD_SET_PMKSA, NL80211_CMD_DEL_PMKSA, NL80211_CMD_FLUSH_PMKSA, NL80211_CMD_REMAIN_ON_CHANNEL, NL80211_CMD_CANCEL_REMAIN_ON_CHANNEL, NL80211_CMD_SET_TX_BITRATE_MASK, NL80211_CMD_REGISTER_FRAME, NL80211_CMD_REGISTER_ACTION = NL80211_CMD_REGISTER_FRAME, NL80211_CMD_FRAME, NL80211_CMD_ACTION = NL80211_CMD_FRAME, NL80211_CMD_FRAME_TX_STATUS, NL80211_CMD_ACTION_TX_STATUS = NL80211_CMD_FRAME_TX_STATUS, NL80211_CMD_SET_POWER_SAVE, NL80211_CMD_GET_POWER_SAVE, NL80211_CMD_SET_CQM, NL80211_CMD_NOTIFY_CQM, NL80211_CMD_SET_CHANNEL, NL80211_CMD_SET_WDS_PEER, NL80211_CMD_FRAME_WAIT_CANCEL, NL80211_CMD_JOIN_MESH, NL80211_CMD_LEAVE_MESH, NL80211_CMD_UNPROT_DEAUTHENTICATE, NL80211_CMD_UNPROT_DISASSOCIATE, /* add new commands above here */ /* used to define NL80211_CMD_MAX below */ __NL80211_CMD_AFTER_LAST, NL80211_CMD_MAX = __NL80211_CMD_AFTER_LAST - 1 };
Attributes即用于描述指令参数的数据结构。
View Code
enum nl80211_attrs { /* don't change the order or add anything inbetween, this is ABI! */ NL80211_ATTR_UNSPEC, NL80211_ATTR_WIPHY, NL80211_ATTR_WIPHY_NAME, NL80211_ATTR_IFINDEX, NL80211_ATTR_IFNAME, NL80211_ATTR_IFTYPE, NL80211_ATTR_MAC, NL80211_ATTR_KEY_DATA, NL80211_ATTR_KEY_IDX, NL80211_ATTR_KEY_CIPHER, NL80211_ATTR_KEY_SEQ, NL80211_ATTR_KEY_DEFAULT, NL80211_ATTR_BEACON_INTERVAL, NL80211_ATTR_DTIM_PERIOD, NL80211_ATTR_BEACON_HEAD, NL80211_ATTR_BEACON_TAIL, NL80211_ATTR_STA_AID, NL80211_ATTR_STA_FLAGS, NL80211_ATTR_STA_LISTEN_INTERVAL, NL80211_ATTR_STA_SUPPORTED_RATES, NL80211_ATTR_STA_VLAN, NL80211_ATTR_STA_INFO, NL80211_ATTR_WIPHY_BANDS, NL80211_ATTR_MNTR_FLAGS, NL80211_ATTR_MESH_ID, NL80211_ATTR_STA_PLINK_ACTION, NL80211_ATTR_MPATH_NEXT_HOP, NL80211_ATTR_MPATH_INFO, NL80211_ATTR_BSS_CTS_PROT, NL80211_ATTR_BSS_SHORT_PREAMBLE, NL80211_ATTR_BSS_SHORT_SLOT_TIME, NL80211_ATTR_HT_CAPABILITY, NL80211_ATTR_SUPPORTED_IFTYPES, NL80211_ATTR_REG_ALPHA2, NL80211_ATTR_REG_RULES, NL80211_ATTR_MESH_CONFIG, NL80211_ATTR_BSS_BASIC_RATES, NL80211_ATTR_WIPHY_TXQ_PARAMS, NL80211_ATTR_WIPHY_FREQ, NL80211_ATTR_WIPHY_CHANNEL_TYPE, NL80211_ATTR_KEY_DEFAULT_MGMT, NL80211_ATTR_MGMT_SUBTYPE, NL80211_ATTR_IE, NL80211_ATTR_MAX_NUM_SCAN_SSIDS, NL80211_ATTR_SCAN_FREQUENCIES, NL80211_ATTR_SCAN_SSIDS, NL80211_ATTR_GENERATION, /* replaces old SCAN_GENERATION */ NL80211_ATTR_BSS, NL80211_ATTR_REG_INITIATOR, NL80211_ATTR_REG_TYPE, NL80211_ATTR_SUPPORTED_COMMANDS, NL80211_ATTR_FRAME, NL80211_ATTR_SSID, NL80211_ATTR_AUTH_TYPE, NL80211_ATTR_REASON_CODE, NL80211_ATTR_KEY_TYPE, NL80211_ATTR_MAX_SCAN_IE_LEN, NL80211_ATTR_CIPHER_SUITES, NL80211_ATTR_FREQ_BEFORE, NL80211_ATTR_FREQ_AFTER, NL80211_ATTR_FREQ_FIXED, NL80211_ATTR_WIPHY_RETRY_SHORT, NL80211_ATTR_WIPHY_RETRY_LONG, NL80211_ATTR_WIPHY_FRAG_THRESHOLD, NL80211_ATTR_WIPHY_RTS_THRESHOLD, NL80211_ATTR_TIMED_OUT, NL80211_ATTR_USE_MFP, NL80211_ATTR_STA_FLAGS2, NL80211_ATTR_CONTROL_PORT, NL80211_ATTR_TESTDATA, NL80211_ATTR_PRIVACY, NL80211_ATTR_DISCONNECTED_BY_AP, NL80211_ATTR_STATUS_CODE, NL80211_ATTR_CIPHER_SUITES_PAIRWISE, NL80211_ATTR_CIPHER_SUITE_GROUP, NL80211_ATTR_WPA_VERSIONS, NL80211_ATTR_AKM_SUITES, NL80211_ATTR_REQ_IE, NL80211_ATTR_RESP_IE, NL80211_ATTR_PREV_BSSID, NL80211_ATTR_KEY, NL80211_ATTR_KEYS, NL80211_ATTR_PID, NL80211_ATTR_4ADDR, NL80211_ATTR_SURVEY_INFO, NL80211_ATTR_PMKID, NL80211_ATTR_MAX_NUM_PMKIDS, NL80211_ATTR_DURATION, NL80211_ATTR_COOKIE, NL80211_ATTR_WIPHY_COVERAGE_CLASS, NL80211_ATTR_TX_RATES, NL80211_ATTR_FRAME_MATCH, NL80211_ATTR_ACK, NL80211_ATTR_PS_STATE, NL80211_ATTR_CQM, NL80211_ATTR_LOCAL_STATE_CHANGE, NL80211_ATTR_AP_ISOLATE, NL80211_ATTR_WIPHY_TX_POWER_SETTING, NL80211_ATTR_WIPHY_TX_POWER_LEVEL, NL80211_ATTR_TX_FRAME_TYPES, NL80211_ATTR_RX_FRAME_TYPES, NL80211_ATTR_FRAME_TYPE, NL80211_ATTR_CONTROL_PORT_ETHERTYPE, NL80211_ATTR_CONTROL_PORT_NO_ENCRYPT, NL80211_ATTR_SUPPORT_IBSS_RSN, NL80211_ATTR_WIPHY_ANTENNA_TX, NL80211_ATTR_WIPHY_ANTENNA_RX, NL80211_ATTR_MCAST_RATE, NL80211_ATTR_OFFCHANNEL_TX_OK, NL80211_ATTR_BSS_HT_OPMODE, NL80211_ATTR_KEY_DEFAULT_TYPES, NL80211_ATTR_MAX_REMAIN_ON_CHANNEL_DURATION, NL80211_ATTR_MESH_SETUP, NL80211_ATTR_WIPHY_ANTENNA_AVAIL_TX, NL80211_ATTR_WIPHY_ANTENNA_AVAIL_RX, /* add attributes here, update the policy in nl80211.c */ __NL80211_ATTR_AFTER_LAST, NL80211_ATTR_MAX = __NL80211_ATTR_AFTER_LAST - 1 };
文件的其余部分定义了一些常用的类型和标志，包括：
- enum nl80211_iftype: 无线模式
- enum nl80211_sta_flags
- struct nl80211_sta_flag_update
- enum nl80211_rate_info: 链路速率信息
- enum nl80211_sta_info: 基站信息类型
- enum nl80211_mpath_flags: Mesh Point模式下的路径状态标志
- enum nl80211_mpath_info: Mesh Point模式的相关信息类型
- enum nl80211_band_attr: 信道属性
- enum nl80211_frequency_attr: 频率属性
- enum nl80211_bitrate_attr: 速率属性
- enum nl80211_reg_initiator
- enum nl80211_reg_type
- enum nl80211_reg_rule_attr
- enum nl80211_reg_rule_flags
- enum nl80211_survey_info
- enum nl80211_mntr_flags
- enum nl80211_meshconf_params
- enum nl80211_mesh_setup_params
- enum nl80211_txq_attr
- enum nl80211_txq_q
- enum nl80211_channel_type
- enum nl80211_bss
- enum nl80211_bss_status
- enum nl80211_auth_type
- enum nl80211_key_type
- enum nl80211_mfp
- enum nl80211_wpa_versions
- enum nl80211_key_default_types
- enum nl80211_key_attributes
- enum nl80211_tx_rate_attributes
- enum nl80211_band
- enum nl80211_ps_state
- enum nl80211_attr_cqm
- enum nl80211_cqm_rssi_threshold_event
- enum nl80211_tx_power_setting
7月4日
对天线的中等距离传输进行了测试。无线节点1置于机柜上，使用可调角度的天线。
两子天线的间距约为3.2cm。首先将另一对天线置于约10米外处的桌上，然后测试两节点间的传输速率。
链路速率显示为300Mbps，实测速率约为25Mbps。
然后改用内置微带天线的USB网卡进行测试。
链路速率依旧是300Mbps。
实测速率约有50Mbps。顺别提一下，当距离非常接近时，两者之间的传输速率可达100Mbps。
随后桌上换用白色棍状天线，调节两天线的间距用以观察空间分集对速率的影响。
间距取值有以下几个：2cm、3cm、4cm、5cm、6cm、8cm、10cm、12cm、14cm、16cm、18cm、20cm、22cm、24cm、26cm。对于每个间距值，分别进行3次长度为10秒的测量，然后取其均值作为传输速率。
下图是2cm时的运行截图：
其它图片就不再列出了。下面使用一个表格对测量数据进行汇总。
| 间距 / cm | 速率1 / Mbps | 速率2 / Mbps | 速率3 / Mbps | 均值 / Mbps |
| 2 | 25.5 | 25.4 | 28.6 | 26.5 |
| 3 | 36.9 | 29.8 | 35.6 | 34.1 |
| 4 | 26.8 | 33.0 | 33.3 | 31.0 |
| 5 | 34.6 | 32.6 | 34.5 | 33.9 |
| 6 | 38.3 | 33.4 | 29.6 | 33.8 |
| 8 | 29.5 | 24.6 | 23.6 | 25.9 |
| 10 | 22.0 | 19.7 | 15.1 | 18.9 |
| 12 | 37.8 | 38.6 | 40.3 | 38.9 |
| 14 | 37.3 | 48.6 | 50.5 | 45.5 |
| 16 | 30.6 | 38.4 | 37.7 | 35.6 |
| 18 | 47.7 | 39.0 | 46.5 | 44.4 |
| 20 | 38.3 | 37.7 | 43.2 | 39.7 |
| 22 | 29.1 | 25.0 | 28.0 | 27.4 |
| 24 | 42.2 | 37.7 | 37.2 | 39.0 |
| 26 | 38.9 | 39.9 | 43.8 | 40.9 |
对应的折线图如下所示。
可见在n * (λ / 2)与与(n + 1) * (λ / 2)之间通常会存在一个波谷。而当天线的距离较近时速率均较低。可见当距离取值合适时，采用两根棍状天线的吞吐量已经和USB网卡内置的微带天线的吞吐量没有多少区别了。
7月6日
利用中午的时间进行了不同信噪比条件下的传输速率测试。信号强度测试工具采用Network Stumbler，如下图所示，该程序仅能在XP下运行。
传输速率依然使用iperf， 采用三次测量取均值的方式进行。测量数据如下表所示：
| 信噪比 / dbm | 速率1 / Mbps | 速率2 / Mbps | 速率3 / Mbps | 均值 / Mbps |
| -45 | 70.1 | 71.0 | 71.6 | 70.9 |
| -45 | 62.6 | 65.3 | 62.6 | 63.5 |
| -45 | 56.3 | 58.8 | 54.9 | 56.7 |
| -56 | 44.1 | 45.4 | 43.4 | 44.3 |
| -58 | 28.6 | 26.5 | 27.1 | 26.4 |
| -66 | 19.1 | 20.4 | 18.9 | 19.5 |
| -72 | 4.27 | 3.65 | 3.74 | 3.89 |
当距离较近时，Network Stumbler显示的信噪比始终为-45dbm，然而实际传输速率并不相同。当距离更远时，速率随着信噪比降低而减小。折线图大致如下所示：
7月7日
对用户空间程序iw 0.9.22进行了初步的分析。
作为用户空间与ath9k驱动程序的桥梁，iw在无线参数配置中有着至关重要的地位。在之前的测试中使用的最新内核版本是3.2.17，而截至更新本日志时，内核的最新版本已达3.5-rc5。不断更新的内核意味着新的特性被不断引入ath9k驱动之中，具体更新信息可参考Compact Wireless中的各个Changelog页面。而iw作为ath9k驱动的控制者也需要不断更新。在之前的测试中内核3.2.17所使用的iw版本是3.1，而目前iw的最新版本是3.5。
iw程序的主要职责是对命令行参数进行解析，然后通过NLA_PUT_XXX等标准接口对驱动程序进行操作。下面展示了一段典型的解析及参数调用代码片段：
static int join_ibss(struct nl80211_state *state, struct nl_cb *cb, struct nl_msg *msg, int argc, char **argv) { char *end; unsigned char abssid[6]; unsigned char rates[NL80211_MAX_SUPP_RATES]; int n_rates = 0; char *value = NULL, *sptr = NULL; float rate; int bintval; if (argc < 2) return 1; /* SSID */ NLA_PUT(msg, NL80211_ATTR_SSID, strlen(argv[0]), argv[0]); argv++; argc--; /* freq */ NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_FREQ, strtoul(argv[0], &end, 10)); if (*end != '\0') return 1; argv++; argc--; if (argc && strcmp(argv[0], "fixed-freq") == 0) { NLA_PUT_FLAG(msg, NL80211_ATTR_FREQ_FIXED); argv++; argc--; } ...
为了成功启用ad-hoc、mesh的HT模式，一个基本的策略是首先将ath9k驱动程序及其控制程序iw升级到最新版本，然后仅当最新的程序仍旧无法满足需求时才有必要自己动手阅读并修改源码。
在之前翻阅Compact Wireless的Changelog的过程中，发现最近的更新包含了大量关于Mesh HT Protection Mode的更新。
据估计，即使是当前Voyage Linux的最新版0.8.5也无法满足高速Mesh网络的需求。接下来的第一个目标是更新ath9k驱动和iw到最新版3.5，并重新测试HT模式的可用性。
7月8日
开始编译compat-wireless和iw。选用的compat-wireless版本为3.5-rc5-1-sn，iw版本为3.5。
在运行Ubuntu 10.04.4的Linux系统(3.0.0内核)下，二者能够直接通过编译。但是在Voyage系统下进行同样的操作时遇到了一系列的问题。
首先是linux-headers。Voyage Linux 0.8.5官方的源中并未提供linux-headers-3.2.17-voyage，因此驱动程序的编译显然就无法进行。将Voyage的版本降至0.8.0之后，能够成功安装linux-headers-3.0.0-voyage，但是出现了另外的问题：
编译时提示Makefile_32.cpu: No such file or directory。上网翻阅关于Voyage 0.8.0的问题，发现有人曾提出过完全相同的问题，并且也提出了相应的解决方案，唯一的问题是其操作较为繁琐。
另外将Ubuntu 10.04 / 3.0.0内核中的Makefile_32.cpu复制到Voyage下之后问题依旧。
7月9日
依照之前提到的帖子中的步骤操作：
I think I found a way (far from the best, but it works).
If you don't care if the process is a bit slower and that you write on your CF, you can execute the same commands on your system without creating the qemu image...
download latest voyage sdk from:
http://mirror.voyage.hk/download/ISO/sdk/
don't forget there might be a mirror closer to you:
http://linux.voyage.hk/mirror
create a qemu disk:
qemu-img create voyage_disk.iso 1G
run voyage:
qemu -cdrom voyage-sdk-0.8.0.iso -hda voyage_disk.iso -redir tcp:2222::22 -boot d
now you can ssh (much easy to cut and paste) into the voyage host with:
ssh 127.0.0.1 -p 2222 -l root
partition and mkfs /dev/hda
mount /dev/hda1 /usr/src
remountrw
if you know how, edit (to use local mirrors and download faster):
/etc/apt/sources.list
/etc/apt/sources.list.d/voyage.list
apt-get update
apt-get install kernel-package build-essential linux-image-3.0.0-voyage linux-source-3.0.0-voyage
cd /usr/src
tar xvjf linux-source-3.0.0-voyage.tar.bz2
cd /usr/src/linux-source-3.0.0-voyage
make oldconfig
make prepare
make modules_prepare
cd /usr/src
download latest compat-wireless (for example):
wget http://www.orbit-lab.org/kernel/compat-wireless-3-stable/v3.3/compat-wireless-3.3-rc1-2.tar.bz2
extract:
tar xvjf compat-wireless-3.3-rc1-2.tar.bz2
cd /usr/src/compat-wireless-3.3-rc1-2
./scripts/driver-select
./scripts/driver-select ath5k
make
tar cvzf compat-wireless-3.3-rc1-2_compiled.tgz compat-wireless-3.3-rc1-2/
copy compat-wireless-3.3-rc1-2_compiled.tgz from the qemu VM to the ALIX (eg using scp)
on the alix:
tar xvzf compat-wireless-3.3-rc1-2_compiled.tgz
cd compat-wireless-3.3-rc1-2
make install
mmmmmmmmmm it seems "make install" did actually compile on ALIX for me, so maybe my idea is wrong. If this doesn't work for you, try to follow this same howto but directly on the ALIX. In any case, I can now compile compat-wireless.
hope this helps,
alfonsoss
执行tar xvjf linux-source-3.0.0-voyage.tar.bz2这一部居然足足用了一个小时，没固态硬盘的话就要做好心理准备了。
[22:30] 完成compat-wireless-3.5-rc5-1-sn和iw-3.5的编译，相关测试将在明天继续。
7月10日
试图加载ath9k.ko时出现了一个错误，Aircrack-ng的wiki页面上存在相关的描述。
Module loading problems
Firstly, make sure that the compat-wireless package was compiled with GCC whose minor version is the same as the minor version of the GCC with which the kernel was compiled. For example, if you compiled your kernel with GCC 4.3.2, but you compiled compat-wireless with GCC 4.4.1, you might run into “Invalid module format” problems. These will also occur if you've built the package for a different kernel than the one you're currently running.
其对应的错误信息如下所示：
7月12日
在Voyage Linux下下载内核源码linux-3.5-rc6，将内核压缩方式改为gzip，成功编译通过。但是在安装内核时出现问题。
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-3.5.0-rc6.120712.postinst line 356
补充说明：虽然出现了该错误信息，但是新内核似乎已经正常安装了。重启后运行uname -r，显示当前内核版本为3.5.0。
Voyage Linux下Mesh + AP模式的配置
明天决定临时对802.11s Mesh模式下多跳传输的性能进行一个测试。待测网络具有如下的结构：
Mesh Network
+----------------------------+
+------------+ | |
| Client 1.1 | --- MeshAP x---x Node 1 |
| Client 1.2 | | |
| ... | | x------x MeshAP --- +------------+
| Client 1.n | | Node 2 | | Client 2.1 |
+------------+ | | | Client 2.2 |
| Node 3 x | | ... |
| | | | Client 2.n |
| | | +------------+
+-----------x----------------+
MeshAP
|
+------------+
| Client 3.1 |
| Client 3.2 |
| ... |
| Client 3.n |
+------------+
n个Mesh节点以Mesh模式相连（在ath9k驱动的Mesh模式下，连接标准为802.11s，采用的路由协议为HWMP）。这里Mesh网络的实现效果大致相当于一个二层交换机，来自各节点的网络曾数据无需关心报文是如何转发的，只需知道网络已连同就可以了。当然，不同的路由算法和不同的具体实现方案下，网络的性能是会有相当大的不同的。
每个Mesh节点同时还以AP模式工作，在上图中，所有AP的ESSID都设置为相同的值MeshAP，这样当客户端移动时，可以在各接入点之间无缝漫游。
配置该网络涉及的操作非常简单。首先是修改hostap配置文件：
interface=wlan0 driver=nl80211 channel=3 hw_mode=g ssid=MeshAP wme_enabled=1 ieee80211n=1 ht_capab=[HT40+][SHORT-GI-40][DSSS_CCK-40]
这里将信道设置为3，启用802.11n HT40+模式，SSID为MeshAP。
另外是修改/etc/network/interface：
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
auto eth1
iface eth1 inet static
address 10.0.0.1
netmask 255.255.255.0
broadcast 10.0.0.255
auto wlan0
iface wlan0 inet static
address 192.168.100.1
netmask 255.255.255.0
broadcast 192.168.100.255
up ifconfig eth1 0.0.0.0
up ifconfig wlan0 0.0.0.0
up hostapd /etc/hostapd/hostapd.wlan0.conf &
up iw phy phy0 interface add mesh0 type mesh
up iw dev mesh0 set meshid mymesh
up iw dev mesh0 set channel 3 HT40+
up ifconfig mesh0 hw ether 00:80:48:78:4c:c1
up ifconfig mesh0 up
up brctl addbr br0
up brctl addif br0 eth1
up brctl addif br0 mesh0
up brctl addif br0 wlan0
up ifconfig br0 192.168.100.1/24 up
每个节点中的相关网络接口共三个：eth1、wlan0和mesh0，三者通过br0进行桥接。虽然mesh0设置为启用HT40+模式，但是其实际链路速率仅能达到54Mbps，这个问题在之前已经提到了，暂时没有相关的解决方案。由于存在这个问题，上述配置的网络中，Mesh部分实际是以802.11g模式工作，而AP部分则以802.11n模式工作。
此外，如果需要强制AP工作在HT40 (300Mbps) 模式，则需要对hostapd进行修改。这里不再赘述。
另外一个需要注意的地方是mesh0的MAC地址不能与wlan0的地址相同，否则在启动mesh0时，会出现如下的错误信息：
SIOCSIFFLAGS: Name not unique on network
每个节点中mesh0的MAC地址需要分别进行配置。MAC地址和IP地址的配置是大规模布置节点时需要主要处理的问题。
7月13日
对ath9k下Mesh模式的HT支持情况重新进行了确认。在Voyage 0.8.0 (3.0.0 Kernel)下，Mesh模式仅能达到18Mbps的速率。在安装Compat Wireless 3.5-rc5之后，Mesh模式能够达到48Mbps的速率。而将模式从HT40+设置为HT20之后，速率仍然不变。这表示网卡并未进入HT40模式，然而相对于NoHT模式而言速率仍有1.6倍的提升。
另外这里列出不同驱动版本下内核模块的大小。compat-wireless-3.5-rc5-sn和3.5-rc6版内核中的驱动模块大小均较大，而较为陈旧的内核中的ath9k内核模块也较小。
compat-wireless-3.5-rc5-sn-1 ----------------------------------------------------------------------- ath9k 95637 0 mac80211 191835 1 ath9k linux-3.5-rc6 ----------------------------------------------------------------------- ath9k 94317 0 mac80211 189710 1 ath9k voyage 0.8.0 (3.0.0 Kernel) ----------------------------------------------------------------------- ath9k 81873 0 mac80211 157166 1 ath9k
当执行lsmod 命令发现内核模块的大小发生了变化，就意味着驱动已经更新成功。
7月14日
今天完成了两项重要的工作：一是对铝板箱对信号衰减的影响进行了初步的测试，二是配置成功ath9k 802.11s Mesh HT40模式。
关于铝板箱的大致情况可参见6月26日的日志截图。将四块240mm × 240mm × 5mm用AB胶粘成一个方形作为屏蔽单元，然后使用240mm × 240mm × 1mm铝板和240mm × 240mm × 2mm铝板作为隔离板，用来调节信号衰减。
之前在Voyage 0.8.0系统下编译compat-wireless-3.5-rc5-sn驱动程序，同时更新iw到3.5版，发现调节发射功率的命令不起效果。
iwconfig命令为：
iwconfig mesh0 txpower 0dBm
iw命令为：
iw mesh0 set txpower fixed 0dBm
执行以上两条命令后均无错误消息，但是iperf测得的传输速率却没有明显变化，因此考虑使用铝板对信号衰减进行调节。按照预期，当不使用铝板时，传输速率应该较高，而当中间的隔离板逐渐变厚时，速率将逐渐下降。然而实测结果和预期完全相反。
将两个天线置于相邻的两个隔离单元中，中间不放置铝板，此时的PING值异常的高，而iperf则在无法在合理的时间内完成执行。
把隔离板厚度调节至2mm。PING值算是正常一点了，速率上升到了11Mbps。
继续加铝板，厚度调节至4mm。PING值更低了，速率上升至16Mbps。
最后把隔离板厚度调节至6mm。PING值依然很低，速率居然飙到了46Mbps，这已经是HT20模式的理想值了，学通信的同学快来解释一下吧。是不是铝板粘的时候粘歪了，然后各种细小的缝隙形成了微妙的天线呢？
隔离单元的测试暂时告一段落。接下来将讨论AR9223 / ath9k下Mesh HT模式的配置。之前曾经尝试过以下的命令：
iw mesh0 set channel 3 HT40+
但是只能够到达HT20的水平。后来突然想到了一个方案：首先修改并重新编译hostapd，使其强制进入HT40模式，然后运行hostapd开启AP，然后使用相关命令建立mesh0接口，然后把wlan0、mesh0和eth1桥接起来 (这一步其实是可选的)，最后就是实测观察了。
结果Mesh接口终于能够工作在HT40模式下了：
这个方案的背后其实存在一个假设：一块无线网卡的底层传输仅能工作在一种模式下：或者11g，或者11n HT20，或者11n HT40，以此类推。之前的问题是hostapd能够（通过修改源码）成功强制进入HT40模式，最新版的iw则通常无法进入HT40模式。于是，在强制hostapd进入HT40模式以后，mesh0也就顺理成章地进入HT40模式了。
HT20 / HT40问题有时并非是程序的Bug，而是一个设计策略。不过相信在不久之后这个问题会有一个更好的解决方案。
7月15日
对最新驱动下IBSS HT40模式的传输速率进行了测试。
IBSS模式相对于Mesh模式有几个不同。其一是虚拟接口的个数：使用Mesh模式下，用户可以建立一个mesh0接口，建立一个wlan0接口，然后运行hostapd使wlan0工作在AP模式下。但是使用IBSS模式，当wlan0已启用时，IBSS模式接口adhoc0则无法启动，当用户执行ifconfig adhoc0 up时系统会给出以下提示：
SIOCSIFFLAGS: Device or resource busy
也就是说，AR9223在compat-wireless-3.5-rc5-sn驱动下不支持AP + ADHOC模式，但是却支持AP + MESH模式。
第二个不同点同样也给ADHOC模式带来了局限性：ad-hoc模式的接口是无法桥接的。当用户试图将adhoc0接口加入br0时，会得到如下的提示：
can't add adhoc0 to bridge br0: Operation not supported
为什么会有这个提示呢？因为在ad-hoc模式下，每个节点只能是一个单一的个体。一旦进行了桥接，从该ad-hoc接口发出的报文就会拥有多个mac地址，而这是不符合设计规范的。Mesh模式则允许这种情况。
最后再展示一段配置程序，在compat-wireless-3.5-rc5-sn驱动下，相邻两个adhoc节点间的互联速率可以达到80Mbps，显然HT40模式已经能够正常启动了。
ifconfig wlan0 down iw phy phy0 interface add adhoc0 type ibss iw adhoc0 set channel 3 HT40+ ifconfig adhoc0 up iw adhoc0 ibss join adhoc 2422 HT40+
再次强调一下，IBSS HT40模式的成功配置需要多个因素：最新版的驱动(compat-wireless-3.5)、最新的的驱动控制程序(iw-3.5)和合理的天线布局。
如果IBSS速率存在问题，记得首先检查以上各项。
7月16日
使用AutoCAD画了个A10五楼的示意图，并且简单准备了一个测试方案。
7月17日
将三个Mesh节点分别置于509、507、505，并且进行了简单的调节，使相邻节点间的速率能够达到约50Mbps。顺便提一下，509和507的长度大约是11.5米，而511和505的长度大约是6.8米。
其中509和507间的吞吐率如下所示：
这个布局存在一个问题：AP1和AP3能够直接相连，因此三个节点实质上构成了一个三角形的拓扑结构。下一步将固定AP2与AP3，并对其一跳范围进行测试。
7月18日
使用之前购买的联想天线测试两节点间的传输速率。Mesh Point 2 (下图中的AP2)固定于507室，而另一节点沿走廊放置。
下图对各点速率进行了汇总：
P1
约以70°角穿两堵墙，速率约11Mbps。
P2
以50°角穿一堵墙，速速率约59Mbps。
P3
以0°角穿一堵墙，速速率约67Mbps。
P4
以60°角穿一堵墙，速速率约4.8Mbps。
P5
以75°角穿三堵墙，这时iperf和IxChariot已经无法正常运行，丢包率约为15% ~ 18%。
P5.2
进一步往外移，丢包率达到了95%。
7月19日
将Mesh Point 1 (下图中的AP1) 固定在505室并进行相同的测试。这个场景中的AP1天线采用两根间距为25cm的独立棍状天线，其吞吐率略高于联想天线，而移动测试点使用联想天线。
P1
以45°角穿一堵墙，速率约为84Mbps。
P2
以0°角穿一堵墙，速率约为97Mbps。
P3
以60°角穿一堵墙，速率约为20Mbps。
P4
以80°角穿三堵墙，丢包率达到48%，TCP测试已无法完成。
P4.5
以80°角穿四堵墙，丢包率达到95%。
7月20日
首先对楼道环境的测试布局进行一个总结。
A10东西总长约为100米，东西南北两侧各由四个紧邻的实验室组成，四个实验室总长约为39米。下图中仅绘制出了东北区的四个实验室。
[图]
为了能够获得所需的网络拓扑结构，隔离不同的无线节点，需要使信号衰减足够严重。目前可采取的方式有以下几种：
- 利用墙壁障碍
- 利用长距离
- 利用铝板进行反射
今天进行的测试的一项是距离及发射功率对传输速率的影响。将两个节点置于楼道中，间距约80m中间无障碍，发射功率为默认的27dBm，此时的速率能够达到30 ~ 40Mbps；而将功率调节至最小值0dBm时，速率约为2Mbps。因此，一个显而易见的结论是单纯的功率调整距离控制无法隔离两个无线节点。
另一项是铝反射板对无线节点的影响。最小功率下在每个天线前方放置一块6mm铝板后，节点间的可见距离缩减到25m以内。
另外，根据之前的测试，默认功率下，以0°角穿越2堵墙与15m的距离（如将节点分别置于505和509）并不能够完全隔离两个无线节点，这给节点的放置带来了一定的局限性。相应的应对策略可以是设置更大的距离与障碍及功率调整。
7月21日 ~ 7月22日
进行4节点综合测试，共产生24组IxChariot测试数据，详情稍后补上。
7月23日
编写演示文稿。
7月24日
由于之前的802.11n测试数据不太稳定，重新对其进行测试。
