OS:Windows 2003 Enterprise 32biterwan.l wrote:Hi Stone_II,
What O.S and snmptools version are you running?
Regards,
Erwan.
snmptools versioin:2.0.0.10 last modified on Feb 17th 2009
PS: Now the graph on cacti like so :
Windows performance counters & VBS/WMI via SNMP
Moderators: Developers, Moderators
Erwan,erwan.l wrote:Hi Temak82,
For the ini file, you can use any editor to do it.
You can define NT counters or vbs scripts.
Iptools will not make the ini file for you, but it will help you find the counter you are looking for.
Example :
[1.3.6.1.4.1.15.1]
counter=LogicalDisk\Free Megabytes\_Total
How to install it is detailed here : http://erwan.l.free.fr/snmptools/ .
Stick to the 32bits version for now, even on 64bits system as I have less time to support the 64bits version of snmptools.
Double click on regagentWow6432.reg and copy the DLL file to the windows folder then, not system32.
Restart snmp service and you are settled.
Regards,
Erwan.
Thank you for your reply! We will give this a whirl soon.
New version can change root OID with a registry key.
Everyone,
There is a new version available (made by Erwan, but from my feature request..)
You can now provide your own Private Enterprise Number (PEN) through a registry key.
Create a new REG_SZ with the root OID for the subagent, such as:
1.3.6.1.4.1.xxxxx
Where xxxxx is your actual PEN. Restart your SNMP service and snmptools will now be rooted in your own Enterprise branch.
PEN can be registered through IANA.org. This is useful for people defining their own MIB file. I believe Erwan is also going to register his own (as a default for this tool) instead of perusing an existing PEN.
Antoine
There is a new version available (made by Erwan, but from my feature request..)
You can now provide your own Private Enterprise Number (PEN) through a registry key.
Create a new REG_SZ with the root OID for the subagent, such as:
1.3.6.1.4.1.xxxxx
Where xxxxx is your actual PEN. Restart your SNMP service and snmptools will now be rooted in your own Enterprise branch.
PEN can be registered through IANA.org. This is useful for people defining their own MIB file. I believe Erwan is also going to register his own (as a default for this tool) instead of perusing an existing PEN.
Antoine
Nothing is as simple as it seems at first
Or as hopeless as it seems in the middle
Or as finished as it seems in the end.
Or as hopeless as it seems in the middle
Or as finished as it seems in the end.
Hello flukester,
Thanks for this advertising : I was too lazy to write about it.
I should make some documentation about the possible registry entries.
This new version also has more debug output that should help to trace the issue mentionned by Stone_II.
Now need to find out how to handle counters with "\" or "/" ...
Regards,
Erwan.
edit : "/" character is ok
18:54:50:546 , SnmpExtensionQueryEx
18:54:50:546 , nRequestType=SNMP_EXTENSION_GET
18:54:50:546 , GetRequest: OID=1.3.6.1.4.1.15.4 (8)
18:54:50:546 , GetPerf: path=System\System Calls/sec
18:54:50:546 , GetPerf: pdh_counter_path=\Système\Appels système/s
18:54:51:546 , GetPerf: vartype=Integer
18:54:51:546 , GetRequest: value=6131 asn_type=2
18:54:51:546 , GetRequest: OK
Thanks for this advertising : I was too lazy to write about it.
I should make some documentation about the possible registry entries.
This new version also has more debug output that should help to trace the issue mentionned by Stone_II.
Now need to find out how to handle counters with "\" or "/" ...
Regards,
Erwan.
edit : "/" character is ok
18:54:50:546 , SnmpExtensionQueryEx
18:54:50:546 , nRequestType=SNMP_EXTENSION_GET
18:54:50:546 , GetRequest: OID=1.3.6.1.4.1.15.4 (8)
18:54:50:546 , GetPerf: path=System\System Calls/sec
18:54:50:546 , GetPerf: pdh_counter_path=\Système\Appels système/s
18:54:51:546 , GetPerf: vartype=Integer
18:54:51:546 , GetRequest: value=6131 asn_type=2
18:54:51:546 , GetRequest: OK
Last edited by erwan.l on Fri Mar 13, 2009 3:42 pm, edited 1 time in total.
Problem with snmpwalk
Hello!
Thanks for the new version once again.
Now, the counters with the / in the name are working correctly. As instructed (by PM), I have removed my flag=norefresh from all the counters which give a per-second reading (all counters ending with "/sec").
The snmp gets are working correctly now, thanks! However, snmpwalk is not working.
If I try to do an snmpgetnext on the root OID or any other OID where I know there is a next element, I receive a "noSuchName" error (using snmpgetnext from net-snmp under Linux).
Could it be related to the new "OID" key in the registry? (I don't know how you decide on the chain of OIDs for the getnext requests). I noticed in the example counters file that there were no blank lines between these items and have removed the blank lines in my own, with no change.
Here is the simplified counters.ini file used for this test (with my PEN obfuscated):
[1.3.6.1.4.1.xxxxx.15]
type=string
counter=customWindows
[1.3.6.1.4.1.xxxxx.15.1]
type=string
counter=System
[1.3.6.1.4.1.xxxxx.15.1.1]
counter=System\File Read Operations/sec
[1.3.6.1.4.1.xxxxx.15.1.2]
counter=System\File Write Operations/sec
Here are the commands (net-snmp under Linux) that work fine, just for completeness (with IP address and PEN obfuscated):
[root@localhost ~]# snmpget -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx
SNMPv2-SMI::enterprises.xxxxx = STRING: "snmptools by erwan.l@free.fr"
[root@localhost ~]# snmpget -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15
SNMPv2-SMI::enterprises.xxxxx.15 = STRING: "customWindows"
[root@localhost ~]# snmpget -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15.1
SNMPv2-SMI::enterprises.xxxxx.15.1 = STRING: "System"
[root@localhost ~]# snmpget -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15.1.1
SNMPv2-SMI::enterprises.xxxxx.15.1.1 = INTEGER: 0
[root@localhost ~]# snmpget -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15.1.2
SNMPv2-SMI::enterprises.xxxxx.15.1.2 = INTEGER: 1
[root@localhost ~]#
Here is the debugging output:
14:53:11:984 , SnmpExtensionQueryEx
14:53:11:984 , nRequestType=SNMP_EXTENSION_GET
14:53:11:984 , GetRequest: OID=1.3.6.1.4.1.xxxxx (7)
14:53:11:984 , GetRequest: value=snmptools by erwan.l@free.fr asn_type=4
14:53:11:984 , GetRequest: OK
14:53:14:937 , SnmpExtensionQueryEx
14:53:14:937 , nRequestType=SNMP_EXTENSION_GET
14:53:14:937 , GetRequest: OID=1.3.6.1.4.1.xxxxx.15 (8)
14:53:14:937 , GetRequest: value=customWindows asn_type=4
14:53:14:937 , GetRequest: OK
14:53:20:328 , SnmpExtensionQueryEx
14:53:20:328 , nRequestType=SNMP_EXTENSION_GET
14:53:20:328 , GetRequest: OID=1.3.6.1.4.1.xxxxx.15.1 (9)
14:53:20:328 , GetRequest: value=System asn_type=4
14:53:20:328 , GetRequest: OK
14:53:23:250 , SnmpExtensionQueryEx
14:53:23:250 , nRequestType=SNMP_EXTENSION_GET
14:53:23:250 , GetRequest: OID=1.3.6.1.4.1.xxxxx.15.1.1 (10)
14:53:23:250 , GetPerf: path=System\File Read Operations/sec
14:53:23:250 , GetPerf: pdh_counter_path=\System\File Read Operations/sec
14:53:24:265 , GetPerf: vartype=Integer
14:53:24:265 , GetRequest: value=0 asn_type=2
14:53:24:265 , GetRequest: OK
14:53:24:265 , SnmpExtensionQueryEx
14:53:24:265 , nRequestType=SNMP_EXTENSION_GET
14:53:24:265 , GetRequest: OID=1.3.6.1.4.1.xxxxx.15.1.1 (10)
14:53:24:265 , GetPerf: path=System\File Read Operations/sec
14:53:24:265 , GetPerf: pdh_counter_path=\System\File Read Operations/sec
14:53:25:265 , GetPerf: vartype=Integer
14:53:25:265 , GetRequest: value=0 asn_type=2
14:53:25:265 , GetRequest: OK
14:53:25:937 , SnmpExtensionQueryEx
14:53:25:937 , nRequestType=SNMP_EXTENSION_GET
14:53:25:937 , GetRequest: OID=1.3.6.1.4.1.xxxxx.15.1.2 (10)
14:53:25:937 , GetPerf: path=System\File Write Operations/sec
14:53:25:937 , GetPerf: pdh_counter_path=\System\File Write Operations/sec
14:53:26:937 , GetPerf: vartype=Integer
14:53:26:937 , GetRequest: value=1 asn_type=2
14:53:26:937 , GetRequest: OK
14:53:26:937 , SnmpExtensionQueryEx
14:53:26:937 , nRequestType=SNMP_EXTENSION_GET
14:53:26:937 , GetRequest: OID=1.3.6.1.4.1.xxxxx.15.1.2 (10)
14:53:26:937 , GetPerf: path=System\File Write Operations/sec
14:53:26:937 , GetPerf: pdh_counter_path=\System\File Write Operations/sec
14:53:27:937 , GetPerf: vartype=Integer
14:53:27:937 , GetRequest: value=0 asn_type=2
14:53:27:937 , GetRequest: OK
So far so good!
Now, let's try to do an snmpwalk starting at either the root OID or any of the deeper branch:
[root@localhost ~]# snmpwalk -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx
End of MIB
SNMPv2-SMI::enterprises.xxxxx = STRING: "snmptools by erwan.l@free.fr"
[root@localhost ~]# snmpwalk -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15
End of MIB
SNMPv2-SMI::enterprises.xxxxx.15 = STRING: "customWindows"
[root@localhost ~]# snmpwalk -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15.1
End of MIB
SNMPv2-SMI::enterprises.xxxxx.15.1 = STRING: "System"
[root@localhost ~]# snmpwalk -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15.1.1
End of MIB
SNMPv2-SMI::enterprises.xxxxx.15.1.1 = INTEGER: 0
[root@localhost ~]#
In all cases, it does not go very far. Here is the debugging output:
14:58:17:015 , SnmpExtensionQueryEx
14:58:17:015 , nRequestType=SNMP_EXTENSION_GET_NEXT
14:58:17:015 , GetNextRequest:1.3.6.1.4.1.xxxxx(7)
14:58:17:015 , comparemem=false
14:58:17:046 , SnmpExtensionQueryEx
14:58:17:046 , nRequestType=SNMP_EXTENSION_GET
14:58:17:046 , GetRequest: OID=1.3.6.1.4.1.xxxxx (7)
14:58:17:046 , GetRequest: value=snmptools by erwan.l@free.fr asn_type=4
14:58:17:046 , GetRequest: OK
14:58:20:171 , SnmpExtensionQueryEx
14:58:20:171 , nRequestType=SNMP_EXTENSION_GET_NEXT
14:58:20:171 , GetNextRequest:1.3.6.1.4.1.xxxxx.15(8)
14:58:20:171 , comparemem=false
14:58:20:218 , SnmpExtensionQueryEx
14:58:20:218 , nRequestType=SNMP_EXTENSION_GET
14:58:20:218 , GetRequest: OID=1.3.6.1.4.1.xxxxx.15 (8)
14:58:20:218 , GetRequest: value=customWindows asn_type=4
14:58:20:218 , GetRequest: OK
14:58:36:500 , SnmpExtensionQueryEx
14:58:36:500 , nRequestType=SNMP_EXTENSION_GET_NEXT
14:58:36:500 , GetNextRequest:1.3.6.1.4.1.xxxxx.15.1(9)
14:58:36:500 , comparemem=false
14:58:36:609 , SnmpExtensionQueryEx
14:58:36:609 , nRequestType=SNMP_EXTENSION_GET
14:58:36:609 , GetRequest: OID=1.3.6.1.4.1.xxxxx.15.1 (9)
14:58:36:609 , GetRequest: value=System asn_type=4
14:58:36:609 , GetRequest: OK
14:58:38:781 , SnmpExtensionQueryEx
14:58:38:781 , nRequestType=SNMP_EXTENSION_GET_NEXT
14:58:38:781 , GetNextRequest:1.3.6.1.4.1.xxxxx.15.1.1(10)
14:58:38:781 , comparemem=false
14:58:38:984 , SnmpExtensionQueryEx
14:58:38:984 , nRequestType=SNMP_EXTENSION_GET
14:58:38:984 , GetRequest: OID=1.3.6.1.4.1.xxxxx.15.1.1 (10)
14:58:38:984 , GetPerf: path=System\File Read Operations/sec
14:58:39:000 , GetPerf: pdh_counter_path=\System\File Read Operations/sec
14:58:40:000 , GetPerf: vartype=Integer
14:58:40:000 , GetRequest: value=0 asn_type=2
14:58:40:000 , GetRequest: OK
14:58:40:000 , SnmpExtensionQueryEx
14:58:40:000 , nRequestType=SNMP_EXTENSION_GET
14:58:40:000 , GetRequest: OID=1.3.6.1.4.1.xxxxx.15.1.1 (10)
14:58:40:000 , GetPerf: path=System\File Read Operations/sec
14:58:40:000 , GetPerf: pdh_counter_path=\System\File Read Operations/sec
14:58:41:000 , GetPerf: vartype=Integer
14:58:41:000 , GetRequest: value=0 asn_type=2
14:58:41:000 , GetRequest: OK
I would have expected to get all my OIDs when starting at the top OID or at least from the top of one branch...
Just for completeness, here is an attempt at doing the getnext queries manually:
[root@localhost ~]# snmpgetnext -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-SMI::enterprises.xxxxx
[root@localhost ~]# snmpgetnext -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-SMI::enterprises.xxxxx.15
[root@localhost ~]# snmpgetnext -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15.1
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-SMI::enterprises.xxxxx.15.1
[root@localhost ~]# snmpgetnext -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15.1.1
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-SMI::enterprises.xxxxx.15.1.1
[root@localhost ~]# snmpgetnext -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15.1.2
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-SMI::enterprises.xxxxx.15.1.2
[root@localhost ~]#
Here is the debugging output:
15:01:42:265 , SnmpExtensionQueryEx
15:01:42:265 , nRequestType=SNMP_EXTENSION_GET_NEXT
15:01:42:265 , GetNextRequest:1.3.6.1.4.1.xxxxx(7)
15:01:42:265 , comparemem=false
15:01:45:296 , SnmpExtensionQueryEx
15:01:45:296 , nRequestType=SNMP_EXTENSION_GET_NEXT
15:01:45:296 , GetNextRequest:1.3.6.1.4.1.xxxxx.15(8)
15:01:45:296 , comparemem=false
15:01:46:937 , SnmpExtensionQueryEx
15:01:46:937 , nRequestType=SNMP_EXTENSION_GET_NEXT
15:01:46:937 , GetNextRequest:1.3.6.1.4.1.xxxxx.15.1(9)
15:01:46:937 , comparemem=false
15:01:49:000 , SnmpExtensionQueryEx
15:01:49:000 , nRequestType=SNMP_EXTENSION_GET_NEXT
15:01:49:000 , GetNextRequest:1.3.6.1.4.1.xxxxx.15.1.1(10)
15:01:49:000 , comparemem=false
15:01:56:984 , SnmpExtensionQueryEx
15:01:56:984 , nRequestType=SNMP_EXTENSION_GET_NEXT
15:01:56:984 , GetNextRequest:1.3.6.1.4.1.xxxxx.15.1.2(10)
15:01:56:984 , comparemem=false
This is running on Windows 2003 Standard Edition, Service Pack 2 (English), btw.
Is there anything different I need to do in my counters.ini file?
Please advise?
Thanks again!
Antoine
Thanks for the new version once again.
Now, the counters with the / in the name are working correctly. As instructed (by PM), I have removed my flag=norefresh from all the counters which give a per-second reading (all counters ending with "/sec").
The snmp gets are working correctly now, thanks! However, snmpwalk is not working.
If I try to do an snmpgetnext on the root OID or any other OID where I know there is a next element, I receive a "noSuchName" error (using snmpgetnext from net-snmp under Linux).
Could it be related to the new "OID" key in the registry? (I don't know how you decide on the chain of OIDs for the getnext requests). I noticed in the example counters file that there were no blank lines between these items and have removed the blank lines in my own, with no change.
Here is the simplified counters.ini file used for this test (with my PEN obfuscated):
[1.3.6.1.4.1.xxxxx.15]
type=string
counter=customWindows
[1.3.6.1.4.1.xxxxx.15.1]
type=string
counter=System
[1.3.6.1.4.1.xxxxx.15.1.1]
counter=System\File Read Operations/sec
[1.3.6.1.4.1.xxxxx.15.1.2]
counter=System\File Write Operations/sec
Here are the commands (net-snmp under Linux) that work fine, just for completeness (with IP address and PEN obfuscated):
[root@localhost ~]# snmpget -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx
SNMPv2-SMI::enterprises.xxxxx = STRING: "snmptools by erwan.l@free.fr"
[root@localhost ~]# snmpget -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15
SNMPv2-SMI::enterprises.xxxxx.15 = STRING: "customWindows"
[root@localhost ~]# snmpget -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15.1
SNMPv2-SMI::enterprises.xxxxx.15.1 = STRING: "System"
[root@localhost ~]# snmpget -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15.1.1
SNMPv2-SMI::enterprises.xxxxx.15.1.1 = INTEGER: 0
[root@localhost ~]# snmpget -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15.1.2
SNMPv2-SMI::enterprises.xxxxx.15.1.2 = INTEGER: 1
[root@localhost ~]#
Here is the debugging output:
14:53:11:984 , SnmpExtensionQueryEx
14:53:11:984 , nRequestType=SNMP_EXTENSION_GET
14:53:11:984 , GetRequest: OID=1.3.6.1.4.1.xxxxx (7)
14:53:11:984 , GetRequest: value=snmptools by erwan.l@free.fr asn_type=4
14:53:11:984 , GetRequest: OK
14:53:14:937 , SnmpExtensionQueryEx
14:53:14:937 , nRequestType=SNMP_EXTENSION_GET
14:53:14:937 , GetRequest: OID=1.3.6.1.4.1.xxxxx.15 (8)
14:53:14:937 , GetRequest: value=customWindows asn_type=4
14:53:14:937 , GetRequest: OK
14:53:20:328 , SnmpExtensionQueryEx
14:53:20:328 , nRequestType=SNMP_EXTENSION_GET
14:53:20:328 , GetRequest: OID=1.3.6.1.4.1.xxxxx.15.1 (9)
14:53:20:328 , GetRequest: value=System asn_type=4
14:53:20:328 , GetRequest: OK
14:53:23:250 , SnmpExtensionQueryEx
14:53:23:250 , nRequestType=SNMP_EXTENSION_GET
14:53:23:250 , GetRequest: OID=1.3.6.1.4.1.xxxxx.15.1.1 (10)
14:53:23:250 , GetPerf: path=System\File Read Operations/sec
14:53:23:250 , GetPerf: pdh_counter_path=\System\File Read Operations/sec
14:53:24:265 , GetPerf: vartype=Integer
14:53:24:265 , GetRequest: value=0 asn_type=2
14:53:24:265 , GetRequest: OK
14:53:24:265 , SnmpExtensionQueryEx
14:53:24:265 , nRequestType=SNMP_EXTENSION_GET
14:53:24:265 , GetRequest: OID=1.3.6.1.4.1.xxxxx.15.1.1 (10)
14:53:24:265 , GetPerf: path=System\File Read Operations/sec
14:53:24:265 , GetPerf: pdh_counter_path=\System\File Read Operations/sec
14:53:25:265 , GetPerf: vartype=Integer
14:53:25:265 , GetRequest: value=0 asn_type=2
14:53:25:265 , GetRequest: OK
14:53:25:937 , SnmpExtensionQueryEx
14:53:25:937 , nRequestType=SNMP_EXTENSION_GET
14:53:25:937 , GetRequest: OID=1.3.6.1.4.1.xxxxx.15.1.2 (10)
14:53:25:937 , GetPerf: path=System\File Write Operations/sec
14:53:25:937 , GetPerf: pdh_counter_path=\System\File Write Operations/sec
14:53:26:937 , GetPerf: vartype=Integer
14:53:26:937 , GetRequest: value=1 asn_type=2
14:53:26:937 , GetRequest: OK
14:53:26:937 , SnmpExtensionQueryEx
14:53:26:937 , nRequestType=SNMP_EXTENSION_GET
14:53:26:937 , GetRequest: OID=1.3.6.1.4.1.xxxxx.15.1.2 (10)
14:53:26:937 , GetPerf: path=System\File Write Operations/sec
14:53:26:937 , GetPerf: pdh_counter_path=\System\File Write Operations/sec
14:53:27:937 , GetPerf: vartype=Integer
14:53:27:937 , GetRequest: value=0 asn_type=2
14:53:27:937 , GetRequest: OK
So far so good!
Now, let's try to do an snmpwalk starting at either the root OID or any of the deeper branch:
[root@localhost ~]# snmpwalk -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx
End of MIB
SNMPv2-SMI::enterprises.xxxxx = STRING: "snmptools by erwan.l@free.fr"
[root@localhost ~]# snmpwalk -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15
End of MIB
SNMPv2-SMI::enterprises.xxxxx.15 = STRING: "customWindows"
[root@localhost ~]# snmpwalk -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15.1
End of MIB
SNMPv2-SMI::enterprises.xxxxx.15.1 = STRING: "System"
[root@localhost ~]# snmpwalk -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15.1.1
End of MIB
SNMPv2-SMI::enterprises.xxxxx.15.1.1 = INTEGER: 0
[root@localhost ~]#
In all cases, it does not go very far. Here is the debugging output:
14:58:17:015 , SnmpExtensionQueryEx
14:58:17:015 , nRequestType=SNMP_EXTENSION_GET_NEXT
14:58:17:015 , GetNextRequest:1.3.6.1.4.1.xxxxx(7)
14:58:17:015 , comparemem=false
14:58:17:046 , SnmpExtensionQueryEx
14:58:17:046 , nRequestType=SNMP_EXTENSION_GET
14:58:17:046 , GetRequest: OID=1.3.6.1.4.1.xxxxx (7)
14:58:17:046 , GetRequest: value=snmptools by erwan.l@free.fr asn_type=4
14:58:17:046 , GetRequest: OK
14:58:20:171 , SnmpExtensionQueryEx
14:58:20:171 , nRequestType=SNMP_EXTENSION_GET_NEXT
14:58:20:171 , GetNextRequest:1.3.6.1.4.1.xxxxx.15(8)
14:58:20:171 , comparemem=false
14:58:20:218 , SnmpExtensionQueryEx
14:58:20:218 , nRequestType=SNMP_EXTENSION_GET
14:58:20:218 , GetRequest: OID=1.3.6.1.4.1.xxxxx.15 (8)
14:58:20:218 , GetRequest: value=customWindows asn_type=4
14:58:20:218 , GetRequest: OK
14:58:36:500 , SnmpExtensionQueryEx
14:58:36:500 , nRequestType=SNMP_EXTENSION_GET_NEXT
14:58:36:500 , GetNextRequest:1.3.6.1.4.1.xxxxx.15.1(9)
14:58:36:500 , comparemem=false
14:58:36:609 , SnmpExtensionQueryEx
14:58:36:609 , nRequestType=SNMP_EXTENSION_GET
14:58:36:609 , GetRequest: OID=1.3.6.1.4.1.xxxxx.15.1 (9)
14:58:36:609 , GetRequest: value=System asn_type=4
14:58:36:609 , GetRequest: OK
14:58:38:781 , SnmpExtensionQueryEx
14:58:38:781 , nRequestType=SNMP_EXTENSION_GET_NEXT
14:58:38:781 , GetNextRequest:1.3.6.1.4.1.xxxxx.15.1.1(10)
14:58:38:781 , comparemem=false
14:58:38:984 , SnmpExtensionQueryEx
14:58:38:984 , nRequestType=SNMP_EXTENSION_GET
14:58:38:984 , GetRequest: OID=1.3.6.1.4.1.xxxxx.15.1.1 (10)
14:58:38:984 , GetPerf: path=System\File Read Operations/sec
14:58:39:000 , GetPerf: pdh_counter_path=\System\File Read Operations/sec
14:58:40:000 , GetPerf: vartype=Integer
14:58:40:000 , GetRequest: value=0 asn_type=2
14:58:40:000 , GetRequest: OK
14:58:40:000 , SnmpExtensionQueryEx
14:58:40:000 , nRequestType=SNMP_EXTENSION_GET
14:58:40:000 , GetRequest: OID=1.3.6.1.4.1.xxxxx.15.1.1 (10)
14:58:40:000 , GetPerf: path=System\File Read Operations/sec
14:58:40:000 , GetPerf: pdh_counter_path=\System\File Read Operations/sec
14:58:41:000 , GetPerf: vartype=Integer
14:58:41:000 , GetRequest: value=0 asn_type=2
14:58:41:000 , GetRequest: OK
I would have expected to get all my OIDs when starting at the top OID or at least from the top of one branch...
Just for completeness, here is an attempt at doing the getnext queries manually:
[root@localhost ~]# snmpgetnext -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-SMI::enterprises.xxxxx
[root@localhost ~]# snmpgetnext -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-SMI::enterprises.xxxxx.15
[root@localhost ~]# snmpgetnext -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15.1
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-SMI::enterprises.xxxxx.15.1
[root@localhost ~]# snmpgetnext -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15.1.1
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-SMI::enterprises.xxxxx.15.1.1
[root@localhost ~]# snmpgetnext -v 2c -c public x.x.x.x .1.3.6.1.4.1.xxxxx.15.1.2
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-SMI::enterprises.xxxxx.15.1.2
[root@localhost ~]#
Here is the debugging output:
15:01:42:265 , SnmpExtensionQueryEx
15:01:42:265 , nRequestType=SNMP_EXTENSION_GET_NEXT
15:01:42:265 , GetNextRequest:1.3.6.1.4.1.xxxxx(7)
15:01:42:265 , comparemem=false
15:01:45:296 , SnmpExtensionQueryEx
15:01:45:296 , nRequestType=SNMP_EXTENSION_GET_NEXT
15:01:45:296 , GetNextRequest:1.3.6.1.4.1.xxxxx.15(8)
15:01:45:296 , comparemem=false
15:01:46:937 , SnmpExtensionQueryEx
15:01:46:937 , nRequestType=SNMP_EXTENSION_GET_NEXT
15:01:46:937 , GetNextRequest:1.3.6.1.4.1.xxxxx.15.1(9)
15:01:46:937 , comparemem=false
15:01:49:000 , SnmpExtensionQueryEx
15:01:49:000 , nRequestType=SNMP_EXTENSION_GET_NEXT
15:01:49:000 , GetNextRequest:1.3.6.1.4.1.xxxxx.15.1.1(10)
15:01:49:000 , comparemem=false
15:01:56:984 , SnmpExtensionQueryEx
15:01:56:984 , nRequestType=SNMP_EXTENSION_GET_NEXT
15:01:56:984 , GetNextRequest:1.3.6.1.4.1.xxxxx.15.1.2(10)
15:01:56:984 , comparemem=false
This is running on Windows 2003 Standard Edition, Service Pack 2 (English), btw.
Is there anything different I need to do in my counters.ini file?
Please advise?
Thanks again!
Antoine
Nothing is as simple as it seems at first
Or as hopeless as it seems in the middle
Or as finished as it seems in the end.
Or as hopeless as it seems in the middle
Or as finished as it seems in the end.
Version 2.0.0.12 now handles "\" characters.
This version also fixes the snmpgetnext bug when using custom oid as mentionned by flukester.
20:53:19:968 , SnmpExtensionQueryEx
20:53:19:968 , nRequestType=SNMP_EXTENSION_GET
20:53:19:968 , GetRequest: OID=1.3.6.1.4.1.15.6 (8)
20:53:19:968 , GetPerf: path=nwlink ipx\datagrams/sec\\device\nwlnkipx
20:53:19:968 , GetPerf: pdh_counter_path=\NWLink IPX(\device\nwlnkipx)\Datagrammes/s
20:53:20:968 , GetPerf: vartype=Integer
20:53:20:968 , GetRequest: value=0 asn_type=2
20:53:20:968 , GetRequest: OK
Thanks for the debugging !
/Erwan
This version also fixes the snmpgetnext bug when using custom oid as mentionned by flukester.
20:53:19:968 , SnmpExtensionQueryEx
20:53:19:968 , nRequestType=SNMP_EXTENSION_GET
20:53:19:968 , GetRequest: OID=1.3.6.1.4.1.15.6 (8)
20:53:19:968 , GetPerf: path=nwlink ipx\datagrams/sec\\device\nwlnkipx
20:53:19:968 , GetPerf: pdh_counter_path=\NWLink IPX(\device\nwlnkipx)\Datagrammes/s
20:53:20:968 , GetPerf: vartype=Integer
20:53:20:968 , GetRequest: value=0 asn_type=2
20:53:20:968 , GetRequest: OK
Thanks for the debugging !
/Erwan
Indeed, I just tried the new version and snmpwalk is now working with the test ini file I posted earlier!erwan.l wrote:Version 2.0.0.12 now handles "" characters.
This version also fixes the snmpgetnext bug when using custom oid as mentionned by flukester.
20:53:19:968 , SnmpExtensionQueryEx
20:53:19:968 , nRequestType=SNMP_EXTENSION_GET
20:53:19:968 , GetRequest: OID=1.3.6.1.4.1.15.6 (8)
20:53:19:968 , GetPerf: path=nwlink ipx\datagrams/sec\\device\nwlnkipx
20:53:19:968 , GetPerf: pdh_counter_path=\NWLink IPX(\device\nwlnkipx)\Datagrammes/s
20:53:20:968 , GetPerf: vartype=Integer
20:53:20:968 , GetRequest: value=0 asn_type=2
20:53:20:968 , GetRequest: OK
Thanks for the debugging !
/Erwan
(2 minutes later)
Yes, it works with my bigger file as well! (about 40 or 50 counters so far..)
Thank you very much for this subagent!
Antoine
Nothing is as simple as it seems at first
Or as hopeless as it seems in the middle
Or as finished as it seems in the end.
Or as hopeless as it seems in the middle
Or as finished as it seems in the end.
Hello Erwan!
Yes, it's me again!
I'm having some small issues with the sub-agent.. I hope you can still help :)
First, I'm building SNMP tables and it looks like some of my OIDs are being rejected by your code because they are too long (number of elements, not string length).
Funny thing is, a GETNEXT operation works but not a regular GET.
Here is what I get in the debug log:
15:06:30:234 , DLL_PROCESS_DETACH
15:06:30:234 , clean
15:08:06:203 , counters=c:\counters.ini
15:08:06:203 , Traps=
15:08:06:203 , SnmpExtensionInit
15:08:06:203 , start
15:08:06:203 , Platform : win32
15:08:06:203 , OSVersion: osWin2k3
15:08:06:203 , LOCALE_SDECIMAL: .
15:08:06:203 , OID: 1.3.6.1.4.1.xxxxx
15:10:33:562 , SnmpExtensionQueryEx
15:10:33:562 , nRequestType=SNMP_EXTENSION_GET
15:10:33:562 , GetRequest: OID=1.3.6.1.4.1.xxxxx.16.6.2.1.4.20 (13)
15:10:33:562 , (len<7) or (len>11)
15:11:01:437 , SnmpExtensionQueryEx
15:11:01:437 , nRequestType=SNMP_EXTENSION_GET_NEXT
15:11:01:437 , GetNextRequest:1.3.6.1.4.1.xxxxx.16.6.2.1.4.20(13)
15:11:01:453 , GetPerf: path=HP EVA Virtual Disk\Read Hit Latency (us)\6005-08B4-0009-0928-0000-D000-00D7-0000_5000-1FE1-500C-D550:U091 (5000-1FE1-500C-D550)
15:11:01:453 , GetPerf: pdh_counter_path=\HP EVA Virtual Disk(6005-08B4-0009-0928-0000-D000-00D7-0000_5000-1FE1-500C-D550:U091 (5000-1FE1-500C-D550))\Read Hit Latency (us)
15:11:02:515 , PdhGetCounterInfo: ret=800007D2
15:11:02:515 , GetPerf: vartype=Double
15:11:02:515 , value=0 length=1
15:11:02:515 , Next OID: 1.3.6.1.4.1.xxxxx.16.6.2.1.4.21 idlength=13
15:11:02:515 , GetNextRequest OK
Blank lines added by myself. I left the DLL initialization in, then we have a failed GET and then a working GETNEXT.
Could you please increase the maximum length you allow? I'm not sure if any RFC specifies a maximum number but 11 is quite low. Is this a static limit you've put in the code? Could you please increase it to a larger value?
I also have another, bigger issue. I think I'll have to send you more details privately. I now have a rather large counters.ini file (2175 lines, about 76kbytes, 576 counters) and everything works fine (the getnext at least) until I reach a certain object.
Here are the log entries. I've done a few getnext starting a few objects earlier. It's a bit hard to read because the Instance names are long UIDs...
15:17:09:531 , SnmpExtensionQueryEx
15:17:09:531 , nRequestType=SNMP_EXTENSION_GET_NEXT
15:17:09:531 , GetNextRequest:1.3.6.1.4.1.xxxxx.16.6.2.1.4.29(13)
15:17:09:531 , GetPerf: path=HP EVA Virtual Disk\Read Hit Latency (us)\6005-08B4-0009-0928-0000-D000-0117-0000_5000-1FE1-500C-D550:U091 (5000-1FE1-500C-D550)
15:17:09:531 , GetPerf: pdh_counter_path=\HP EVA Virtual Disk(6005-08B4-0009-0928-0000-D000-0117-0000_5000-1FE1-500C-D550:U091 (5000-1FE1-500C-D550))\Read Hit Latency (us)
15:17:09:562 , PdhGetCounterInfo: ret=800007D2
15:17:09:562 , GetPerf: vartype=Double
15:17:09:562 , value=54 length=2
15:17:09:562 , Next OID: 1.3.6.1.4.1.xxxxx.16.6.2.1.4.30 idlength=13
15:17:09:562 , GetNextRequest OK
15:17:13:031 , SnmpExtensionQueryEx
15:17:13:031 , nRequestType=SNMP_EXTENSION_GET_NEXT
15:17:13:031 , GetNextRequest:1.3.6.1.4.1.xxxxx.16.6.2.1.4.30(13)
15:17:13:031 , GetPerf: path=HP EVA Virtual Disk\Read Hit Latency (us)\6005-08B4-0009-0928-0000-D000-011D-0000_5000-1FE1-500C-D550:U091 (5000-1FE1-500C-D550)
15:17:13:031 , GetPerf: pdh_counter_path=\HP EVA Virtual Disk(6005-08B4-0009-0928-0000-D000-011D-0000_5000-1FE1-500C-D550:U091 (5000-1FE1-500C-D550))\Read Hit Latency (us)
15:17:13:062 , PdhGetCounterInfo: ret=800007D2
15:17:13:062 , GetPerf: vartype=Double
15:17:13:062 , value=0 length=1
15:17:13:062 , Next OID: 1.3.6.1.4.1.xxxxx.16.6.2.1.4.31 idlength=13
15:17:13:062 , GetNextRequest OK
15:17:15:640 , SnmpExtensionQueryEx
15:17:15:640 , nRequestType=SNMP_EXTENSION_GET_NEXT
15:17:15:640 , GetNextRequest:1.3.6.1.4.1.xxxxx.16.6.2.1.4.31(13)
15:17:15:656 , value= length=0
15:17:15:656 , length(str_result)=0
15:17:16:875 , SnmpExtensionQueryEx
15:17:16:875 , nRequestType=SNMP_EXTENSION_GET_NEXT
15:17:16:875 , GetNextRequest:1.3.6.1.4.1.xxxxx.16.6.2.1.4.32(13)
Here is what I get at the shell from snmpgetnext (using net-snmp 5.1.12 under RedHat 4):
[root@localhost ~]# snmpgetnext -v 2c -c public -r 3 -t 10 x.x.x.x .1.3.6.1.4.1.xxxxx.16.6.2.1.4.31
Error in packet.
Reason: (genError) A general failure occured
Failed object: SNMPv2-SMI::enterprises.xxxxx.16.6.2.1.4.31
[root@localhost ~]# snmpgetnext -v 2c -c public -r 3 -t 10 x.x.x.x .1.3.6.1.4.1.xxxxx.16.6.2.1.4.32
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-SMI::enterprises.xxxxx.16.6.2.1.4.32
[root@localhost ~]#
It looks like the code never prints the GetPerf path and pdh_counter_path so I guess it never makes it to fetch the actual counter...
I can't post my full counters.ini here but if you need to, I can send you a private copy. Also, I'm afraid those are performance counters that you won't have on your test system(s).
I can run perf32 for this xxxxx.16.6.2.1.4.31 counter and I don't get any error. The returned value is 0, but it's not the only counter that gives me a 0 value.. (the system is not very busy at the moment).
Please let me know (by PM?) what information you would require to help diagnose this.. If you want me to run another version of the DLL with more debugging I will be glad to do that...
Thanks!
Antoine
Yes, it's me again!
I'm having some small issues with the sub-agent.. I hope you can still help :)
First, I'm building SNMP tables and it looks like some of my OIDs are being rejected by your code because they are too long (number of elements, not string length).
Funny thing is, a GETNEXT operation works but not a regular GET.
Here is what I get in the debug log:
15:06:30:234 , DLL_PROCESS_DETACH
15:06:30:234 , clean
15:08:06:203 , counters=c:\counters.ini
15:08:06:203 , Traps=
15:08:06:203 , SnmpExtensionInit
15:08:06:203 , start
15:08:06:203 , Platform : win32
15:08:06:203 , OSVersion: osWin2k3
15:08:06:203 , LOCALE_SDECIMAL: .
15:08:06:203 , OID: 1.3.6.1.4.1.xxxxx
15:10:33:562 , SnmpExtensionQueryEx
15:10:33:562 , nRequestType=SNMP_EXTENSION_GET
15:10:33:562 , GetRequest: OID=1.3.6.1.4.1.xxxxx.16.6.2.1.4.20 (13)
15:10:33:562 , (len<7) or (len>11)
15:11:01:437 , SnmpExtensionQueryEx
15:11:01:437 , nRequestType=SNMP_EXTENSION_GET_NEXT
15:11:01:437 , GetNextRequest:1.3.6.1.4.1.xxxxx.16.6.2.1.4.20(13)
15:11:01:453 , GetPerf: path=HP EVA Virtual Disk\Read Hit Latency (us)\6005-08B4-0009-0928-0000-D000-00D7-0000_5000-1FE1-500C-D550:U091 (5000-1FE1-500C-D550)
15:11:01:453 , GetPerf: pdh_counter_path=\HP EVA Virtual Disk(6005-08B4-0009-0928-0000-D000-00D7-0000_5000-1FE1-500C-D550:U091 (5000-1FE1-500C-D550))\Read Hit Latency (us)
15:11:02:515 , PdhGetCounterInfo: ret=800007D2
15:11:02:515 , GetPerf: vartype=Double
15:11:02:515 , value=0 length=1
15:11:02:515 , Next OID: 1.3.6.1.4.1.xxxxx.16.6.2.1.4.21 idlength=13
15:11:02:515 , GetNextRequest OK
Blank lines added by myself. I left the DLL initialization in, then we have a failed GET and then a working GETNEXT.
Could you please increase the maximum length you allow? I'm not sure if any RFC specifies a maximum number but 11 is quite low. Is this a static limit you've put in the code? Could you please increase it to a larger value?
I also have another, bigger issue. I think I'll have to send you more details privately. I now have a rather large counters.ini file (2175 lines, about 76kbytes, 576 counters) and everything works fine (the getnext at least) until I reach a certain object.
Here are the log entries. I've done a few getnext starting a few objects earlier. It's a bit hard to read because the Instance names are long UIDs...
15:17:09:531 , SnmpExtensionQueryEx
15:17:09:531 , nRequestType=SNMP_EXTENSION_GET_NEXT
15:17:09:531 , GetNextRequest:1.3.6.1.4.1.xxxxx.16.6.2.1.4.29(13)
15:17:09:531 , GetPerf: path=HP EVA Virtual Disk\Read Hit Latency (us)\6005-08B4-0009-0928-0000-D000-0117-0000_5000-1FE1-500C-D550:U091 (5000-1FE1-500C-D550)
15:17:09:531 , GetPerf: pdh_counter_path=\HP EVA Virtual Disk(6005-08B4-0009-0928-0000-D000-0117-0000_5000-1FE1-500C-D550:U091 (5000-1FE1-500C-D550))\Read Hit Latency (us)
15:17:09:562 , PdhGetCounterInfo: ret=800007D2
15:17:09:562 , GetPerf: vartype=Double
15:17:09:562 , value=54 length=2
15:17:09:562 , Next OID: 1.3.6.1.4.1.xxxxx.16.6.2.1.4.30 idlength=13
15:17:09:562 , GetNextRequest OK
15:17:13:031 , SnmpExtensionQueryEx
15:17:13:031 , nRequestType=SNMP_EXTENSION_GET_NEXT
15:17:13:031 , GetNextRequest:1.3.6.1.4.1.xxxxx.16.6.2.1.4.30(13)
15:17:13:031 , GetPerf: path=HP EVA Virtual Disk\Read Hit Latency (us)\6005-08B4-0009-0928-0000-D000-011D-0000_5000-1FE1-500C-D550:U091 (5000-1FE1-500C-D550)
15:17:13:031 , GetPerf: pdh_counter_path=\HP EVA Virtual Disk(6005-08B4-0009-0928-0000-D000-011D-0000_5000-1FE1-500C-D550:U091 (5000-1FE1-500C-D550))\Read Hit Latency (us)
15:17:13:062 , PdhGetCounterInfo: ret=800007D2
15:17:13:062 , GetPerf: vartype=Double
15:17:13:062 , value=0 length=1
15:17:13:062 , Next OID: 1.3.6.1.4.1.xxxxx.16.6.2.1.4.31 idlength=13
15:17:13:062 , GetNextRequest OK
15:17:15:640 , SnmpExtensionQueryEx
15:17:15:640 , nRequestType=SNMP_EXTENSION_GET_NEXT
15:17:15:640 , GetNextRequest:1.3.6.1.4.1.xxxxx.16.6.2.1.4.31(13)
15:17:15:656 , value= length=0
15:17:15:656 , length(str_result)=0
15:17:16:875 , SnmpExtensionQueryEx
15:17:16:875 , nRequestType=SNMP_EXTENSION_GET_NEXT
15:17:16:875 , GetNextRequest:1.3.6.1.4.1.xxxxx.16.6.2.1.4.32(13)
Here is what I get at the shell from snmpgetnext (using net-snmp 5.1.12 under RedHat 4):
[root@localhost ~]# snmpgetnext -v 2c -c public -r 3 -t 10 x.x.x.x .1.3.6.1.4.1.xxxxx.16.6.2.1.4.31
Error in packet.
Reason: (genError) A general failure occured
Failed object: SNMPv2-SMI::enterprises.xxxxx.16.6.2.1.4.31
[root@localhost ~]# snmpgetnext -v 2c -c public -r 3 -t 10 x.x.x.x .1.3.6.1.4.1.xxxxx.16.6.2.1.4.32
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-SMI::enterprises.xxxxx.16.6.2.1.4.32
[root@localhost ~]#
It looks like the code never prints the GetPerf path and pdh_counter_path so I guess it never makes it to fetch the actual counter...
I can't post my full counters.ini here but if you need to, I can send you a private copy. Also, I'm afraid those are performance counters that you won't have on your test system(s).
I can run perf32 for this xxxxx.16.6.2.1.4.31 counter and I don't get any error. The returned value is 0, but it's not the only counter that gives me a 0 value.. (the system is not very busy at the moment).
Please let me know (by PM?) what information you would require to help diagnose this.. If you want me to run another version of the DLL with more debugging I will be glad to do that...
Thanks!
Antoine
Nothing is as simple as it seems at first
Or as hopeless as it seems in the middle
Or as finished as it seems in the end.
Or as hopeless as it seems in the middle
Or as finished as it seems in the end.
Hi flukester,
The 11 bytes max issue should be resolved.
Re download and it should be fine.
About second issue :
"800007D2" error means "There is more data to return than would fit in the supplied buffer. Allocate a larger buffer and call the function again."
Gave me a good hint where to look : there was a memory allocation bug fixed now in 2.0.0.13.
3 minor versions in a week : nice
Regards,
Erwan
The 11 bytes max issue should be resolved.
Re download and it should be fine.
About second issue :
"800007D2" error means "There is more data to return than would fit in the supplied buffer. Allocate a larger buffer and call the function again."
Gave me a good hint where to look : there was a memory allocation bug fixed now in 2.0.0.13.
3 minor versions in a week : nice
Regards,
Erwan
Hello! Thanks for the amazingly quick response!erwan.l wrote:Hi flukester,
The 11 bytes max issue should be resolved.
Re download and it should be fine.
About second issue :
"800007D2" error means "There is more data to return than would fit in the supplied buffer. Allocate a larger buffer and call the function again."
Gave me a good hint where to look : there was a memory allocation bug fixed now in 2.0.0.13.
3 minor versions in a week : nice :)
Regards,
Erwan
The new version works for a GET on my long OIDs. Thanks!
For the other problem, it's really strange. I cannot access any OID after my xxxxx.16.6.2.1.4.30 (in the 16.6 branch) but I can access xxxxx.16.7 and xxxxx.16.8 which are both defined with type=string.
If I do a walk starting at xxxxx.16.6, it runs for a while (1 second per value is really killing me. I use flag=norefresh for anything that isn't a "per second" counter, as per your instructions..) then it stops with the "Reason: (genError) A general failure occured" error message as said earlier.
Also, when I reach that point, restarting the snmp.exe process no longer works. When I issue the stop command, snmp.exe starts using 25% cpu (on a quad core system, so it's maxing out one of the cores) and the stop operation times out. I then have to manually kill the process.
The memory usage increases as well. Right after starting the service, snmp.exe uses 2.5MB. After a few seconds (I guess, after your DLL has initialized), memory usage increases to 7.1MB. This in itself is not a problem. After running my snmpwalk, the memory of the service climbs to 11MB or more.
Could it be some "memory leak" or some pool of reused objects that gets exhausted? What I find really odd is that even after relaunching the service, I still can't access any of the late OIDs. It doesn't look like it's related to the number of queries or the rate of queries.
Is there a limit to how many blocks we can have in the INI file itself? How about the internal list of objects? (I guess you have to maintain a linked list of some sort to make snmpgetnext possible?)
Please let me know if the full counters.ini file could be useful to diagnose this..
thanks!
Antoine
Nothing is as simple as it seems at first
Or as hopeless as it seems in the middle
Or as finished as it seems in the end.
Or as hopeless as it seems in the middle
Or as finished as it seems in the end.
Hi flukester,
Today you can put up to 65535 counters in the ini file.
snmpgetnext will go thru the ini file each time, nothing is kept in memory from one cal to the other.
I fixed a minor bug in 2.0.0.13 when the ini file is read.
There is a little chance that fixes your issue : re download the zip file again.
Also, send me your ini file and log file so that I try to reproduce the error.
Thanks,
Erwan.
Today you can put up to 65535 counters in the ini file.
snmpgetnext will go thru the ini file each time, nothing is kept in memory from one cal to the other.
I fixed a minor bug in 2.0.0.13 when the ini file is read.
There is a little chance that fixes your issue : re download the zip file again.
Also, send me your ini file and log file so that I try to reproduce the error.
Thanks,
Erwan.
Excellent! Thanks for looking into this!erwan.l wrote:Hi flukester,
Today you can put up to 65535 counters in the ini file.
snmpgetnext will go thru the ini file each time, nothing is kept in memory from one cal to the other.
I fixed a minor bug in 2.0.0.13 when the ini file is read.
There is a little chance that fixes your issue : re download the zip file again.
Also, send me your ini file and log file so that I try to reproduce the error.
Thanks,
Erwan.
Tomorrow morning I will download the new version and try it. If that doesn't work, I'll send you (in private) my full counters.ini file and the debug output of a full snmpwalk.
Thanks again!
Antoine
Nothing is as simple as it seems at first
Or as hopeless as it seems in the middle
Or as finished as it seems in the end.
Or as hopeless as it seems in the middle
Or as finished as it seems in the end.
Erwan, thanks for looking into this. I downloaded the latest version and it doesn't fix my snmpwalk issue. snmp gets seem to be working fine though.erwan.l wrote:Hi flukester,
Today you can put up to 65535 counters in the ini file.
snmpgetnext will go thru the ini file each time, nothing is kept in memory from one cal to the other.
I fixed a minor bug in 2.0.0.13 when the ini file is read.
There is a little chance that fixes your issue : re download the zip file again.
Also, send me your ini file and log file so that I try to reproduce the error.
Thanks,
Erwan.
I just sent you a PM with a zip file containing my full counters.ini, logfile and snmpwalk/snmpget output.
Thanks!!
Antoine
Nothing is as simple as it seems at first
Or as hopeless as it seems in the middle
Or as finished as it seems in the end.
Or as hopeless as it seems in the middle
Or as finished as it seems in the end.
Hello!
Once again, thanks for looking into this!!
I tried 2.0.0.14 (according to the history.txt file in the zip) and am still having some issues during snmpwalks.
I'll send you a PM in a few minutes with the full counters.ini (I've added a few string counters so I can start the walk at a few places in my tree), the log.txt file and the output of my snmpwalk.
Thanks!!
Antoine
Once again, thanks for looking into this!!
I tried 2.0.0.14 (according to the history.txt file in the zip) and am still having some issues during snmpwalks.
I'll send you a PM in a few minutes with the full counters.ini (I've added a few string counters so I can start the walk at a few places in my tree), the log.txt file and the output of my snmpwalk.
Thanks!!
Antoine
Nothing is as simple as it seems at first
Or as hopeless as it seems in the middle
Or as finished as it seems in the end.
Or as hopeless as it seems in the middle
Or as finished as it seems in the end.
Who is online
Users browsing this forum: No registered users and 0 guests