Menu
▾
▴
#713 override directive ignored with snmpbulkget
I noticed that when I disable a mib variable using the
override directive in the config file, I can still
retreive the value using getbulk.
for example:
override sysDescr.0 octet\_str "fubar"
then, I restart snmpd, then from another system, I run:
snmpbulkget -On -Cr5 -cpublic -v2c lab15 sysDescr
and I get back:
.1.3.6.1.2.1.1.1.0 = STRING: Linux lab15 2.4.20 #30 SMP
Tue Mar 18 14:12:02 CST 2003 i686
.1.3.6.1.2.1.1.1.0 = STRING: fubar
.1.3.6.1.2.1.1.1.0 = STRING: fubar
.1.3.6.1.2.1.1.1.0 = STRING: fubar
.1.3.6.1.2.1.1.1.0 = STRING: fubar
Found the problem just a few minutes ago and I hven't
had time to look thru the code yet, I'm also leaving
for some vacation later today. If somebody needs to
contact me, I'll be back on April 6.
Logged In: YES
user_id=40186
oops, version info follows:
: root; snmpd --version
NET-SNMP version: 5.0.7
Web: http://www.net-snmp.org/
Email: net-snmp-coders@lists.sourceforge.net
: home; snmpbulkget --version
NET-SNMP version: 5.0.7
debugging notes
snmpd -D -Lf output
Logged In: YES
user_id=88893
I've *finally* managed to track down what's triggering
this problem. It turns out to be the "out of range"
processing in the check_getnext_results routine, which
sets the 'inclusive' flag (erroneously in this case).
I think I've got a fix for this, but I'm by no means
certain of the implications of it. So for the time being,
I've just applied it to the main CVS development code.
As long as that doesn't throw up any significant problems,
I'll look at back-porting it to the earlier branches in
a week or two. Then hopefully we can finally nail this
bug once and for all.
Logged In: YES
user_id=76148
Ok, this is gonna be a long one, folks.
Dave, did you test your fix? In my cvs, as of today, the replication of fubar is fixed, but the first varbind still returns the standard sysDescr, instead of the overriden one.
There are several issues in play here.
1) The reason that the original sysDescr remains is in the bulk_to_next handler. If an answer is returned, it unconditionally sets for retry and then advances to the next variable.
Solution: check for end of range in netsnmp_bulk_to_next_fix_requests.
2) The reason for the repetions is that, as you discovered, inclusive has been set.
Solution: revert Dave's patch. Instead, when check_getnext_results discovers that range has been exceeded, set inclusive to 2 instead of 1. In netsnmp_bulk_to_next_fix_requests, if inclusive is 2, reset it to 0 after moving to the next variable in the request.
(An alternative that I explored was to check the current varbind agains the tree end when assigning the tree in the cache, and making sure that the request index + 1 didn't exceed the tree range end, moving on the the next tree if that test failed. This worked, but I'm not convinced that it would work for more complex cases (like table indexes that aren't scalars, or when there are indexes are non-contiguous)).
These 2 fixes fix the problem, and correctly set the overridden value and the move on to subsequent values. There might be some interactions with AgentX, the primary consumer of the inclusive value. We'll cross that bridge when we come to it.
3) On a related note, both Dave's fix and my above fixes caused an endless loop when the override was for an object in a table (eg hrStorageDescr.0). In this case, the problem was that the instance helper used for override was translating no value (ASN_NULL) and the NOSUCH* returns into ASN_PRIV_RETRY to trigger a retry (see revisions 5.11 and 5.12 of that file). However, I don't see how that could be right. RETRY will call the same handler again. For an *instance*, there is no reason to expect that if it didn't have data the first time, that it will have data on the next call.
Solution: The correct value should be ANS_NULL, causing the agent to move on to the next object in the tree.
The checkins for 5.11 and 5.12 didn't mention a test case, so I don't know if changing to ANS_NULL breaks something else, but the above test case (scalar override of sysDescr) and the test case for #3 (object in table) both work with all 3 of these fixes.
That's all for now! These fixes will also only be commited to cvs MAIN, and should be backported if nothing else breaks (or nobody finds a broken test case, or a better solution; solution for #2, in particular, is a hack).
patch for bulk override fixes
Logged In: YES
user_id=76148
Note that the override token has been broken in 5.1.x (including 5.1.2 and 5.1.3). However, I just fixed it for 5.1.4.rc1. This issue is now an issue for 5.1.4, as well. That is supposed to be scheduled for 3 days from now, which doesn't leave a whole lot of review for this fix. I've attached the patch backported to 5.1.4 below...
Logged In: YES
user_id=848638
So in what branches has this bug been fixed, finally? MAIN
(5.4-to-be) for sure and 5.1.x not (now EOL anyway), but
what about 5.2.x and 5.3.x?
Logged In: YES
user_id=88893
As far as I can tell:
Fixed: 5.1.x, 5.4.dev
Not: 5.0.x, 5.2.x, 5.3.x
Logged In: YES
user_id=848638
Are there any objections to commit this to 5.2.x and 5.3.x,
then? It looks strange to fix something in 5.1.x and 5.4.dev
only and not in the branches in between.
Logged In: YES
user_id=88893
Originator: NO
Fix applied to 5.2.x and 5.3.x lines.