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
};

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测试数据不太稳定，重新对其进行测试。

优质内容筛选与推荐>>
1、安装apache Unable to correct problems, you have held broken packages
2、csdn排名第一的连接
3、arts-week12
4、tomcat启动时自动加载一个类 MyServletContextListener
5、大一下 校软C++ 考核试题