某局点802.1x认证，用户名带小数点时无法认证

设备型号：WX3520H

设备版本：R5446P06 

现场反馈结合第三方RADIUS服务器做无线802.1X认证，用户名带小数点“.”时无法成功认证，不带小数点时认证正常。
现场使用小数点不是作为域分隔符，是用户名中使用。  

现场不方便抓包，只收集了debug信息，收集的是debugging radius packet，没有过滤指定的测试的user信息，又由于debug radius打印的内容本来就比较多，因此在radius过程的请求和应答报文不一定紧挨在一起。

如果使用wireshark抓包工具，可以帮助解析出packet identifier这一参数，找到radius过程的请求应答报文的对应关系，便于确认radius过程在哪里出现了问题。

那么如何从debug中找到radius报文的请求与应答的对应关系呢？根据wireshark解析可以看到在报文的详细内容中，packet identifier参数对应的内容就跟在radius报文的code后面。下面我们就根据现场收集的debug信息进行分析。

查看debug信息发现，

*Oct 19 16:58:23:737 2021 z_AC RADIUS/7/PACKET:

    User-Name="a.ye"

……….

*Oct 19 16:58:23:739 2021 z_AC RADIUS/7/PACKET:

 01 f7 02 12 2a 18 b8 69 77 92 2b b9 63 70 e7 7c               \\ a.ye用户发起1号access-request报文，报文id是f7

……….

*Oct 19 16:58:24:740 2021 z_AC RADIUS/7/PACKET:

 03 f7 00 2c f2 7c 63 d0 3d dd 14 ff 74 8e f2 5f                    \\ 紧接着a.ye用户收到服务器发回的3号 access-reject报文，报文id也是f7，说明是前面1号报文的回复

……….                   

%Oct 19 16:58:24:741 2021 z_AC DOT1X/5/DOT1X_WLAN_LOGIN_FAILURE: -Username=a.ye-UserMAC=xxxx-xxxx-xxxx-BSSID=xxxx-xxxx-xxxx-SSID=emp_ix-APName=xxx-RadioID=1-VLANID=9; A user failed 802.1X authentication.Reason:AAA processed authentication request and return 26.                                  \\ 之后，日志报该用户1x认证失败

 这样就证明了是由于第三方服务器拒绝了AC发出的access-request，导致a.ye用户认证失败

由于服务器拒绝了AC发出的access-request，导致a.ye用户认证失败，需要第三方服务器侧排查拒绝原因