今天进入本篇博客的总结整理阶段 = = 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路由算法//代码效果参考：http://www.zidongmutanji.com/zsjx/444837.html
（如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页面，你会发现同一个版本的驱动仍有不同的子版本：
其中不同标志（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标准的情况下，目前还存在一些替代的解决方案
Repeater模式
Repeater Bridge模式
AP+WDS模式
路由器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是多极化天线。双极化 是水平+垂直极化两个方向，可以同时工作，效率高体积小
相关的帖子有以下几个：
请教专家:2.4G的mimo天线与普通天线的区别
室内MIMO天线规范
摸着石头过河搞MIMO天线
14db平板天线改造为MIMO双天线
2×12db双天线,超经典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下，提示信息如下：
?1iperf: not found
已联系EnGenius请求提供一个可运行的mips-iperf。
最后回到x86开发板的调试，目前修改版的hostapd经确认已经可以成功跳过干扰源检测。
6月13日
虽然淘宝上14dbi平板的售价基本上都在￥30以下，但是要将其改装成MIMO天线还缺少部分工具，因此MIMO天线的改造工作暂缓。
今天主要对M5000三设备互联的传输速率进行了测试。
首先打开设备1的管理页面。设备1无法发现设备3，设备2的信号也较弱。
设备2能同时发现设备1和设备3，设备3虽然距离较远，但是由于中间无障碍，其信号强度较高。
设备3仅能发现设备2，信//代码效果参考：http://www.zidongmutanji.com/zsjx/544259.html
号强度同样较高。设备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检测到的信号强度：
<a href="
