AC对接IMC认证portal mac-trigger无感知用户每隔一段时间后掉线需要重新认证问题

AC旁挂核心，本地转发，对接IMC，服务模板配置portal mac-trigger无感知认证

无

现场反馈AC从旧版本升级到最新版本后，第二天客户侧连接portal mac-trigger无感知服务模板的终端每隔~46 min出现portal掉线，需要重新认证的情况。

1. 由于故障很好复现，因此在IMC上开启UAM和Portal日志的debug模式，然后让一个已经复现的终端完成Portal登录后持续观察，果然过了45~46 min左右，这个终端下线，并且AC上portal表项消失，需要重新认证，而此时查看IMC的Portal日志（debug级别），发现是到达时间后IMC给AC发送了req_logout报文让终端下线，

这与案例：https://zhiliao.h3c.com/theme/details/220470 的情形类似，于是去IMC上查看配置发现果然有相关心跳超时的配置：

相关具体的机制不再赘述，需要注意的是：在IMC上将这两个参数调整为0（即关闭心跳功能后），只有在关闭此功能之后完成Portal登录上线的终端才会不再获得该心跳属性；而在关闭心跳功能前登录的Portal终端，还是会在45 min左右下线，此时再次登录如果是在关闭心跳功能之后，那就不再受心跳属性的影响而导致掉线。

2. 但是另一个疑惑点是：服务模板配置了mac-trigger无感知，终端到期portal掉线后应该可以通过无感知自动完成再次认证，并且检查IMC上无感知表项老化时间设置也比较长，复现故障时并未出现无感知表项消失的情况，难道是mac-trigger无感知没有生效？

3. 在解决了1的问题后，为了验证2的问题，在AC上通过：portal delete-user usrname xxx 删掉了某个终端的portal表项，来验证其mac-trigger功能，发现没有认证成功，于是在AC上开启debug portal等，IMC上也同步开启UAM和Portal的debug日志，然后复现问题，

一般的portal mac-trigger终端再次上线流程如下图所示【实验室内部环境示意图，IP地址等均不涉密】

排查发现：在mac-trigger无感知认证过程中，AC给IMC发送req_macbind_info后，IMC回复了ack_macbind_info（errorcode = 0），此时IMC应该给AC发送req_challenge (CHAP模式)或者req_info (Portal 2.0的PAP模式)，但是IMC却没有发送这个报文，导致AC上计时器超时mac-trigger认证失败；

4. 进一步将此信息反馈给IMC后，其反馈AC发送给IMC的mac-trigger报文（即req_macbind_info）由于是2.0版本的，没有携带：（EX_ATTR_START_TIME = 113 用户上线起始时间）字段，因此IMC会给AC回复ack_macbind_info （errorcode=0）后，不再给AC发送req_info或者req_challenge，导致无感知不成功。

5. 那么为什么AC发给IMC的mac-trigger报文是2.0版本，而且升级前没有出现类似故障呢？

询问执行变更的一线同事，并且查看AC的display history-command all，发现其在AC升级后，在原本的mac-trigger服务器下配置了：version 2

而至于为什么要添加这个配置，其给出的解释是看到IMC上下面这里配置了portal 2.0，误认为mac-trigger-server下的version也要一致，而实际是不需要的。

将AC上mac-trigger-server下的version 2执行undo恢复为默认的version 1，此时AC给IMC发送的req_macbind_info报文变为version 1版本，IMC不再校验其中：（EX_ATTR_START_TIME = 113 用户上线起始时间）字段属性，后续mac-trigger认证过程正常。