今天进入本篇博客的总结整理阶段==2012.8.3
前言
然而在具体应用时,两者也有一个显著的区别:一个Ad-hoc节点总是对应于一个单一的设备,从该节点发出的二层报文的源MAC地址始终是唯一的;而一个Mesh节点则可能同时作为一个AP向周围的设备提供接入服务,因此从该Mesh节点送出的二层报文的源MAC地址可能有多个。这个区别也造成了一个配置时可能遇到的困扰:在新的Linux内核下,是无法将Ad-hoc模式的无线网卡与其它设备桥接的,因为一旦进行桥接,就意味着源MAC地址不止一个,而Mesh模式则没有这个限制。
之前提到的Mesh测试平台又是一个什么东西呢?对于一个Mesh网络来说,采用的路由算法是其核心,而对Mesh路由算法(如AODV、DSDV、DSR、TORA)的研究通常以离散事件仿真器为主要平台。本问中提到的Mesh测试平台则是一个由嵌入式设备构成的模拟测试平台,路由协议代码以内核模块的形式工作在Linux系统之上,所有的报文都将通过真实的设备转换为电磁波进行发射,通过真实的设备和较为真实的环境对整个网络的性能进行评估。
虽然模拟测试强调真实性,但是仍然不同于真实环境测试。如果整个Mesh网络的覆盖范围达到数百米,那么就很难在实验室中进行操作了。所以,为了便于模拟测试的进行,必须对整个网络拓扑结构进行微缩处理,而进行这个处理的主要方式就是对设备的发射功率进行调节。
在对测试平台进行配置的过程中,集中精力解决了几个问题,而这些问题在Internet上通常很难搜索到比较完整的解答。这些问题包括以下几个:
QuestionsandAnswers
下面逐一对这些问题进行解答。
Q1:在Linux下,对于Atheros802.11n系列网卡,应该选用什么驱动程序
这里基本上总共有三个选择:使用内核中集成的ath9k驱动、安装compat-wireless版ath9k驱动,或者安装MadWifi驱动。ath9k支持Atheros所有的802.11n芯片组,而MadWifi对Atheros802.11n的支持则非常有限,因此ath9k总是首选驱动。
即使选择使用ath9k,也有两个不同的方式:使用内核中集成的驱动,或者安装compat-wireless。那么之前一直提到的compat-wireless到底是个什么东西呢?如果打开ath9k官网,你会看到如下的描述:
ath9kbackportedforolderkernels
也就是说,compat-wireless使得你可以在较老的内核上安装最新的ath9k驱动程序。
举个例子,在更新本节时,Linux内核的最新版本是3.5-rc6,而你使用的嵌入式Linux发行版的最高内核只有3.2,而3.2内核中集成的ath9k在对Mesh、Ad-hocHT40等模式的支持上尚存在问题,那么应该如何解决呢?可以下载Linux3.5-rc6版源码,然后配置内核、编译、安装,这个过程一般至少需要3个小时;另外一个途径则是下载compat-wireless,然后编译、安装。在安装完成后,新编译的无线驱动模块将自动替换原模块,因此就可以快速地在3.2内核下运行3.5内核集成的驱动程序了。
其中不同标志(s、n、p、c)的含义分别如下所示:
这里对驱动选择问题进行一个总结:在大多数情况下,compat-wireless的最新版都是一个不错的选择,如果你确实需要一些最新开发的特性,那么可以尝试snpc版,否则就使用稳定版。
compat-wireless的安装还是非常简单的:
在使用ath9k驱动程序时,常见的用户空间(userspace)配置程序有3种:
刚接触Linux无线配置的同学大概会很容易迷失在一大堆名词之中:madwifi、ath9k、ath5k、prism54、wlanconfig、iw、iwconfig、iwlist、nl80211、cfg80211、mac80211、hostapd……这些东西之间到底有什么关系呢?
不论当前关于Linux无线的解决方案有多少个,它们都逃不出一个模式:为了使用户能够控制无线设备,需要一个运行在用户空间的配置程序,而这个配置程序则通过访问内核中的驱动程序对硬件进行操作。
2Philosophy&GoalItallstartedwhenItriedtoinstallaWavelannetworkonLinuxcomputers.IwashavingaISAandaPCMCIAversionsoftheWavelan,andthetwodriverswereusingtotallydifferentmethodsforthesetupandcollectionofstatistics(andinfactfairlyincomplete...).Asmysmallharddisksdidn'tallowmetoreboottoDOStosetupthosemissingparameters,Istartedtomodifythedrivercode.
IdecidedtodefineawirelessAPIwhichwouldallowtheusertomanipulateanywirelessnetworkingdeviceinastandardanduniformway.Ofcourse,thosedevicesarefundamentallydifferent,sothestandardisationwouldonlybeonthemethodsbutnotonthevalues(aNetworkIDisalwaysaparameterthatyoumaysetandgetandusetodistinguishlogicalnetworks,butsomedevicesmightuse4bitsandothers16bits,andtheeffectofachangemaybeimmediateordelayedafterareconfigurationofthedevice...).
Thisinterfacewouldneedtobeflexibleandextensible…
LinuxWirelessExtension是其中的一个早期分支。LinuxWirelessExtension由三个部分组成:第一部分是用于操作这个Extension的用户接口iwconfig、iwlist、iwpriv等,第二部分是在内核中添加对Extension的相应支持,第三部分位于各硬件的驱动程序中,将Extension定义的标准操作转换为具体的硬件操作。
mac80211是一个用于开发SoftMAC无线设备驱动的框架,关于mac80211、cfg80211、nl80211和WirelessExtension之间的关系,可以在mac80211的文档页面找到大致的解答:
mac80211implementsthecfg80211callbacksforSoftMACdevices,mac80211thendependsoncfg80211forbothregistrationtothenetworkingsubsystemandforconfiguration.Configurationishandledbycfg80211boththroughnl80211andwirelessextensions.
关于这几者之间的关系,暂且就用这张图来描述一下吧。
kernel|userspace|+---------++--------------++--------------+|+-------------+|||||||||hostapd|||mac80211|--|cfg80211|||nl80211|iw|||||||||||+--------------++--------------+|+-------------+|drivers||||+--------------------------------+|iwconfig|||||iwlist|||WirelessExtension||iwpriv|||||iwspy+---------++--------------------------------+|iwevent...Q3:在Linux下,如何强制以HT40模式启动AP
然后打开源码src/ap/hw_features.c,禁用检测判断:
if(!oper40){//修改为if(0)wpa_printf(MSG_INFO,"20/40MHzoperationnotpermittedon""channelpri=%dsec=%dbasedonoverlappingBSSes",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=wlan0driver=nl80211channel=3hw_mode=gssid=MeshAPwme_enabled=1ieee80211n=1ht_capab=[HT40+][SHORT-GI-40][DSSS_CCK-40]Q4:在Linux下,如何强制以HT40模式启动Mesh节点
为了以HT40模式启动Mesh节点,首先请安装最新版的compat-wireless驱动(嗯?如果你的网卡不是Atheros的话那也先把驱动更新到最新版试试,至于结果我就不知道了)。然后将iw更新到最新版,顺便提一下,在更新本节时iw的最新版为3.5。
首先强制以HT40模式启动AP(关于这一条可能需要再确认一下)。
然后输入以下命令:
iwphyphy0interfaceaddmesh0typemeshiwdevmesh0setmeshidmymeshiwdevmesh0setchannel3HT40+ifconfigmesh0hwether00:1C:11:11:11:11ifconfigmesh0up注意一点:mesh0的mac地址不能与wlan0的mac地址重复,否则设备是无法正常启动的。
Q5:在Linux下,如何强制以HT40模式启动Ad-hoc节点
类似于上一条,你需要最新版的compat-wireless,最新版的iw,准备完成后输入以下命令即可:
ifconfigwlan0downiwdevwlan0settypeibssiwwlan0setchannel3HT40+ifconfigwlan0upiwwlan0ibssjoinadhoc2422HT40+Q6:对于一个802.11n2x2MIMO无线网卡,应当如何安装天线才能使速率达到一个比较理想的值
在802.11n传输中,速率通常都是由一个MCS索引值来描述的,如下表所示。对于一个2x2MIMO的网卡来说,两个空间流(SpatialStream)并行传输数据,因此我们通常看到的300M消费级无线产品通常至少有两根天线,其速率通常也差不多是150M产品的两倍。
使用两根天线实现空间多路传输(SpatialMultiplexing)时,需要保证两根天线接收信道的独立性较强,也就是使两者相互干扰造成的影响较低。
在实际测试中,当外接两根棍状天线时(淘宝上搜2db/5db天线大概就能找到一大堆),发现天线间距对速率有着非常大的影响。假设你有两块802.11n网卡A和B,每块网卡各接两根棍状天线1和2。
DA1<------------------->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)。MiniCircuits的原装SMA接口衰减器大概一个售价的¥200左右,而淘宝上比较便宜的衰减器售价大概在¥80左右。
实际模拟测试中面对的Mesh网络拓扑环境通常是较为复杂的,但是对于前期研究来说,通常需要测试的一个基本网络拓扑结构是一个链状多跳结构:
P1<------>P2<------>P3<------>P4<------>P5<------>P6<------>P7<------>P8<------>P9<------>P10…
这个网络的搭建有哪些具体要求呢?假定每个节点Pn都可以收到来自其它节点的信号,信噪比用SNR(i,j)来表示,那么对于这个网络的一个基本要求是:
其中,R1是一个较大的值,保证相邻两节点能够以一定的速率通讯;而R2是一个较小的值,保证不相邻的两节点互相不可见。于是,参数R1、R2的确定与场景布置就成了核心的问题。
最后再顺便提一点:2x2MIMO传输对天线的配置非常敏感,在测试中,设计一个阻抗不匹配的微带天线同时作为衰减器可能是一个更好的选择。
下面是工作日志部分,其中可能有不少重复的、无关紧要、遗漏的甚至部分错误的内容,仅留作纪念了
开发平台概览
开发板全景。
VIAVT6105M以太网控制芯片,10M/100M自适应接口。
无线网卡WLM200N2-26。
四颗海力士64MBDDR400内存颗粒,CPU型号是AMDGeodeALXD800EEXJ2VD,主频500MHz,一级缓存64KB+64KB,二级缓存128KB。
MiniPCI网卡WML200N2-26
300M无线网卡NetcoreNW362
开发系统多机互联测试时很容易将不同的因素纠缠在一起而难以确定问题的根源。为了更好地控制各干扰因素,首先购买了一个成品网卡。NW362采用2T2R设计,内置双天线,其在Windows下的驱动程序同时支持基站模式和接入点模式。
VoyageLinux
测试日志
2012年6月9日
把EnGeniousM5000设备拆了,内置的5GHz天线的增益目测有18dbi,设备虽然采用PoE供电,但是电压不是标准的48V,而是24V(实测值22.9V),电路版上的实际元件所用的电压基本上都是3.3V。
PoE端口布局如下所示:棕白棕两根线互相短路,电压24V;蓝白蓝两根线互相短路,电压0V。所以应该可以用个9V干电池做个移动电源。
回到x86开发板的调试。目前桌上一共有3个x86开发板,安装的系统都是Voyage0.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。
使用脚本Throughput,把字节数稍微改大些,OnePair测试的结果和iperf差不多。
EightPairs测试下的吞吐量折线图。
总吞吐量基本上能够维持在iperf单线程TCP的最高水平(118Mbps),平均吞吐量比iperf单线程高出约20%。
关闭开发板1号。开发板2号接馈线1、馈线2、天线1、天线2,吞吐量类似于之前的测量值。
开发板2号接馈线3、馈线4、天线3、天线4,吞吐量依旧在100Mbps左右。
2012年6月10日
开发板2在启动完成后会自动进入Managed模式,其相应的配置文件项为:
autowlan0ifacewlan0inetstaticaddress192.168.100.1network255.255.255.0broadcast192.168.100.255输入命令切换至ad-hoc模式:
支持WDS的最小内核版本是2.6.37,而支持MeshHT的最小内核版本在ath9k的开发者邮件列表中暂时还未找到。
在Mesh速率无法达到11n标准的情况下,目前还存在一些替代的解决方案
路由器Linux发行版DD-WRT在其WebUI上直接提供了Repeator/RepeatorBridge模式的选项,其x86固件应该也提供了相应的功能。DD-WRT使用MadWifi作为无线驱动程序,而ath9k仅支持上述方案中的第三项wds。由于以上四个方案均需要建立基站,有理由相信其速率能够达到100Mbps的级别。
[19:53]为了避免可能存在的问题,首先把Voyage版本升级到0.8.5(3.2.17Kernel)。
在升级之前,重新对开发板Station–AccessPoint互联速率进行了测试。开发板1运行hostapd,开发板2作为客户端,USB网卡同样作为客户端接入开发板1。存在的问题有以下几个:
推测可能存在的问题有以下几个:
2012年6月11日
在Anywlan论坛转了转,发现犯了一个低级错误。
mimo是多极化天线。双极化是水平+垂直极化两个方向,可以同时工作,效率高体积小
推测之前两开发板Station/AccessPoint模式互联速率达到100Mbps时两个偶极子天线的角度恰好交错到了一个合适的角度。而使用300M无线网卡NW362进行速率测试时,由于收发两端至少有一端的极化方向配置正确,因此速率总能达到100Mbps。
2012年6月11日小结
1.x86开发板的速率测试
2.存在的问题
3.近期计划
2011年6月12日
9V碳性电池和3.7V18650锂离子电池均无法使M5000正常工作,推测M5000内部使用的降压电路需要输入电压恰等于24V。移动电源的制作暂时中止。从Debian软件库下载的mips版iperf无法运行在M5000下,提示信息如下:
iperf:notfound已联系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接笔记本,运行IxChariotEndpoint5.1进行4Pairs吞吐量测试,结果似乎还是在预期内的。由于存在两段链路,同时其中一段又有钢筋水泥阻挡,因此实际速率只有8Mbps左右。
Telnet到192.168.254.102(设备2)发现传输的字节数有415MB,说明数据确实通过设备2转发。
接着进行下半部分的测试:把设备1从实验室搬到外面的走廊里。
此时三个设备都能互相发现对方。设备1和设备2的定向天线直面对方,RSSI居然达到了-36。设备1和设备2之间距离较大,定向天线方向平行,RSSI测量值-55也算比较理想了。
设备2检测到的信号强度:
设备3检测到的信号强度:
还是4Pairs测试,此时速率已达到达到24Mbps。考虑到802.11a54Mbps的理论值,这个值已经相当高了。
网卡统计数据。此时设备2转发的字节数增加了50MB,说明有少量报文似乎还是通过设备2转发的,但是大部分直接由设备1发往设备3。
6月14日
和常见的AODV模块一样,AODV-UU需要一块支持ad-hoc模式的网卡,因此同样存在链路速率无法超过54Mbps的问题。
因此考虑将开发平台的操作系统暂时迁移到OpenWRTx86。
6月16日
该wiki列表的Building子项包括以下子页面:
为了应用来自OpenWRT论坛的两个补丁,首先需要下载源码,安装相应的工具链,编译,制作镜像,然后测试在该补丁生效时ad-hoc模式的实际传输速率。
关于ad-hoc模式的HT支持目前还查阅到另外两个邮件列表中的回复(其意义尚待确定):
6月17日~6月18日
编译前首先下载各必须的软件:
sudoapt-getinstallsubversionbuild-essentialbashbinutilsfastjarflexgit-coreg++gccutil-linuxlibgtk2.0-devintltoolzlib1g-devmakelibncurses5-devlibssl-devpatchperl-modulespython2.6-devrubysdccunzipwgetgettextxsltproczlib1g-dev检出OpenWRT源码:
mkdir~/openwrtcdopenwrtsvncosvn://svn.openwrt.org/openwrt/trunk/cdtrunk安装更新:
./scripts/feedsupdate-a./scripts/feedsinstall-a配置编译选项:
makemenuconfig编译过程将产生一个TUI界面,其中大多数项目保留默认值即可,但是需要将目标平台类型修改为x86。
最后开始编译:
make编译过程将产生一个非常紧凑的输出,如果读者曾经学习过LFS,或许会对输出信息感到比较熟悉。在执行部分步骤时,OpenWRTBuildRoot将从网络上下载源码,因此整个过程非常缓慢,总耗时预计有10小时左右,之后进行的重编译则不存在这个问题。
6月19日~6月22日
各种毕业活动终于告一段落了,宿舍从B9搬到了B16,然后办了个临时宽带。铝板已下单,预计明天发货,发票需要等到星期一再发货;MIMO天线和转接线准备明天再订。
6月23日
天线和MMCX转接线已订,准备开始测试OpenWRT补丁下ad-hocht模式的传输速率。
6月24日
之前订的铝板今天中午刚收到,铝板的发票和MIMO天线估计明后天才能到。
再次作个小结。目前的主要目标是解决ad-hoc/mesh网络多跳高速传输问题,各节点构成一个链状结构,各节点同时产生视频数据流,预计总流量将达到60~90Mbps。开发板的处理器类型为嵌入式x86,无线芯片类型为AtherosAR9223。开发板使用的操作系统是VoyageLinux。
1.关于驱动程序
Atheros无线网卡在Linux下可用的驱动程序有两个:ath9k/mac80211和madwifi。ath9k支持的模式有以下几个:
2.关于天线的选用
3.关于IBSS的速率问题
4.关于Linux下AODV协议的实现
多个开源项目实现了AODV协议,其中较新的一个是AODV-UU。AODV-UU实现了一个支持AODV协议的内核模块,支持Linux2.6内核。AODV-UU需要无线设备支持IBSS(ad-hoc)模式,由于天线问题尚未解决,IBSSHT模式速率测试尚未开始,AODV-UU的实际吞吐测试也仍未开始。
5.链状ad-hoc/mesh网络的替代方案
6月25日
重新确认了一遍,iw不支持NW362(Realtek8192CU),所以NW362/开发板IBSSHT模式互联测试暂时取消。目前静候MIMO天线中。
6月26日
花了两个小时用AB胶把隔离单元粘起来了,然后依次摆在桌上。
每个隔离单元由四块240×240×5mm的1060铝板组成,粘和后构成一个方形管道结构。隔离板共12块,包括250×260×1mm和250×260×2mm铝板各6块,用以调节各单元间的信号衰减。
今天也向通信专业的一位老师请教了一些关于MIMO天线的问题。为了提高信道独立性,天线间距的一个合适取值是λ/2,对于2.4GHz电磁波来说,也就是6.25cm。在之前的测试中可能并未注意这一点,而造成了速率不稳定的情况。
6月27日
中午收到天线后首先进行了Station/AccessPoint模式下的速率测试。
经过简单的距离和角度调整后,TCP的发送和接收窗口大小设置为4M时,单线程传输速率可以达到约80Mbps,这个速率已经比较正常了。但是当两对天线的间距非常小时,传输速率依然较低。
之后进行了ibss(ad-hoc)HT模式的测试。下载iw的源码iw-0.9.22.tar.bz2,和来自OpenWRTbackfire分支的补丁:001-nl80211_sync.patch、100-rx_rate.patch、110-fix_rate_calculation.patch和120-ibss_ht.patch并编译。然后输入以下命令
./iwwlan0settypeibss./iwwlan0setchannel3HT40+./iwwlan0ibssjointest2422HT40+ifconfigwlan0up此时双机的连接速率依然是54Mbps。
而后再次进行了meshpointHT模式的测试:
6月28日
下午对AR9223WDS模式的配置进行了初步的探索。OpenWRTbackfire10.03.1并不支持AR9223;而在Voyage0.7.5(Kernel2.6.38)中,LinuxWireless文档中描述的指令
iwphyphy0interfaceaddwds0typewdsiwdevwds0setpeer
7月2日
之前提到OpenWRT社区提供了iw的ibssht模式补丁,而ath9k邮件列表中则提到了iw的meshht模式补丁。因此猜测用户空间程序iw在对HT的支持上处于一个相当重要的位置。
其中文件nl80211.h提供了一份较为详尽的接口文档。
对nl802.11h进行了初步的解读。该文件用60%的篇幅对nl80211中的命令(Commands)和参数(Attributes)进行了描述。
Commands即驱动程序/硬件可接收的指令。
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时的运行截图:
其它图片就不再列出了。下面使用一个表格对测量数据进行汇总。
对应的折线图如下所示。
可见在n*(λ/2)与与(n+1)*(λ/2)之间通常会存在一个波谷。而当天线的距离较近时速率均较低。可见当距离取值合适时,采用两根棍状天线的吞吐量已经和USB网卡内置的微带天线的吞吐量没有多少区别了。
7月6日
传输速率依然使用iperf,采用三次测量取均值的方式进行。测量数据如下表所示:
当距离较近时,NetworkStumbler显示的信噪比始终为-45dbm,然而实际传输速率并不相同。当距离更远时,速率随着信噪比降低而减小。折线图大致如下所示:
7月7日
对用户空间程序iw0.9.22进行了初步的分析。
iw程序的主要职责是对命令行参数进行解析,然后通过NLA_PUT_XXX等标准接口对驱动程序进行操作。下面展示了一段典型的解析及参数调用代码片段:
staticintjoin_ibss(structnl80211_state*state,structnl_cb*cb,structnl_msg*msg,intargc,char**argv){char*end;unsignedcharabssid[6];unsignedcharrates[NL80211_MAX_SUPP_RATES];intn_rates=0;char*value=NULL,*sptr=NULL;floatrate;intbintval;if(argc<2)return1;/*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')return1;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升级到最新版本,然后仅当最新的程序仍旧无法满足需求时才有必要自己动手阅读并修改源码。
在之前翻阅CompactWireless的Changelog的过程中,发现最近的更新包含了大量关于MeshHTProtectionMode的更新。
据估计,即使是当前VoyageLinux的最新版0.8.5也无法满足高速Mesh网络的需求。接下来的第一个目标是更新ath9k驱动和iw到最新版3.5,并重新测试HT模式的可用性。
7月8日
开始编译compat-wireless和iw。选用的compat-wireless版本为3.5-rc5-1-sn,iw版本为3.5。
在运行Ubuntu10.04.4的Linux系统(3.0.0内核)下,二者能够直接通过编译。但是在Voyage系统下进行同样的操作时遇到了一系列的问题。
首先是linux-headers。VoyageLinux0.8.5官方的源中并未提供linux-headers-3.2.17-voyage,因此驱动程序的编译显然就无法进行。将Voyage的版本降至0.8.0之后,能够成功安装linux-headers-3.0.0-voyage,但是出现了另外的问题:
另外将Ubuntu10.04/3.0.0内核中的Makefile_32.cpu复制到Voyage下之后问题依旧。
7月9日
依照之前提到的帖子中的步骤操作:
执行tarxvjflinux-source-3.0.0-voyage.tar.bz2这一部居然足足用了一个小时,没固态硬盘的话就要做好心理准备了。
7月10日
Moduleloadingproblems
Firstly,makesurethatthecompat-wirelesspackagewascompiledwithGCCwhoseminorversionisthesameastheminorversionoftheGCCwithwhichthekernelwascompiled.Forexample,ifyoucompiledyourkernelwithGCC4.3.2,butyoucompiledcompat-wirelesswithGCC4.4.1,youmightruninto“Invalidmoduleformat”problems.Thesewillalsooccurifyou'vebuiltthepackageforadifferentkernelthantheoneyou'recurrentlyrunning.
其对应的错误信息如下所示:
7月12日
在VoyageLinux下下载内核源码linux-3.5-rc6,将内核压缩方式改为gzip,成功编译通过。但是在安装内核时出现问题。
Failedtoprocess/etc/kernel/postinst.dat/var/lib/dpkg/info/linux-image-3.5.0-rc6.120712.postinstline356
补充说明:虽然出现了该错误信息,但是新内核似乎已经正常安装了。重启后运行uname-r,显示当前内核版本为3.5.0。
VoyageLinux下Mesh+AP模式的配置
明天决定临时对802.11sMesh模式下多跳传输的性能进行一个测试。待测网络具有如下的结构:
MeshNetwork+----------------------------++------------+|||Client1.1|---MeshAPx---xNode1||Client1.2||||...||x------xMeshAP---+------------+|Client1.n||Node2||Client2.1|+------------+|||Client2.2||Node3x||...|||||Client2.n||||+------------++-----------x----------------+MeshAP|+------------+|Client3.1||Client3.2||...||Client3.n|+------------+n个Mesh节点以Mesh模式相连(在ath9k驱动的Mesh模式下,连接标准为802.11s,采用的路由协议为HWMP)。这里Mesh网络的实现效果大致相当于一个二层交换机,来自各节点的网络曾数据无需关心报文是如何转发的,只需知道网络已连同就可以了。当然,不同的路由算法和不同的具体实现方案下,网络的性能是会有相当大的不同的。
每个Mesh节点同时还以AP模式工作,在上图中,所有AP的ESSID都设置为相同的值MeshAP,这样当客户端移动时,可以在各接入点之间无缝漫游。
配置该网络涉及的操作非常简单。首先是修改hostap配置文件:
interface=wlan0driver=nl80211channel=3hw_mode=gssid=MeshAPwme_enabled=1ieee80211n=1ht_capab=[HT40+][SHORT-GI-40][DSSS_CCK-40]这里将信道设置为3,启用802.11nHT40+模式,SSID为MeshAP。
另外是修改/etc/network/interface:
此外,如果需要强制AP工作在HT40(300Mbps)模式,则需要对hostapd进行修改。这里不再赘述。
另外一个需要注意的地方是mesh0的MAC地址不能与wlan0的地址相同,否则在启动mesh0时,会出现如下的错误信息:
SIOCSIFFLAGS:Namenotuniqueonnetwork每个节点中mesh0的MAC地址需要分别进行配置。MAC地址和IP地址的配置是大规模布置节点时需要主要处理的问题。
7月13日
对ath9k下Mesh模式的HT支持情况重新进行了确认。在Voyage0.8.0(3.0.0Kernel)下,Mesh模式仅能达到18Mbps的速率。在安装CompatWireless3.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-----------------------------------------------------------------------ath9k956370mac802111918351ath9klinux-3.5-rc6-----------------------------------------------------------------------ath9k943170mac802111897101ath9kvoyage0.8.0(3.0.0Kernel)-----------------------------------------------------------------------ath9k818730mac802111571661ath9k当执行lsmod命令发现内核模块的大小发生了变化,就意味着驱动已经更新成功。
7月14日
今天完成了两项重要的工作:一是对铝板箱对信号衰减的影响进行了初步的测试,二是配置成功ath9k802.11sMeshHT40模式。
关于铝板箱的大致情况可参见6月26日的日志截图。将四块240mm×240mm×5mm用AB胶粘成一个方形作为屏蔽单元,然后使用240mm×240mm×1mm铝板和240mm×240mm×2mm铝板作为隔离板,用来调节信号衰减。
之前在Voyage0.8.0系统下编译compat-wireless-3.5-rc5-sn驱动程序,同时更新iw到3.5版,发现调节发射功率的命令不起效果。
iwconfig命令为:
iwconfigmesh0txpower0dBmiw命令为:
iwmesh0settxpowerfixed0dBm执行以上两条命令后均无错误消息,但是iperf测得的传输速率却没有明显变化,因此考虑使用铝板对信号衰减进行调节。按照预期,当不使用铝板时,传输速率应该较高,而当中间的隔离板逐渐变厚时,速率将逐渐下降。然而实测结果和预期完全相反。
把隔离板厚度调节至2mm。PING值算是正常一点了,速率上升到了11Mbps。
继续加铝板,厚度调节至4mm。PING值更低了,速率上升至16Mbps。
最后把隔离板厚度调节至6mm。PING值依然很低,速率居然飙到了46Mbps,这已经是HT20模式的理想值了,学通信的同学快来解释一下吧。是不是铝板粘的时候粘歪了,然后各种细小的缝隙形成了微妙的天线呢?
隔离单元的测试暂时告一段落。接下来将讨论AR9223/ath9k下MeshHT模式的配置。之前曾经尝试过以下的命令:
结果Mesh接口终于能够工作在HT40模式下了:
这个方案的背后其实存在一个假设:一块无线网卡的底层传输仅能工作在一种模式下:或者11g,或者11nHT20,或者11nHT40,以此类推。之前的问题是hostapd能够(通过修改源码)成功强制进入HT40模式,最新版的iw则通常无法进入HT40模式。于是,在强制hostapd进入HT40模式以后,mesh0也就顺理成章地进入HT40模式了。
HT20/HT40问题有时并非是程序的Bug,而是一个设计策略。不过相信在不久之后这个问题会有一个更好的解决方案。
7月15日
对最新驱动下IBSSHT40模式的传输速率进行了测试。
IBSS模式相对于Mesh模式有几个不同。其一是虚拟接口的个数:使用Mesh模式下,用户可以建立一个mesh0接口,建立一个wlan0接口,然后运行hostapd使wlan0工作在AP模式下。但是使用IBSS模式,当wlan0已启用时,IBSS模式接口adhoc0则无法启动,当用户执行ifconfigadhoc0up时系统会给出以下提示:
SIOCSIFFLAGS:Deviceorresourcebusy也就是说,AR9223在compat-wireless-3.5-rc5-sn驱动下不支持AP+ADHOC模式,但是却支持AP+MESH模式。
第二个不同点同样也给ADHOC模式带来了局限性:ad-hoc模式的接口是无法桥接的。当用户试图将adhoc0接口加入br0时,会得到如下的提示:
can'taddadhoc0tobridgebr0:Operationnotsupported为什么会有这个提示呢?因为在ad-hoc模式下,每个节点只能是一个单一的个体。一旦进行了桥接,从该ad-hoc接口发出的报文就会拥有多个mac地址,而这是不符合设计规范的。Mesh模式则允许这种情况。
最后再展示一段配置程序,在compat-wireless-3.5-rc5-sn驱动下,相邻两个adhoc节点间的互联速率可以达到80Mbps,显然HT40模式已经能够正常启动了。
ifconfigwlan0down#关闭所有其它无线接口iwphyphy0interfaceaddadhoc0typeibssiwadhoc0setchannel3HT40+#这一步大概可有可无ifconfigadhoc0upiwadhoc0ibssjoinadhoc2422HT40+再次强调一下,IBSSHT40模式的成功配置需要多个因素:最新版的驱动(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日
使用之前购买的联想天线测试两节点间的传输速率。MeshPoint2(下图中的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日
将MeshPoint1(下图中的AP1)固定在505室并进行相同的测试。这个场景中的AP1天线采用两根间距为25cm的独立棍状天线,其吞吐率略高于联想天线,而移动测试点使用联想天线。
以45°角穿一堵墙,速率约为84Mbps。
以0°角穿一堵墙,速率约为97Mbps。
以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测试数据,详情稍后补上。