Hi list members, I am trying to define two pass persist entries in the configuration file which link MIBs to two different pass-persist scripts. The two MIBs for these entries overlap:
pass_persist .1.3.6.1.4.1.1192.1.1 /my/path/script1 pass_persist .1.3.6.1.4.1.1192.1.1.11 /my/path/script2 The intention of this is to have script1 handle all variables in our MIB, except for the .11 subtree, which needs to be handled by script2. I'd think this is not such an exotic wish if you have an enterprise MIB that goes beyond the most basic. I identified this nesting as a potential problem early on, but a bit of Googling reassured me that the more specific definition would take precedence, and that if all else failed there was a priority flag to take control over this precedence. Now, much development of the script later, it turns out not to work at all. The reassuring Google statement on hindsightwas about the 'proxy' module only, and could not be extrapolated to be of any value for pass_persist. The priority flag just plain doesn't work. This is confirmed by a thorough look at the source code in pass_persist.c. The pass_persist definitions are lexicographically ordered (ascending) and for a GET operation, and looped over. The first matching definition is used. In my case, for a GET of .1.3.6.1.4.1.1192.1.1.11.1.0 this incorrectly runs script1, which returns a NONE for this variable, and that's where it ends. The priority flag is not implemented beyond storing it with the MIB metadata. It is never consulted when looping to find the right extension. Question A) Can any of you confirm that what I am seeing is correct? Did I misinterpret anything? Besides integrating the two scripts or using another OID for script2, I am considering the option of fixing the code to act in the way I expected it to work, meaning: always take the most specific definition (= longest match) first. I would then bundle that adapted build of net-snmp with our product. Question B) Pass & Pass Persist are badly documented let alone specified, so it is hard for me to say that the current implementation has a bug. I can only say that it works differently than I thought it would. Who of you agrees that my interpretation is the correct one? Should I submit my 'fix' if I decide to rewrite this section? Thanks! Andre Blum ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 _______________________________________________ Net-snmp-users mailing list [email protected] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
