Thanks for the patch information, it seems that patch is already added in
5.3.1, but the problem still exists.
The following is the "snmpgetnext 10.1 nlmLogEngineID.0.1" GDB back trace:
Breakpoint 2, table_helper_handler (handler=0x10063978, reginfo=0x100633d8,
reqinfo=0x100dd5f8, requests=0x1012ce88) at table.c:154
warning: Source file is more recent than executable.
154 int incomplete, out_of_range, cleaned_up = 0;
(gdb) p *reginfo
$1 = {handlerName = 0x10063410 "nlmLogTable", contextName = 0x0, rootoid =
0x10063420,
rootoid_len = 10, handler = 0x100639a8, modes = 3, priority = 127,
range_subid = 0,
range_ubound = 0, timeout = 0, global_cacheid = 0, my_reg_void = 0x0}
(gdb) bt
#0 table_helper_handler (handler=0x10063978, reginfo=0x100633d8,
reqinfo=0x100dd5f8,
requests=0x1012ce88) at table.c:154
#1 0x0fe648c8 in netsnmp_call_handler (next_handler=0x10063978,
reginfo=0x100633d8,
reqinfo=0x100dd5f8, requests=0x1012ce88) at agent_handler.c:434
#2 0x0fe64c6c in netsnmp_call_handlers (reginfo=0x100633d8, reqinfo=0x100dd5f8,
requests=0x1012ce88) at agent_handler.c:515
#3 0x0fe56918 in handle_var_requests (asp=0x1012bc50) at snmp_agent.c:2485
#4 0x0fe58090 in handle_pdu (asp=0x1012bc50) at snmp_agent.c:3262
#5 0x0fe57be8 in netsnmp_handle_request (asp=0x1012bc50, status=0) at
snmp_agent.c:3058
#6 0x0fe54ea8 in handle_snmp_packet (op=1, session=0x100fa508,
reqid=1940079301,
pdu=0x100fdee8, magic=0x0) at snmp_agent.c:1833
#7 0x0fd60ee4 in _sess_process_packet (sessp=0x100df158, sp=0x100fa508,
isp=0x10120448, transport=0x100f4570, opaque=0x100edce8, olength=16,
packetptr=0x10144128 "0/\002\001\001\004\aprivate¡!\002\004s£BÅ\002\001",
length=49)
at snmp_api.c:5340
#8 0x0fd62294 in _sess_read (sessp=0x100df158, fdset=0x7f9a98b0) at
snmp_api.c:5753
#9 0x0fd6232c in snmp_sess_read (sessp=0x100df158, fdset=0x7f9a98b0) at
snmp_api.c:5772
#10 0x0fd61088 in snmp_read (fdset=0x7f9a98b0) at snmp_api.c:5392
#11 0x100048e4 in receive () at snmpd.c:1167
#12 0x1000420c in main (argc=6, argv=0x7f9a9db4) at snmpd.c:1011
(gdb) c
Breakpoint 2, table_helper_handler (handler=0x100628d0, reginfo=0x100620e8,
reqinfo=0x100dd5f8, requests=0x1012ce88) at table.c:154
154 int incomplete, out_of_range, cleaned_up = 0;
(gdb) p *reginfo
$2 = {handlerName = 0x10062120 "nlmLogVariableTable", contextName = 0x0,
rootoid = 0x10062138, rootoid_len = 10, handler = 0x10062900, modes = 3,
priority = 127, range_subid = 0, range_ubound = 0, timeout = 0,
global_cacheid = 0,
my_reg_void = 0x0}
(gdb) bt
#0 table_helper_handler (handler=0x100628d0, reginfo=0x100620e8,
reqinfo=0x100dd5f8,
requests=0x1012ce88) at table.c:154
#1 0x0fe648c8 in netsnmp_call_handler (next_handler=0x100628d0,
reginfo=0x100620e8,
reqinfo=0x100dd5f8, requests=0x1012ce88) at agent_handler.c:434
#2 0x0fe64c6c in netsnmp_call_handlers (reginfo=0x100620e8, reqinfo=0x100dd5f8,
requests=0x1012ce88) at agent_handler.c:515
#3 0x0fe56918 in handle_var_requests (asp=0x1012bc50) at snmp_agent.c:2485
#4 0x0fe57628 in handle_getnext_loop (asp=0x1012bc50) at snmp_agent.c:2906
#5 0x0fe580d0 in handle_pdu (asp=0x1012bc50) at snmp_agent.c:3275
#6 0x0fe57be8 in netsnmp_handle_request (asp=0x1012bc50, status=0) at
snmp_agent.c:3058
#7 0x0fe54ea8 in handle_snmp_packet (op=1, session=0x100fa508,
reqid=1940079301,
pdu=0x100fdee8, magic=0x0) at snmp_agent.c:1833
#8 0x0fd60ee4 in _sess_process_packet (sessp=0x100df158, sp=0x100fa508,
isp=0x10120448, transport=0x100f4570, opaque=0x100edce8, olength=16,
packetptr=0x10144128 "0/\002\001\001\004\aprivate¡!\002\004s£BÅ\002\001",
length=49)
at snmp_api.c:5340
#9 0x0fd62294 in _sess_read (sessp=0x100df158, fdset=0x7f9a98b0) at
snmp_api.c:5753
#10 0x0fd6232c in snmp_sess_read (sessp=0x100df158, fdset=0x7f9a98b0) at
snmp_api.c:5772
#11 0x0fd61088 in snmp_read (fdset=0x7f9a98b0) at snmp_api.c:5392
#12 0x100048e4 in receive () at snmpd.c:1167
#13 0x1000420c in main (argc=6, argv=0x7f9a9db4) at snmpd.c:1011
(gdb)
Thanks
Emi
________________________________
From: Jayaprakasha Guddenahalli Naganna [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 06, 2007 2:19 AM
To: Emi Yanagi; net-snmp-coders@lists.sourceforge.net
Subject: RE: When there is "no instance" object in a table,snmpgetnext skip the
rest of the objects in the table and search forthe next table
Problem is in "sparse_table_helper_handler" function,
- if (request->requestvb->type == ASN_NULL ||
- request->requestvb->type == SNMP_NOSUCHINSTANCE) {
+ if (request->requestvb->type == SNMP_NOSUCHINSTANCE) {
When ' request->requestvb->type' is ASN_NULL this function is not assigning
ASN_PRIV_RETRY and get next will move to next table instead of moving to next
accessible column/instance.
Please refer to the attached mail thread...
Thanks
-JP
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Emi Yanagi
Sent: Wednesday, September 05, 2007 9:21 PM
To: net-snmp-coders@lists.sourceforge.net
Subject: When there is "no instance" object in a table,snmpgetnext skip the
rest of the objects in the table and search forthe next table
I am reporting a bug in snmpgetnext. Here is how to reproduce the problem with
nlmLogTable.
NlmLogEntry ::= SEQUENCE {
nlmLogIndex Unsigned32,
nlmLogTime TimeStamp,
nlmLogDateAndTime DateAndTime,
nlmLogEngineID SnmpEngineID,
nlmLogEngineTAddress TAddress,
nlmLogEngineTDomain TDomain,
nlmLogContextEngineID SnmpEngineID,
nlmLogContextName SnmpAdminString,
nlmLogNotificationID OBJECT IDENTIFIER
}
$ snmpget 10.1 nlmLogTime.0.3
NOTIFICATION-LOG-MIB::nlmLogTime."".3 = Timeticks: (15125) 0:02:31.25
$ snmpgetnext 10.1 nlmLogTime.0.3
NOTIFICATION-LOG-MIB::nlmLogDateAndTime."".3 = STRING: 2007-9-5,15:9:29.0,+0:0
$ snmpgetnext 10.1 nlmLogDateAndTime.0.3
NOTIFICATION-LOG-MIB::nlmLogEngineID."".3 = ""
$ snmpget 10.1 nlmLogEngineTAddress.0.3
NOTIFICATION-LOG-MIB::nlmLogEngineTAddress."".3 = No Such Instance currently
exists at this OID
$ snmpget 10.1 nlmLogNotificationID.0.3
NOTIFICATION-LOG-MIB::nlmLogNotificationID."".3 = OID: IF-MIB::linkDown
Now since nlmLogEngineTAddress has no instance, although the last object
nlmLogNotificationID in nlmLogTable exists, snmpgetnext of nlmLogEngineID will
return nlmLogVariableID of the next table nlmLogVariableTable instead of
nlmLogNotificationID in the current table nlmLogTable.
$ snmpgetnext 10.1 nlmLogEngineID.0.3
NOTIFICATION-LOG-MIB::nlmLogVariableID."".3.1 = OID: SNMPv2-MIB::sysUpTime.0
Any idea how to improve snmpgetnext in this case?
Emi Yanagi
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
