Hi all, I'm new to the list but old to Net-SNMP and other agents with CMU / HP ancestry (used to be a developer on SystemEDGE until right after CA ate the project and spat me out).
About sixteen months ago I created issue 2340904 in the tracker describing an Integer32 overflow problem with the non-perentage objects in the dskTable when the filesystems they represent are 2TB in size or larger. There's been a burst of conversation now and then, but no strong consensus on what to do about the problem. I just had a short IRC conversation with Robert Story that culminated in my coming to this list to try to build some forward momentum. So here is my appeal. At its technical base, this issue boils down to a failure to truncate a value before marshaling it into a response varbind. This problem results in the agent sending response PDUs that RFC-compliant command generators* (i.e. managers) must discard because they are malformed. The encoding of the suspect values will look something like: 02 05 02 d3 c0 65 fe The reason I'm passionate about this bug is that it's inhibiting real people from using RFC-compliant managers to monitor filesystem capacities, and some of those people are our customers. I have no desire to maintain a fork of Net-SNMP, but I do plan to be around long enough for the 5.5 release train to make its way into popular distributions. I know that there are contentious decisions to be made about how to change the MIB so that users can get good and accurate data on 2TB or larger filesystems. Should we (mis)use a Counter64? Commit ultimate heresy and provide a string for managers that know how to parse one as a number? Do the technically-best-but-highly-incompatible thing by using an opaque UINT64? I'd like to lay aside this question for the moment and propose that something be done about the technical base of the issue: can we please start by capping those objects' values before we marshal them? It's far from a complete fix, but it at least enables managers that strictly follow the BER to talk to Net-SNMP agents. Thanks for your time and consideration, -jeff [*] Manager toolkits I've tried that can't cope with these response PDUs: SNMP4J (as part of OpenNMS), SNMP Research EMANATE (as part of OpenView NNM). -- Jeff Gehlbach mailto|sip:[email protected] The OpenNMS Group, Inc. ph: +1 919.533.0160 x7754 ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
