一年前吧，因为这一年来，这个博客都还没有来过，密码都忘记了，刚找回来。
有个交换机的自动化工作也已经开展起来，模块也分下去了。其他模块也就是使用Python开发即可，但是Rmon和SNMP模块就遇到了不小的问题。程序如何抓取交换机Trap或者Inform的消息会成为这两个模块自动化成败的关键。SNMPv1和SNMPv2c的Trap还好说，再不济也可以通过抓包的方式解决。SNMPv2c或者SNMPv3的infrom都需要服务器有回应报文。SNMPv3Trap或者Infrom如果带认证和加密的话，你通过抓包根本无法判定到底是因为什么原因的inform或者Trap。那么一个好用的Trap服务器就显得尤为重要了，可能看到这里，大家有可能会说，去网上下载啊！
我只想说，如果下的到，也不错，但是即使有类似于MIBBrowser这种现成的工具在手，自动化也是无用的。因为它们一般是图形化操作的，自动化对于带GUI的软件操作本就是个软肋。所以基本不可行。那么自行研究与开发就势在必行了。以下就是我从3月5日开始的研究结果以及个中心酸与大家做个分享。
网上有一个老外写的名为pysnmp的库，这个库大家使用pipinstall都可以轻松地安装。网上也有一个他们写的Trap服务器的例子。那么第一步自然是照着例子依葫芦画瓢咯。把他们的代码做了修改成一个类之后，一运行，喜出望外，SNMPv1和SNMPv2c的Trap消息都能够正常接收了。类似于下图这个样子
然而，事情远没有想象中的简单。我发现pysnmp的代码库中，我使用的这个模块根本就没办法得知获取到的Trap报文的版本。因为它的回调函数中传入的参数是PDU，PDU你知道是什么吧，它在报文中的位置是在SNMP版本之后啊。也就是说在这个回调函数里面我们已经看不到SNMP版本了的。没办法。而网上关于此问题的解答为0。网上所谓的pysnmp中文翻译或者外文资料简直是一无是处（本想用脏话的，算了。）。现在想想，我当时内心还是很强大的，没有放弃。
于是我准备通过修改pysnmp库里面的代码来解决这个问题。那如何解决呢？找到SNMP报文到底是在什么模块中剥离出整个SNMP的消息体的。现在看来可能貌似很轻松的样子，当时找起来可真没那么简单。最终通过各种定位手法，找到了在engine.py中有这个消息。于是我将整个消息体设置成了engine类的成员变量，方便我调用。
这样我在我自己的代码中用pythonmsg_version =api.verdec.decodeMessageVersion(self.snmp_engine.whole_msg)就可以获取到报文中的版本号了。至此，这个问题就得到解决了。
当我将我们交换机的Trap上报配置成SNMPv3，并且带认证加密的时候。这个时候啥都看不到，所以据初步观察，应该为加密的问题，为了验证这个结论，我将交换机配置成SNMPv3只认证不加密。这个时候发现打印的PDU里面的内容就正常了。所以进一步确认了这就是加密的问题。
那么接下来就是看一下这个问题出在哪里了。这个问题出在哪里了。怎么看呢？代码跟读是最好也是最笨的方式。依据自己写的代码，然后看到里面引用的一些函数，然后在这些函数的开始和结尾分别添加打印信息。运行一次，如果头尾的打印信息均出现了，说明问题不是出现在这个函数里面。如果后面的打印信息未出现，将后面的打印信息往前移。如果发现在函数中引用的另外一个函数里面出错，则如前面的步骤继续，如此循环往复。
最终被我发现了，它的加密方法是存在在它引用的一个mib节点变量中的。而这些mib文件因为目录的关系无法引入。所以这里出现了错误。如下图：
来这些文件按照代码里面的逻辑应当是放在这个地方的，然而它放在了那个instance目录中。所以导致它引入出错。再次验证之后，发现它仍然无法解密PDU，依据上面的方法继续验证。
还是通过上述的方法，最后找到了解密的地方，原来它一直返回DES对象为None。为什么会是None呢？原来是它try过滤了一下，如果引入失败，则返回DES对象为None，那么自然解不了密了。于是我尝试着使用它原本的名称去网上下载该库，最后发现这个库根本无法使用pipinstall安装，能安装的是Crypto。于是我将此模块安装完毕，将加密解密模块中原本的引入库文件名称全换成了这个。终于好了。
这个过程我花了三天时间，而且是在没有任何人能够提供指导意见的情况下，没点毅力还真不行。有些路终归是要一个人走的，走着走着也就会长大的，做技术就是这样。
联系客服
