AP_featuretest 总结

Zss 发表于:

———————————–    漫游性能测试(11r) ———————————-

1.测试环境:两台ap,一台cpe,均支持开启快速漫游功能,两台ap接入在同一个交换机上,一台pc1接入在此交换机上,

ap设置为两个相同的ssid,及其加密方式,设置cpe的漫游扫描阈值及其切换阈值和漫游前所扫描的信道,

cpe的阈值具体的设定可以根据cpe在两端的snr值来灵活设定,cpe端接入一台pc2,构造一个udp包,写入源地址为pc2ip和mac,

目的地址为pc1ip和mac,在pc2上发送udp包,平均5ms发送一个,使用cpe在两个ap之间漫游切换,在pc2上面使用wireshark抓包,无线侧使用omnipeek抓包

 

2.测试原理:当在此链路未连接的时候,pc2的报文无法发送到pc1,在接通的时候,报文平均在5ms左右到达目的端,

当cpe连接在ap1切换到ap2时,中间是存在一段报文无法传送的过程,那么使用ap2第一个所接收到的报文的时间减去ap1所发送的最后一个报文的时间,

这段时间差就是漫游切换的时间

 

3.11r和普通漫游分析:

11r快速漫游时,抓包看到cpe先向ap1发起action管理帧,中间包含fast bss request,ap1收到后确认请求回复一个同样带有fast bss rsp的报文确认,

cpe再次向ap2发送连接Reasscation请求,ap2发送响应给cpe

 

4.数据计算:

在无线侧抓取的快速漫游ap发送给cpe的reassociation响应时间减去cpe发送给ap的ation请求时间,则是无线侧的漫游时间

在有线侧则需要导出所有数据包,筛选为udp包,保存为csv文件,使用word公式计算两个udp之间的时间差使用柱状图来显示最高点则是漫游时长

因为测试每次计算的时长需要时间来使用word计算,速度可能比较慢,所以用python写了一个通过源ip和目的ip和协议来过滤计算csv文件中排行前十的延时,并打包成exe

 

———————————–    Bandsetting     ———————————–

1.作用:

因为2.4g频段的设备越来多,蓝牙 ziggbee等无线设备可能都在使用这个免费的频段,导致频段越来越拥挤,

且2.4g信道也有限,但是5g信道很多,信道非常空闲,所以采用一种将双频终端迁移至5g的手段来解决信道拥挤的问题

 

2.测试方向:

  • 对于已关联的终端
  1. 若sta是4g单频终端,无法被提至5g
  2. 若sta是单频5g终端,无须移动
  3. 若sta是双频终端且在4g上,需要模拟环境来剔至5g
  • 对于新接入的终端
  1. 若sta是4g单频终端,连接时ap会以一种消极响应的方式来回复sta收到多个探测请求时才会响应一个探测响应,保证2.4g也能接入到ap中
  2. 若sta是5g,正常响应,正好接入
  3. 若sta是双频终端的话,那么ap收到了两个频段的探测请求,ap只会响应5g的探测请求导致4g无法接入,正常接入到5g

模拟环境:

调节ap的2.4g信道利用率过载,及sta的rssi较低,且此时sta处于非活跃状态,非活跃状态可以未在做即时的数据传输

 

———————————–    Mac clone  ———————————–

当开启动态mac clone的时候ap上显示repeater下所介入的sta,此时变成了三地址传输,

相当于pc1直接介入到了ap,pc1与ap,ap与pc3的数据交互

当未开启mac clone时,ap上不会显示repeater下的sta,此时变为了四地址传输,相当于中间隔了一个repeater设备

测试内容,抓取ping无线报文,当开启时为三地址传输,不开启为地址传输,和静态的mac clone 动态+静态mac clone ,和一些基本的网络通信是否正常

 

——————————————    HNAT    ———————————————–

双网口设备:

一个网口作为lan侧,一个做为wan侧,使用两台pc分别连接,设置为不同网段地址,开启hnat功能后lan侧pc正常ping通wan侧pc,跑流lan到wan的转换可以到800m

 

———————————–     Arp代理    ———————————————————–

 

1.目的:为解决链路中过多的arp广播报文传输

2.组网环境:

一个项目中ap中接入了80个终端机器人,造成过多的arp报文导致过多的网络资源消耗导致瘫痪