有个项目让我印象特别深。客户那边本来有一套用了三年的Aruba无线网络，跑得好好的，后来因为合规要求要上WiFi认证系统。按理说这就是加一套Radius服务器、配一个Portal页的事情，结果项目从计划两周变成了折腾了快两个月。

同一个厂商不同型号的AP行为都不一样

最让人崩溃的是AP兼容性。客户那边不是一次采购的，三年里陆陆续续买了四五批AP，型号从AP-205到AP-515都有。同一品牌、同一系列的设备，照理说配置方式应该一致，但我们后来发现根本不是这么回事。

老款AP-205的固件版本停在了一个比较旧的版本上，它不支持我们想要的CoA（Change of Authorization）功能。CoA在WiFi认证系统中是一个非常重要的能力——当用户套餐到期、或者管理员在后台手动踢人、或者策略变更的时候，Radius服务器需要通过CoA报文通知AC/AP实时调整用户的网络权限。如果没有CoA，就只能等用户下次重新关联的时候才能应用新策略，中间可能有几十分钟到几小时的"真空期"。

更麻烦的是Portal重定向的行为差异。同样是Aruba的设备，AP-315在Portal认证场景下会把用户的HTTP请求重定向到认证页面，这个重定向是通过HTTP 302实现的，标准行为。但AP-505在某个固件版本下，重定向用的是HTTP 307，而某些老款Android手机对307的处理有问题，会直接报错。最后我们通过全网固件升级和AC侧配置参数调整才解决，但这个过程浪费了大量时间去定位问题。

多品牌混网的场景更是噩梦

如果全是一个品牌还好办，至少你可以找原厂技术支持。怕的是那种因为历史原因多品牌混网的场景。我碰到过一个园区，办公楼用的是华为AP，宿舍楼是H3C的，体育馆和食堂用的是一批锐捷的设备。三种品牌的AP挂在不同厂商的AC下面，需要统一对接一套WiFi认证系统。

第一个问题是Radius属性字段的差异。华为和H3C在Called-Station-Id字段里放的是AP的MAC地址，锐捷放的是AP的名称。你要在Radius服务器上写策略——比如说"只允许特定区域的用户使用特定套餐"——就得根据Called-Station-Id来判断用户从哪个AP接入的。如果这个字段三家都不一样，策略就写不了。

第二个问题是VLAN下发方式的不同。在802.1X认证成功后，Radius可以通过Tunnel-Private-Group-Id属性告诉AC把用户划分到哪个VLAN。但有的厂商要求这个值填VLAN ID（数字），有的要求填VLAN Name（字符串），还有的要求格式是"VLAN=123"。如果你配错了格式，AC直接忽略这个属性，用户就掉进了默认VLAN里，认证成功但上不了网，排查起来极其痛苦。

AP侧日志的缺失让故障定位靠猜

WiFi认证系统出问题的时候，通常会有两个视角。一是Radius服务器的日志，能看到认证请求有没有到、认证结果是接受还是拒绝；二是AC的日志，能看到用户关联状态和策略下发情况。但AP本身往往是一个黑盒——很多AP默认不开启debug级别的日志，就算开了，日志也只在内存里缓存一小段时间就覆盖了。

有一次一个用户反复反馈"连上了但过几分钟就掉线"，Radius和AC的日志都干干净净，看不出任何异常。后来我们联系AP厂商技术支持，远程开启了AP的无线debug日志，才发现是用户终端在802.11r快速漫游过程中，PMK缓存没有正确更新，导致四次握手失败。这个问题严格来说不是WiFi认证系统的锅，但用户不关心是谁的锅，他只知道"认证连不上"。

所以后来每次做WiFi认证系统项目，我都会在实施前做一件事：把客户现场所有型号的AP都拿一台出来，搭一个最小化的测试环境，把认证流程从头到尾跑一遍。不跑不知道，一跑总能发现几个兼容性问题。提前发现和排期的代价，比上线后找厂商扯皮小太多了。