Progress has been slow and painful mostly because of my own stupidity. I have been going nutz with authentication error while parsing INFORM packets from SNMPv3 agents and couldn’t find the fault only to find out that I was passing receive buffer length to the decode function and not received length resulting in a longer buffer padded with zeros and messing up with the authentication hash generation. Such is life…
That is fixed now and SNMPv3 INFORM and TRAP handling is moving into alpha (from pre-release) with a couple of hours of testing planned for next week against actual agents in the real world. I expect to have this nailed down soon and ready for release.
One thing I have discovered from e-mails I’ve been receiving is that high level of control while coding SNMP is not always desirable. To make it easier for people who just want to get to the data, I have created a SimpleSnmp class that will allow SNMPv1 and SNMPv2 request generation and reply processing with no or very little knowledge of how SNMP works.
I have replaced a lot of code based on other libraries implementations from the encode/decode methods in base type classes. This has taken some doing and a lot of debugging. To make sure this all works, I have written a testing server using a proven and stable C++ SNMP library and then written a whole lot of c# apps to send encoded data to it for verification. Just so you know, this is a bad idea and just the testing of Integer32 class has taken a better part of 3 days on a quad-core system I use for development.
Besides the “big” changes, I have been working on introducing higher level of consistency to class methods and properties. During development you tend to focus so much on delivering functionality that you forget that classes performing similar functions should have similar methods and properties. That work continues and I don’t think it will be fully done in the next release but at least I don’t plan to remove anything but just keep adding what’s missing.
Exception generation is another area that I have tried to put a little time into making it more sensible. In the earlier releases I have been creating exception classes as needed and ended up with a lot of them being used only once or twice. Again, work is far from over but reduction in the number of exception classes thrown and better notification of what went wrong is the goal. Introduction of error codes in each exception class so that caller can determine if it is fatal or recoverable (as most SNMP exceptions on a network manager are) should help.
At this point, I expect I’ll take TripleDES, AES-192 and AES-256 privacy classes completely out of the next release and target to re-introduce them later down the road when I have the time to finish implementing them. I work on the library away from agents that support these protocols so I am finding it very hard to find the time to spend in a lab testing code with all the other obligations I have. If you have a project that absolutely depends on these privacy protocols being implemented, let me know and I’ll see what I can do to speed things out but for now this functionality is out.
Check back often and look out for library release 0.5 no later then a month from now. This release will be the first “real” beta with all functionality included and tested as much as possible in the lab environment. This is where I’ll start doing the real world testing with the applications that are in the pipeline.