FreeRadius会话开始时间异动咨询：排查数据差异成因

1. FreeRadius会不会主动修改已入库的会话开始时间？ #

原生FreeRadius不会主动维护或修改已入库的会话开始时间。它的计费数据更新完全依赖WiFi控制器（AC）发送的RADIUS报文：

• 会话初始的开始时间来自AC发送的Accounting-Request(Start)或Access-Accept报文中的Acct-Start-Time属性。
• 后续只有AC发送Interim-Update（中间更新）或Stop（会话结束）报文时，Radius才会更新会话的结束时间、时长、流量等字段，默认不会触碰已记录的开始时间。
• 除非你在Radius的配置里写了自定义unlang脚本，强制覆盖Acct-Start-Time字段，否则原生逻辑不会触发这种修改。

2. WiFi控制器允许修改会话开始时间吗？ #

主流品牌的WiFi控制器（比如Aruba、Cisco Meraki、Ruckus等）大多支持在特定场景下修改会话开始时间，并同步给Radius服务器，常见触发场景包括：

• 会话重连续期：部分AC会把用户短时间内断开又重连的会话合并成一个，此时会用最新的连接时间覆盖原会话的开始时间。
• 时钟校准：如果AC的本地时钟通过NTP同步修正了时间偏差，可能会回溯修改未结束会话的开始时间。
• 手动运维操作：管理员在AC后台手动调整用户会话的时间属性，会同步触发Radius的记录更新。
• 会话异常恢复：AC处理会话中断故障时，可能会修正会话的时间参数并同步给Radius。

3. 这种现象是Bug吗？ #

这不一定是Bug，得看具体触发原因：

• 如果是AC按照预设的业务逻辑（比如会话合并、时钟校准）触发的时间更新，属于厂商设计的正常行为，不是Bug。
• 如果FreeRadius在没有AC报文触发的情况下自行修改了开始时间，或者AC毫无理由地频繁修改历史会话的时间，那才可能是软件Bug（比如AC的会话管理模块逻辑出错、Radius的数据库驱动异常）。

修正数据处理逻辑的建议 #

• 先查AC配置：确认是否开启了会话合并、重连续期这类可能修改时间的功能，了解厂商的具体行为逻辑。
• 检查Radius配置：查看radiusd.conf、sites-available/default等文件，确认有没有自定义脚本修改Acct-Start-Time。
• 给数据库加审计字段：新增last_modified记录每条会话的最后修改时间，再添个modify_source字段标记是AC报文触发还是系统操作，方便追溯变更。
• 统计时区分时间版本：如果会话开始时间被多次修改，建议保留所有历史版本，根据业务需求选择统计维度（比如用首次记录的开始时间，还是最后更新的开始时间）。

内容的提问来源于stack exchange，提问作者João Bastos