一次低级的错误耽误了一周时间

春节前测试nas设备和freeradius服务器之间的联调。radius服务无论使用freeradius的radtest程序还是jradius的代码都测试正常。但是从nas设备发过来密码就是不正确。

开始以为是加密方式不一致，经过udp抓包比对都是pap方式加密，但是密码坚决不正确。前节因为没有太多时间就放假了，只能拖到节后调试。

春节在家闲着的时候又把rasius协议和jradius的实现全部看一遍。最后确定一定是nas端配置有问题。（事实证明这个正确的判断为找到问题节省不少时间）

由于nas设备部署在弹外，而且我没有权限登录，所以nas的配置依赖其他人检查。反馈说只有几个字段，而且以前也是这么配置的，原来的就可以正常工作。

今天早上配置的人突然告诉我说原来配置的32位的sharserct取回来只有25位，可能是太长被截断了。

可以立即判断问题的结症找到了，但是配置的人说如果sharserct错误，radtest直接报Incorrect sharserct而不应该是密码不匹配。凭着春节时间对radius协议的理解，

一定是这个问题，因为传输过程不可能传sharserct，radtest测试时服务端之所以判断Incorrect sharserct只是因为其它错误都被排除而乘下的唯一可能。而现在的情况可以认定99.99999%是因为sharserct不一致引起的。加密的种子不一致，怎么可能获得匹配的结果？

要求nas的配置重新配置为16位长度和radius服务端一致后，所有的一切都明亮了。

问题：

1.因为没有权限登录nas设备检查，只有几个简单的配置，对nas的配置人员有点太相信了。

2.其实昨天配置的人就发现了这个问题，因为经验不足，一直以为如果sharserct不一致应该报Incorrect sharserct而不是密码不匹配，没有向我反馈。

   其实用脚趾头想想也应该明白加密种子不一样怎么可能得到匹配的结果？

3.在密码不匹配时没有首先想到可能是sharserct不一致，思维短路了。正常情况下一样的算法得到不同的结果肯定是输入有问题，应该相想到有可能是sharserct不一致造成的。