Hello murf,

In my experiments with 'pass' (v5.7.3), I found strange behavior like you 
describe if I tried to handle leaf-nodes of the OID-tree.  I am not sure from 
your description if "each value" you are trying to pass is a leaf or not.


Based on working pass script examples I found 
(https://sourceforge.net/p/net-snmp/code/ci/master/tree/local/passtest), pass 
appears to work if an OID tree-node is 'passed', but not a leaf node.  This 
behavior, despite my leaf-node pass script providing proper responses to the -n 
and -g inputs for all OIDs presented.   I attempted to 'pass' one leaf of the 
existing ifAdminStatus tree, and let the snmp agent handle all the other 
leaves, but I couldn't get this to work -- only worked if I used 'pass' on 
ifAdminStatus node itself, but then I had to handle all of the interfaces 
(leaves) in my script.


I would love to hear more from users who have successful experience using the 
'pass' construct, and whether my understanding of the limitation is correct.


Regards,
Alan





________________________________
From: Steve Murphy <m...@parsetree.com>
Sent: Thursday, May 10, 2018 1:56:25 PM
To: net-snmp-users@lists.sourceforge.net
Subject: snmpgetnext weirdness

I'm using snmp v. 5.7.3, built on centos from source code.
I have my own MIB, which I validated via a web validation site.
My MIB has 12 tables, and a total of about 80 individual values.
I have a large snmpd.conf file where I have "pass" lines for each value.
example: pass .1.3.6.1.4.1.50805.3.7.8.1.2  
/usr/bin/check_log_growth-snmp-security
50805 is the assigned number for our company.
Every one of the 12 apps is able to handle the -n option, and return the next 
value
in the list, both OID and value, as the passtest example in the release shows.
Every app is responds with a -n request with the next app in the list, the 
first OID,
when the last element is requested. So, all 12 apps are linked like a 
daisy-chain together.

my call to snmpgetnext:
snmpgetnext -v 2c -Cf -c nexvortex localhost -m NEXVORTEX-MIB 
.1.3.6.1.4.1.50805.2.4.1.6

In response, I get:

NEXVORTEX-MIB::nVCheckSECURITYLogGrowthEntry = INTEGER: 0

So what's my beef? I have a few:
1. The next element after 2.4.1.6 is 2.4.1.7, and the one returned is 3.7.8.1.2
    (It does call the proper app and gets the right stuff back, but, wow, it 
just kept on going!
2. My twelve apps were nearly all called, over 100 app calls made. It looks 
like it
    did a fairly complete walk from the given starting point.
3. During the walk, I see my apps being called with values out-of-range. For 
example,
    if I have a table with 15 values, 1-15, I see calls to xxxx.16 for that 
table.
4.  I get differeing results between test runs. For snmpgetnext calls, usually 
I get
    "Timeout: No Response from localhost." or an object not found type message.
    If I slow the test scrip[t down, it has a better chance of completing. I 
usually have
    to restart the snmpd daemon to get working again.

So, in other words, snmpgetnext goes nuts.

Anybody seen this kind of thing? Any advise of stuff to try? Any theories?
I'm waaaay behind schedule setting up monitoring as it is.

murf


--

Steve Murphy
NexVortex

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

Reply via email to