某局点采用iNode进行无线Dot1X认证频繁发生连接中断问题处理经验案例

一、组网

某局点采用无线V7 WX5540H IRF设备进行提供无线服务，同时配合IMC+iNode客户端对终端笔记本进行Dot1X认证，对接入用户进行身份控制。

二、问题描述

该局点WX5540H与Dot1X相关的配置均按照无线典型配置进行，没有存在奇怪的多余配置。当客户现场某一天对现网的iNode客户端进行统一升级之后，便会零星的出现个别终端采用iNode认证时提示连接超时，需要检查网络配置。客户也通过windows自带的1X客户端进行认证接入，并没有类似的故障体验。

该问题从最直观的观察角度来说，确实与某次iNode升级有直接关联，但是我们需要协助用户查清问题根源，并且明确AC无线系统是否真的存在问题。因此我们先从最容易操作的AC设备debug日志来分析。

针对这个故障可以先明确与Dot1X有直接关联的模块，即

<V7AC>debugging radius all user XXX        //针对特定账号debug

<V7AC>debugging dot1x all

<V7AC>debugging wlan access-security all //必须打开，不然无法显示上述两个debug信息

<V7AC>debugging wlan mac client AAAA-BBBB-CCCC

<V7AC>debugging wlan mac all  //针对特定终端mac地址debug

按照现场复现故障终端mac地址为c48e-8f1b-0d05进行检索日志：

终端加入wlan之后进行1X认证阶段，在EAP阶段首先AC收到来自终端的认证开始报文

*Mar  1 09:37:41:008 2018 XXX-WX5540H-01 STAMGR/7/PktRcv: [MAC: c48e-8f1b-0d05, BSSID: 703d-157a-9530]

-----Packet HEAD-----

Mac Frame Type: 0x888e

Protocol Version ID: 0x1

Packet Type: 0x1         //认证发起帧，终端向AC发送的认证开始报文

Packet Length: 0

然后是AC向终端发起的认证请求；

*Mar  1 09:37:43:060 2018 XXX-WX5540H-01 STAMGR/7/PktSend: [MAC: c48e-8f1b-0d05, BSSID: 703d-157a-9530]

-----Packet HEAD-----

Mac Frame Type: 0x888e

Protocol Version ID: 0x1

Packet Type: 0x0

Packet Length: 5

-----Packet Body-----

Code: 0x1                             //EAP Code 1，代表Request 

Identifier: 1

Length: 5

紧接着终端回复了一个Logoff，这个显得有点奇怪；

*Mar  1 09:37:44:239 2018 XXX-WX5540H-01 STAMGR/7/PktRcv: [MAC: c48e-8f1b-0d05, BSSID: 703d-157a-9530]

-----Packet HEAD-----

Mac Frame Type: 0x888e

Protocol Version ID: 0x1

Packet Type: 0x2            // EAPOL-Logoff退出请求帧，客户端向AC发送的下线请求

Packet Length: 0

对比标准的EAP中继的1X认证流程；问题出在第三步，应该发送EAP-Response而非日志记录中的Logoff；并且按照常规模式这个终端应该在一次失败之后继续重认证，重新从步骤1到3再执行一遍。而非现在的再无后续动作的情况了。

在AC的Debug方向上来看属于终端某种判断机制造成了EAP交互中断，当然也就没有后续流程可言了，那么问题到底是出在哪里了呢？

我们可以观察到Debug日志中，终端发送的EAPOL-Start报文到AC回应的EAP-Request报文中存在了一个2S多时间的间隔，翻看其他终端的Debug信息发现凡是出现认证问题的终端认证行为都存在类似的时间间隔。

通过业软产品线的解释，在iNode软件版本E0506的时候对上述流程没有做任何时间限制，直到在软件版本是E0519之后加入了2S的时间限制，也就是在EAPOL-Start到AC回应EAP-Request之间如果超过了2S，iNode则单方面认为认证存在异常直接发送EAPOL-Logoff报文退出认证，同时在iNode客户端上提示认证失败，网络异常。而采用其他客户端进行认证则不会出现这样的情况。

至此该问题有了定位，首先由于AC在某些时刻存在业务并发的高峰AC处理时效存在延迟，又或者环境存在干扰和冲突造成了交互报文可能会被延迟送达的情况，再加上iNode客户端加入了一些比较严格的判断机制导致了该问题的发生。

因此我们解决该问题需要从两个方向入手：

1、增加AC处理报文的效率，通过采用无线AC通用优化指导，及对AC进行软件版本更新（新的软件版本在流程和算法都会有效率提高）。

2、协调iNode采用更加合理的等待时间窗口，例如5S等待时间或者加入自动重传的机制淡化报文回复超时带来的体验感。